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

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

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