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
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime