Denis Pinkas wrote:
I have a few comments about draft-schaad-smime-algorithm-attribute-03.txt:
1) The key question is what should contain the field signatureAlgorithm ?
SignatureAlgorithmIdentifier is defined in section 10.1.2 from RFC 5652:
The SignatureAlgorithmIdentifier type identifies a signature
algorithm, and it can also identify a message digest algorithm.
Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with
SHA-256. A signature algorithm supports signature generation and
verification operations. The signature generation operation uses the
message digest and the signer's private key to generate a signature
value. The signature verification operation uses the message digest
and the signer's public key to determine whether or not a signature
value is valid. Context determines which operation is intended.
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
Some examples are questionable: is RSA really a "signature algorithm" ?
sha-1withRSA is really a signature mechanism, since it cannot be used
Call it "evolutionary heritage" (from PKCS#7 1.5 -> SMIME/CMS)
there was a semantical change in the SignerInfo ASN.1 structure
for SignedData in that the element "digestEncryptionAlgorithm"
was respecified as "SignatureAlgorithmIdentifier".
So for historical reasons, RSA-based signatures use the
original DigestEncryptionAlgorithm sematics and the AlgId
RSA / rsaEncryption (1.2.840.1135184.108.40.206)
while all other public key signature schemes use the newer CMS semantics
"SignatureAlgorithmIdentifier" and a signature AlgId that includes
a specific hash algorithm. I notice that rfc2630 section 5.3 lists "DSS"
as an example value for SignatureAlgorithmIdentifier, but e.g. our
implementation of PKCS7 uses id_dsa_with_sha1 (1.2.840.10040.4.3)
--the only DSA-related OID defined in rfc2630.
_not_ id_dsa (1.2.840.10040.4.1) which AFAIK is used for DSA _keys_
in X.509 certs and defined elsewhere.
Ietf mailing list