Subject: Nitpicking between CMS and CMC

From: Jan Vilhuber <[email-masked]>
Date: Thu, 26 Mar 2009 15:14:38 -0600

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

---

From: Sean Turner <[email-masked]>
Date: Thu, 26 Mar 2009 14:57:37 -0700

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

spt

Jan Vilhuber wrote:
>    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".
> 
> (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:
> 
>        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
> 
> 
>

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 26 Mar 2009 18:12:49 -0400

The "uniquely identifies" clause really only applies to the
issDN/serialNum bit.  Moving it gives:

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 
that uniquely identifies the certificate containing the public key or by
a subject key identifier.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sean Turner
Sent: Thursday, March 26, 2009 2:58 PM
To: Jan Vilhuber
Cc: [email-masked]
Subject: Re: Nitpicking between CMS and CMC

spt

> (i.e., included in the TaggedRequest tcr or crm fields) or a
previously 
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.

---

From: Jan Vilhuber <[email-masked]>
Date: Thu, 26 Mar 2009 16:42:51 -0600

Hi Carl!

Works for me. Is this something that needs fixed in a new CMS  
revision? How does this work?

jan

On Mar 26, 2009, at 4:12 PM, Carl Wallace wrote:

> the

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 26 Mar 2009 18:48:09 -0400

This can be addressed with an errata report:
http://www.rfc-editor.org/errata.php. 

-----Original Message-----
From: Jan Vilhuber [mailto:[email-masked]] 
Sent: Thursday, March 26, 2009 3:43 PM
To: Carl Wallace
Cc: Sean Turner; [email-masked]
Subject: Re: Nitpicking between CMS and CMC

Hi Carl!

jan

On Mar 26, 2009, at 4:12 PM, Carl Wallace wrote:

> From: [email-masked]
[mailto:[email-masked] 
> ]

---

From: Sean Turner <[email-masked]>
Date: Thu, 26 Mar 2009 15:59:00 -0700

I agree an errata is better/quicker.

spt

---

From: Jan Vilhuber <[email-masked]>
Date: Thu, 26 Mar 2009 17:02:36 -0600

Sounds good then.

Thanks!
jan

On Mar 26, 2009, at 4:59 PM, Sean Turner wrote:

>> http://www.rfc-editor.org/errata.php. -----Original Message-----
>> From: Jan Vilhuber [mailto:[email-masked]] Sent: Thursday,  
>> March 26, 2009 3:43 PM
>> To: Carl Wallace

---

From: Tom Gindin <[email-masked]>
Date: Thu, 26 Mar 2009 20:18:11 -0400

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 <[email-masked]> 
Sent by: [email-masked]
03/26/2009 05:57 PM

To
Jan Vilhuber <[email-masked]>
cc
[email-masked]
Subject
Re: Nitpicking between CMS and CMC

spt

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.