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

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

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>
> > 
> >
>