Re: CMS signed object algorithm selection question

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
[email protected]
https://www.ietf.org/mailman/listinfo/smime