Re: Nitpicking between CMS and CMC

[Tom Gindin <tgindin@xxxxxxxxxx>]

        The definition of "sid" in CMS section 5.3 says, in part "When 
other certificate formats are referenced, the documents that specify the 
certificate format and their use with the CMS must include details on 
matching the key identifier to the appropriate certificate field."  Except 
for the fact that the certification request is not a certificate, this is 
met by CMC.
        A PKCS #10 certification request and a self-signed certificate are 
not that different in semantics or in trustworthiness.  Since a 
self-signed certificate has issuer == subject by definition and signature 
== signatureAlgorithm by RFC 5280 section 4.1.2.3, the only mandatory 
fields in a self-signed certificate whose value couldn't be derived from a 
certification request are serialNumber and validity.  The signature comes 
from the subject in both cases, and is only trusted through out-of-band 
procedures.
        Should the wording in section 5 change from "uniquely identifies 
the certificate containing" to "uniquely identifies the certificate or 
certification request containing"?  If so, another sentence about 
certification requests gets added to 5.3, like "When certification request 
formats are referenced, the documents that specify the request format and 
their use with the CMS must include details on matching the key identifier 
to the appropriate request field."

                Tom Gindin





Sean Turner <turners@xxxxxxxx> 
Sent by: owner-ietf-pkix@xxxxxxxxxxxx
03/26/2009 05:57 PM

To
Jan Vilhuber <vilhuber@xxxxxxxxx>
cc
ietf-pkix@xxxxxxx
Subject
Re: Nitpicking between CMS and CMC







I think mandating a self-signed certificates is not the way to go.

spt

Jan Vilhuber wrote:
> I noticed the following discrepancy between CMC and CMS, which could 
> very accurately be described as nitpicking (but them isn't that what 
> standards are about?):
> 
> CMS RFC, section 5. Signed-data Content Type:
> <quote>
> 
>    A recipient independently computes the message digest.  This message
>    digest and the signer's public key are used to verify the signature
>    value.  The signer's public key is referenced either by an issuer
>    distinguished name along with an issuer-specific serial number or by
>    a subject key identifier that uniquely identifies the certificate
>    containing the public key.  The signer's certificate can be included
>    in the SignedData certificates field.
> 
> </quote>
> 
> Specifically: "... or by a subject key identifier that uniquely 
identifies the certificate containing the public key".
> 
> CMC RFC, Section 3.2.  Full PKI Request
> 
> <quote>
> If SignedData is used, the signature can be generated using either the 
> private key material of an embedded signature certification request 
> (i.e., included in the TaggedRequest tcr or crm fields) or a previously 
> certified signature key. If the private key of a signature certification 

> request is used, then:
> 
> a.  The certification request containing the corresponding public key
>        MUST include a Subject Key Identifier extension
> 
>  b.  The subjectKeyIdentifier form of the signerIdentifier in
>        SignerInfo MUST be used.
> 
> c.  The value of the subjectKeyIdentifier form of SignerInfo MUST be
>        the Subject Key Identifier specified in the corresponding
>        certification request.  (The subjectKeyIdentifier form of
>        SignerInfo is used here because no certificates have yet been
>        issued for the signing key.)  If the request key is used for
>        signing, there MUST be only one SignerInfo in the SignedData.
> 
> </quote>
> 
> So CMC allows the SignedData to use the SubjectKeyIdentifier, but 
pointing to the certificate request it is encapsulating. While I don't 
mind this usage, the CMS rfc specifically mentions that the 
SubjectKeyIdentifier "uniquely identifies the certificate containing the 
public key".
> 
> So if we want to be nitpicky about it, then the CMC rfc is asking for 
something which is illegal as per the CMS RFC. This can be cleaned up in 
either place, i.e. either mandating in CMC that a self-signed certificate 
be included when no previous certificate has been issued (thus making it 
conform to CMS), or modify CMS to allow a more liberal application of 
where to find the public key in question.
> 
> Thoughts?
> 
> jan
> 
> 
>