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

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

Maybe we can just use the RetrievalMethod element in that case?

> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Thursday, December 14, 2000 5:22 PM
> To: ebxml-tp@lists.ebxml.org; ebxml-ta-security@lists.ebxml.org
> Subject: Re: Certifcate element..RE: comments on cppml,v0.1.dtd
> 
> 
> Dale,
> 
> Possibly. However, one key feature f the KeyInfo is the
> RetrievalMethod element which provides a means of
> identifying the means of obtaining key rather than 
> incorporating the bits directly as you suggest.
> 
> Cheers,
> 
> Chris
> "Moberg, Dale" wrote:
> > 
> > I remember somewhere recently that we wondered whether
> > we wanted the CPP & CPAs to be deprecated if only the
> > certificate for a given authorizing role changed; for
> > example, if the SSL server name changed or the signing
> > certificate expired and a new certificate was issued.
> > 
> > The KeyInfo field seems to move us toward the consequence
> > that we will have to deprecate the CPP because it
> > would typically include the actual base64 encoded
> > certificate chain. I see the KeyInfo field as basically
> > the xmldsig analog of the pkcs7 set of CRLS and Certs
> > that can be included in a smime message.
> > 
> > Of course, so would other values tied to the actual
> > identity of the certificate (rather than pointers)
> > like the fingerprints of serial numbers I mentioned.
> > 
> > If we used some link facility, we would
> > only point to the actual security objects (and they
> > could change and the link (URL) stay the same.
> > 
> > I think I now am leaning toward a pointer/reference
> > mode of CPP/CPA link to the cert chains and crls,
> > but could be swayed otherwise (for example, if the
> > URL allows the cert to be replaced, possibly
> > we open up a maintenance issue (how to notify to
> > recheck the URL ) or mischief opportunity.)
> > 
> > We are in effect inventing yet another means
> > of certificate distribution by obtaining
> > certs from a CPA to store in a cert/crl cache.
> > 
> > > -----Original Message-----
> > > From: Moberg, Dale
> > > Sent: Thursday, December 14, 2000 3:11 PM
> > > To: 'Christopher Ferris'; ebxml-tp@lists.ebxml.org;
> > > ebxml-ta-security@lists.ebxml.org
> > > Subject: Certifcate element..RE: comments on cppml,v0.1.dtd
> > >
> > >
> > > > 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>
> > > >
> > > >
> > >
>