[Top] [All Lists]

Re: [smime] CMS signed object algorithm selection question

2015-05-20 15:39:26
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 
to just rsaEncryption.  All of the existing RPKI CA implementations use 
apparently because the 3rd party crypto libraries don't support 
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

      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

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?


smime mailing list