RE: I-D ACTION:draft-deacon-xkms-aia-00.txt

Thanks all for the input.  Perhaps my WSDL suggestion was a little
"academic", and I agree in practice its a little heavyweight.  
 
So, I will update the draft as follows:
 
Specify XKMS over SOAP.
 
Clarify and rename the OID to specify XKMS-Validate only.
 
Make support for X509Certificate a MUST.  As an alternative I also like
X509IssuerSerial as a MUST as it makes requests smaller which is nice in
some mobile environments.  As for X509Data, I suppose supporting this makes
sense if we want to allow a single request to contain more then 1 cert.
(I.e. please validate these 12 certs).  My inclination is to keep things
simple and not allow this in this profile, especially since XKMS validates
the whole chain, not just a single cert.  But to be honest I don't have a
strong opinion so let me know what you think.
 
Borrow the OCSP trust model where responses can be CA signed, CA delegated
or trusted via some out of band mechanism (other).
 
Regards,
Alex
 
 
 

-----Original Message-----
From: Ryan M. Hurst [mailto:rmh@windows.microsoft.com]
Sent: Monday, August 18, 2003 8:07 AM
To: Rich Salz; Deacon, Alex
Cc: ietf-pkix@imc.org; www-xkms@w3.org
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt


Rich - in-line

  _____  

From: Rich Salz
Sent: Fri 8/15/2003 6:12 PM
To: Deacon, Alex
Cc: Ryan M. Hurst; ietf-pkix@imc.org; www-xkms@w3.org
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt



> So the XKMS AIA would simply point to a WSDL file that defines where the 
> XKMS service lives, what transport should be used, is a SOAP envelope 
> required, what services are provided and even perhaps even details as to 
> what key identification forms can be sent and what the trust model is. 

Uhm, yuck. :) 

Are you really expecting every XKMS request to start out with a 
GET If-modified-since request?  And then have to parse WSDL to understand 
what do do?  Again, every single XKMS request and every single XKMS client? 

If you don't expect XKMS applications to do the conditional GET, then it's 
not a URL, but is instead a URI.  At that point, it becomes an identifier 
for *a particular instance* of a WSDL file defining the service.  At that 
point, you might as following standard AIA practice, and let the OID 
define the service and transport, and the value define how to find it. 

The only profile worth defining is XKMS over SOAP 1.1 and SOAP 1.2, 
and the value of the OID is a URL of the service that can tell you 
how to Validate the certificate.  Mandate "ds:X509Data/ds:X509Certificate" 
MUST be supported, and that other forms MAY be supported.  Leave it 
up to WS-I (when they get to us) to profile what MAYs should become 
MUSTs. 

[rmh] I agree, however in the case of a certifcate validation engine I can't
imagine a case when anything other that a X509Certificate would be used for
key evaluation, but with that being said as long as there is the MUST for
support of x509 based identification thats workable.

I think it makes little sense, for example, for a cert to 
say "here's the Register service if you want to make more like me." :) 

[rmh] I agree,  my point is that we should be explicit in the draft.

 

I think Ryan's questions are slightly interesting, but only if you 
think a certificate is going to contain multiple AIA's.  I don't. 
In general, his questions are leading us to the morass of "PKI-ness" 
that has, so far, managed to throttle PKI in its crib. 

[rmh] I think support for multiple AIAs is important, also these concepts
must be explicit in a PKIX draft like this otherwise existing certificate
validation engines would make a different set of assumtions resulting in
non-interoperable deployments.


        /r$ 
-- 
Rich Salz                  Chief Security Architect 
DataPower Technology       http://www.datapower.com/
<http://www.datapower.com/>  
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
<http://www.datapower.com/products/xs40.html>  
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html
<http://www.datapower.com/xmldev/xmlsecurity.html>