Re: CMS signed object algorithm selection question

Bilal:

The original PKCS#7 specification only supported RSA signatures.  That is, a message digest or hash value was computed, and then it was encrypted with the RSA private key.  The standards-track RFC supports RSA as well as many other signature schemes.  The terminology was changed to reflect this situation.

Russ


On May 21, 2015, at 3:15 AM, Bilal Ashraf wrote:

> Hi,
> 
> Please see my responses inline.
> 
> Regards,
> Bilal.
> 
> On 5/20/2015 10:49 PM, Richard Hansen wrote:
>> Hi all,
>> 
>> Is this the right place to ask a question about the Cryptographic
>> Message Syntax signed object spec (RFC5652 Section 5)?  (I'm interested
>> in understanding the RFC author's intentions, not what implementations
>> currently do.)
>> 
>> I am reviewing draft-ietf-sidr-rfc6485bis for the sidr working group and
>> am confused about SignerInfo algorithm selection, specifically the
>> relationship between the digestAlgorithm and signatureAlgorithm fields.
>> 
>> RFC3370 defines the digest algorithm OIDs sha-1 and md5.  It also
>> defines the signature algorithm OIDs rsaEncryption,
>> sha1WithRSAEncryption, and md5WithRSAEncryption.  This leads me to wonder:
>> 
>>   * Suppose digestAlgorithm contains sha-1. Is there any functional
>>     difference between choosing rsaEncryption vs. sha1WithRSAEncryption
>>     for the signatureAlgorithm field?
> [Bilal] : If you look at RFC 2315 (PKCS#7) , the ASN.1 structure of signerInfo is :
> 
> SignerInfo ::= SEQUENCE {
>      version Version,
>      issuerAndSerialNumber IssuerAndSerialNumber,
>      digestAlgorithm DigestAlgorithmIdentifier,
>      authenticatedAttributes
>        [0] IMPLICIT Attributes OPTIONAL,
>      digestEncryptionAlgorithm
>        DigestEncryptionAlgorithmIdentifier,
>      encryptedDigest EncryptedDigest,
>      unauthenticatedAttributes
>        [1] IMPLICIT Attributes OPTIONAL }
> 
> Here it is mentioned the "digestEncryptionAlgorithm" and it should be e.g. "rsaEncryption" while the "digestAlgorithm" should be like "sha-1".
> 
> In RFC 3852 (CMS) which maintains backward compatibility with PKCS#7, the ASN.1 structure of signerInfo is :
> 
> SignerInfo ::= SEQUENCE {
>         version CMSVersion,
>         sid SignerIdentifier,
>         digestAlgorithm DigestAlgorithmIdentifier,
>         signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
>         signatureAlgorithm SignatureAlgorithmIdentifier,
>         signature SignatureValue,
>         unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
> 
> Here it is mentioned the "signatureAlgorithm" and it should be e.g. "sha1withrsaEncryption" while the "digestAlgorithm" should be like "sha-1".  Here "signatureAlgorithm" alone can be be used to pick the digest algorithm but IMHO, "digestAlgorithm" remains there for backward compatibility with PKCS#7. "digestAlgorithm" must be compatible with the "signatureAlgorithm" otherwise tool kits that processes this structure will give an error.
> 
> CMS tool kits must be able to process both types of structures and  tool kits that generates CMS should create as per new structure i.e. use "signatureAlgorithm" instead of "digestEncryptionAlgorithm" and "digestAlgorithm" remains as it is.
> 
>>   * What happens if I put sha-1 in digestAlgorithm but choose
>>     md5WithRSAEncryption for signatureAlgorithm?
> [Bilal] : See above.
>> 
>>   * In general, what is the relationship between the digest algorithm
>>     associated with the chosen signatureAlgorithm and the chosen
>>     digestAlgorithm?
> [Bilal] : See above.
>> 
>> 
>> Thanks,
>> Richard
>> 
>> _______________________________________________
>> smime mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/smime
>> 
>> 
> 
> _______________________________________________
> smime mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/smime

_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime