Re: CMS signed object algorithm selection question

"Kemp, David P." <[email protected]> Wed, 20 May 2015 20:01:01 +0000
Newsgroups gmane.ietf.smime
Message-ID <[email protected]>
-----Original Message-----
Richard Hansen wrote:
> On 2015-05-20 14:07, Russ Housley wrote:
>>>  * Suppose digestAlgorithm contains sha-1. Is there any functional
>>>    difference between choosing rsaEncryption vs. sha1WithRSAEncryption
>>>    for the signatureAlgorithm field?
>> 
>> These are equivalent.
>>
>> However, the practice is to use the hash function identifier in 
>> digestAlgorithm and the the identifier that includes the hash function 
>> and the signature algorithm in signatureAlgorithm.
>
> Intriguing!  The reason draft-ietf-sidr-rfc6485bis exists is to go in
> the opposite direction -- to change the requirement from sha256WithRSAEncryption
> to just rsaEncryption.  All of the existing RPKI CA implementations use rsaEncryption,
> apparently because the 3rd party crypto libraries don't support sha256WithRSAEncryption.
> It was decided that it would be easier/better to change the RFC than to force
> implementations to change.

A case could be made that rsaEncryption and sha1WithRSAEncryption are not equivalent.  The former should be used exclusively to identify a type of public key (in a certificate's subjectPublicKeyInfo "algorithm" field) and the latter should be used exclusively to identify a signature algorithm (in a SignerInfo's or Certificate's "signatureAlgorithm" field).  If the ASN.1 specification were more strongly typed it would be an easy-to-detect syntax error to use an OID of one type in a field of a different type, instead of being just a logical error that could lead to latent issues.

Failure to identify the signature algorithm (by using rsaEncryption in signerInfo) could cause problems if digestAlgorithms contains more than one DigestAlgorithmIdentifier (e.g. MD5, SHA-1, and SHA-256).  In that case all three hashes are computed over the content, but there is nothing to indicate which hash value should be used in a particular signerInfo.


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