ietf-smime
[Top] [All Lists]

Re: [smime] CMS signed object algorithm selection question

2015-05-20 13:43:07
Thank you for your prompt reply.  Comments below.

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.

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.

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

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

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.

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

I think this is answered above.

Indeed, thanks!

-Richard

_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime