Subject: [smime] CMS signed object algorithm selection question

From: Richard Hansen <[email-masked]>
Date: Wed, 20 May 2015 13:49:14 -0400

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?

  * What happens if I put sha-1 in digestAlgorithm but choose
    md5WithRSAEncryption for signatureAlgorithm?

  * In general, what is the relationship between the digest algorithm
    associated with the chosen signatureAlgorithm and the chosen
    digestAlgorithm?

Thanks,
Richard

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 May 2015 14:07:19 -0400

Richard:

See below.

>    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.

>    md5WithRSAEncryption for signatureAlgorithm?

At  minimum, this is rude.  The I would expect an error.

The complete answer requires looking at SignedData:

      SignedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithms DigestAlgorithmIdentifiers,
        encapContentInfo EncapsulatedContentInfo,
        certificates [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
        signerInfos SignerInfos }

The digestAlgorithms list comes before the content.  This allows an implementation to calculate the hash values as it buffers or processes the content, depending on the circumstance.  To encounter a signature that uses a hash function that is not in this list should cause an error.

>    associated with the chosen signatureAlgorithm and the chosen

I think this is answered above,

Russ

---

From: Richard Hansen <[email-masked]>
Date: Wed, 20 May 2015 14:42:59 -0400

Thank you for your prompt reply.  Comments below.

On 2015-05-20 14:07, Russ Housley wrote:
> These are equivalent.

Good to know, thanks.  I was worried that sha1WithRSAEncryption might
mean to use SHA1 to hash whatever hash was produced by the chosen
digestAlgorithm before applying RSA, as silly as that would be.  :)

> 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.

See <http://article.gmane.org/gmane.ietf.sidr/4706> for details.

> At  minimum, this is rude.  The I would expect an error.

OK.  Shouldn't RFC3370 and/or RFC5652 prohibit mismatches?

If the signatureAlgorithm's named digest algorithm should always match
the chosen digestAlgorithm, why do the xxxWithRSAEncryption variants
even exist?  Why not just have rsaEncryption?

> The digestAlgorithms list comes before the content.  This allows an
> implementation to calculate the hash values as it buffers or
> processes the content, depending on the circumstance.  To encounter a
> signature that uses a hash function that is not in this list should
> cause an error.

I did see the discussion about how SignedData's digestAlgorithms field
is meant to enable one-pass processing in RFC5652 Section 5.1.  However,
if sha1WithRSAEncryption had meant to hash the hash before RSA, then
one-pass processing would still be possible even if SHA1 wasn't
mentioned in digestAlgorithms.

> I think this is answered above.

Indeed, thanks!

-Richard

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 20 May 2015 20:01:01 +0000

-----Original Message-----
Richard Hansen wrote:
>> digestAlgorithm and the the identifier that includes the hash function 
>> and the signature algorithm in signatureAlgorithm.
>
> 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

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.

---

From: Richard Hansen <[email-masked]>
Date: Wed, 20 May 2015 16:39:17 -0400

On 2015-05-20 16:01, Kemp, David P. wrote:
> 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

---

From: Bilal Ashraf <[email-masked]>
Date: Thu, 21 May 2015 12:15:01 +0500

Hi,

Please see my responses inline.

Regards,
Bilal.

>      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.

>      md5WithRSAEncryption for signatureAlgorithm?
[Bilal] : See above.
>      associated with the chosen signatureAlgorithm and the chosen
[Bilal] : See above.
>
> Thanks,
> Richard
>
> _______________________________________________
> smime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smime
>
>

---

From: Richard Hansen <[email-masked]>
Date: Thu, 21 May 2015 14:36:54 -0400

On 2015-05-21 03:15, Bilal Ashraf wrote:
> "sha-1".

I'd like to get some historical context:  Do you know why the semantics
of digestEncryptionAlgorithm (rsaEncryption) was changed to
signatureAlgorithm (sha1WithRSAEncryption)?

> Here "signatureAlgorithm" alone can be be used to pick the
> digest algorithm

So an implementation conforming to RFC5652 is allowed to ignore
digestAlgorithm when validating a signature?  I couldn't find anywhere
in RFC5652 or RFC3370 that suggests this.  If so, this means that it is
not OK to put rsaEncryption in the signatureAlgorithm field, as that
doesn't specify which digest algorithm to use.

> but IMHO, "digestAlgorithm" remains there for backward
> compatibility with PKCS#7.

OK, backward compatibility makes sense.

> "digestAlgorithm" must be compatible with the

Where does RFC5652 or RFC3370 state this requirement?  I couldn't find
anything.

Are digestAlgorithm and signatureAlgorithm required to be compatible for
PKCS#7 compatibility?  Is PKCS#7 compatibility required by RFC5652?

Thanks,
Richard

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 May 2015 14:38:21 -0400

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:

> [Bilal] : If you look at RFC 2315 (PKCS#7) , the ASN.1 structure of signerInfo is :
> 
> 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 :
> 
> 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.
>