Re: CMS signed object algorithm selection question

Richard Hansen <[email protected]> Wed, 20 May 2015 16:39:17 -0400
Newsgroups gmane.ietf.smime
Message-ID <[email protected]>
On 2015-05-20 16:01, Kemp, David P. wrote:
> 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).

You make an interesting point.  RFC3370 Section 3.2 says:

   The algorithm identifier for RSA subject public keys in certificates
   is:

      rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

Notice the phrase "for RSA subject public keys in certificates".

However, later in that same section:

   The rsaEncryption algorithm identifier is used to identify RSA (PKCS
   #1 v1.5) signature values regardless of the message digest algorithm
   employed.

which sounds to me like it can *also* be used for a SignerInfo'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.

What about a particular SignerInfo's digestAlgorithm field?

-Richard

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