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.

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." :)

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

Received on Friday, 15 August 2003 21:12:19 UTC