ebxml-tp message


OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC