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