Re: Certifcate element..RE: comments on cppml,v0.1.dtd

[christopher ferris <chris.ferris@east.sun.com>]

Dale,

KeyInfo is supposed to address all of the issues you cite.
The point is that there are many ways of identifying a cert
as you probably know. I'm not just thinking of XMLDSIG friendly,
but that they've already addressed the problem in a far more
thorough manner than we could possibly do in the time we have
left to us.

Cheers,

Chris

"Moberg, Dale" wrote:
> 
> > Would we be better
> > served to leverage the work of the (now CR) XMLDSig WG
> > and use the KeyInfo element they have defined?
> >
> > http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/#sec-KeyInfo
> >
> 
> If the point is to have some way to identify an X.509 certificate,
> the usual "primary key" consists of the issuer's serial number
> together with the issuer's DN. Mostly this works pretty well.
> There have been CAs using dual key models that reused
> the serial number for both the signing and encrypting key;
> I don't think this should be a problem going forward. It is
> also fairly common for applications to use this information
> to retrieve certificates from a local cache, especially
> in the PKCS7 arena (because these values are used in the
> signerinfo and recipientinfo fields).
> 
> If the point is to have some way to access the certificate,
> then a URL may be a good candidate or some more convoluted
> PKI style reference to the certificate, its chain, its CRL
> and so on using OCSP services (RFC2560,RFC2459 etc. etc]
> 
> In security practice, fingerprints of certificates are often
> used for decisive indications of certificate identity.
> (some type of hash on the entire certificate. ) Such values
> would be useful supporting documentation for an application,
> I think.
> 
> I don't think there is any XML dtd established in this area
> that is so widely accepted as to prevent us from making our
> own wheel. But maybe we would want to tie the system to CDSA
> or some other PKI standards but it is hard to know what
> has the most traction in this area.
> 
> I think that the certificate identification and retrieval
> information we select has to service certificates
> referenced within open-pgp extensions, client side SSL
> certificates, and so on. So I don't see why we need
> to find an xmldsig friendly format, if that is what
> KeyInfo is.
> 
> Dale Moberg
> 
> > e.g.
> > <KeyInfo>
> >   <X509Data> <!-- two pointers to certificate-A -->
> >     <X509IssuerSerial>
> >       <X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM,
> >                   L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName>
> >       <X509SerialNumber>12345678</X509SerialNumber>
> >     </X509IssuerSerial>
> >     <X509SKI>31d97bd7</X509SKI>
> >   </X509Data>
> >   <X509Data> <!-- single pointer to certificate-B -->
> >       <X509SubjectName>Subject of Certificate B</X509SubjectName>
> >   </X509Data>
> >   <X509Data><!-- certificate chain -->
> >               <!--Signer cert, issuer
> > CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4-->
> >     <X509Certificate>MIICXTCCA..</X509Certificate>
> >     <!-- Intermediate cert subject CN=arbolCA,OU=FVTO=IBM,C=US
> >                    issuer,CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
> >     <X509Certificate>MIICPzCCA...</X509Certificate>
> >     <!-- Root cert subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
> >     <X509Certificate>MIICSTCCA...</X509Certificate>
> >   </X509Data>
> > </KeyInfo>
> >
> >
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard