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