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

From: Holger Ebel <[email-masked]>
Date: Mon, 17 Feb 2003 15:28:56 +0100

Hello,

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
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 (1.3.14.3.2.26)
and the digestEncryptionAlgorithm is again RSA (1.2.840.113549.1.1.1).
(The same for RipeMD160WithRsaEncryption (1.3.36.3.3.1.2)

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

CMS
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
     signatureAlgo/digestEncryptionAlgorithm?

(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            1.3.14.3.2.26  (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        1.3.36.3.2.1  (Ia)     1.3.36.3.3.1.2
    (1.3.36.3.3.1.2)                       (Ib)     1.2.840.113549.1.1.1
                                           (II)     1.2.840.113549.1.1.1

(D) sha1WithDsa            1.3.14.3.2.26  (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

Holger

---

From: "Tom Gindin" <[email-masked]>
Date: Tue, 18 Feb 2003 12:34:24 -0500

Holger:

      With respect to your digestAlgorithm and digestEncryptionAlgorithm
points, the use of the term "digestEncryptionAlgorithm" really applies best
to RSA signatures and only to one mode of those.  PKCS#1has two distinct
signature schemes: the traditional one, which is the only mode defined
within RFC 2313 and 2437 and is described in the new RFC 3447 as
RSASSA-PKCS1-V1_5-SIGN; and the newly recommended one, which is described
in RFC 3447 as RSASSA-PSS-SIGN.  In the older mode, the plain text
encrypted by the RSA key contains the actual algorithm ID of the hash
algorithm used - see RFC 3447 section 9.2 step 2 or RFC 2437 section 9.2.1
step 2.  In the newer mode, the hash algorithm used cannot be recovered so
easily from the plain text - see RFC 3447 section 9.1.1 and 9.1.2.  This is
especially the case because the mask generation function is typically based
on a hash algorithm which need not be the same as the hash algorithm used
in the signature calculation, although it is recommended in RFC 3447 that
they be the same.
      Please note that although RFC 3447 is brand new, it is essentially
the same as PKCS#1 version 2.1, whichhas been actively under development
since at least September 1999 (including the PSS scheme) and was finalized
in June 2002.

                  Tom Gindin

Holger Ebel <[email-masked]>@mail.imc.org on 02/17/2003
09:28:56 AM

Sent by:    [email-masked]

To:    [email-masked]
cc:
Subject:    signatureAlgorithm in PKCS#7/RFC 2630/RFC 3369/70

Hello,

PKCS#7

CMS

Now my questions:

Thanks in advance

Best Regards

Holger