[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

signatureAlgorithm in PKCS#7/RFC 2630/RFC 3369/70


after working through these specs and decoding many example signatures
I still have the following questions regarding the meaning of the
signatureAlgorithm/digestEncryptionAlgorithm in these standards
mentioned above. (To be more precise, the appearance of these in the
SignerInfo structure of the SignedData contentType)

If this topic does not belong to this list, it would be nice if someone
can point me at the responsible mailing list.

Please note that I use the term signatureAlgorithm for the combination
of a digest and a digestEncryption algorithm in the following mail.
(To be honest, this could also be the subject of my mail: Do the
successors of PKCS#7 mean "SignatureAlgorithm" alike.) ;-)

With respect, I would like to summarize first how I get these standards.

PKCS#7 1.5 (RFC 2315) clearly distinguishes between a digestAlgorithm
and a digestEncryptionAlgorithm.
So if  the signatureAlgorithm is md5WithRSAEncryption
(1.2.840.113549.1.1.4), the digestAlgorithm is md5 (1.2.840.113549.2.5)
and the digestEncryptionAlgorithm is RSA (1.2.840.113549.1.1.1).
Or if the signatureAlgorithm is sha1WithRSAEncryption
(1.2.840.113549.1.1.5), the digestAlgorithm is sha1 (
and the digestEncryptionAlgorithm is again RSA (1.2.840.113549.1.1.1).
(The same for RipeMD160WithRsaEncryption (

All the PKCS#7 'samples' I've found strictly follows these rules, there
is  a  digest-  and  a digestEncryption algorithm.

CMS (RFC 2630/3369/3370) introduced the term signatureAlgorithm in the
SignerInfo structure, which has 'replaced' the digestEncryptionAlgorithm
of PKCS#7 while the digestAlgorithm field still remains.
Here the value of the signatureAlgorithm must contain a signatureAlgoOID
(sha1WithRSAEncryption, md5WithRSAEncryption, RipeMD160WithRsaEncryption
or sha1WithDsaEncryption) and the digestAlgorithmValue must be equals to
the one defined in the signatureAlgorithm.
The only Exception is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1
in conjunction with a digestAlgorithm as defined in PKCS#7 for backward
compatibility. When this OID is used, it is assumed that the digestAlgo
is SHA-1, but may be also MD5. (RFC 3370)
The CMS samples I've found (e.g. csrc.nist.gov/pki/testing/x509paths.html,
ISISMTT TestSuite) following these rules.

Now my questions:

(1) Did I get the standard mentioned above right regarding the

(2) How should I handle a CMS (2630) signature where the value of the
    digestAlgorithm does not match the 'included' digestAlgorithm in
    the signatureAlgorithm field. (e.g. having a RIPEMD160 digestAlgo
    OID at the digestInfo field and a Sha1WithRSA OID in the signature-
    algorithm field).

(3) When a component claims that it can produce valid RFC 2630
    signatures, is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1 the
    only exception from the rule?

(4) Having the following signatureAlgorithms, is the usage of these for
    PKCS#7 and RFC 2630 signatures allowed and correct?
    (having valid signatures according the corresponding standard)

SignatureAlgorithm      digestAlgo        (I)  signatureAlgo (RFC 2630)
                                          (II) digestEncrAlgo(PKCS#7)
(A) sha1WithRSA    (Ia)     1.2.840.113549.1.1.5
   (1.2.840.113549.1.1.5)                 (Ib)     1.2.840.113549.1.1.1
                                          (II)     1.2.840.113549.1.1.1

(B) md5WithRSA           1.2.840.1x9.2.5  (Ia)     1.2.840.113549.1.1.4
   (1.2.840.113549.1.1.4)                 (Ib)     1.2.840.113549.1.1.1
                                          (II)     1.2.840.113549.1.1.1

(C) ripeMD160WithRsa  (Ia)
   (                       (Ib)     1.2.840.113549.1.1.1
                                          (II)     1.2.840.113549.1.1.1

(D) sha1WithDsa    (Ia)     1.2.840.10040.4.3
   (1.2.840.10040.4.3)                    (Ib)     1.2.840.10040.4.1 (?)
                                          (II)     1.2.840.10040.4.1

(5) Or is the signatureAlgorithm check performed this way (for 2630):
    If the signatureAlgo field contains a digestEncryptionOID, the
    signatureAlgo is the digestEncryptionOID plus the digestOID.
    If the signatureAlgo field contains a signatureAlgo, the
    signatureAlgo equals the found signatureAlgo. The included
    digestAlgo is not observed/ must be the same as the one which
    is contained in the signatureAlgo?

Thanks in advance

Best Regards