Subject: Re: Nitpicking between CMS and CMC

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

I agree an errata is better/quicker.

spt

Carl Wallace wrote:
> 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!
> 
> 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 "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
>>
>>
>> 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
>>>
>>>
>>>
> 
>

---

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
>>> that uniquely identifies the certificate containing the public  
>>> key  or by
>>>> If SignedData is used, the signature can be generated using  
>>>> either  the
>>> SubjectKeyIdentifier "uniquely identifies the certificate  
>>> containing  the
>>> public key".
>>> something which is illegal as per the CMS RFC. This can be  
>>> cleaned  up in