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

From: Holger Ebel <[email-masked]>
Date: Tue, 18 Feb 2003 11:50:15 +0100

[I accidentally posted this (somewhat different) message to the pkix
list, apologize for that. After some direct replies I've modified
some parts of my original post]

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.

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))

Although 'only' RSA is mentioned in PKCS7 directly as a digest-
EncryptionAlgorithm, I assume that this rules also apply for other
'encryptionAlgorithm's.
All the PKCS#7 'samples' I've found strictly follows these rules, there
is always a digest and a digestEncryption algorithm.

- CMS (2630) -
CMS (RFC 2630) introduced the term signatureAlgorithm in the
SignerInfo structure, which has 'replaced' the digestEncryptionAlgorithm
of PKCS#7 while the digestAlgorithm field still remains.

If a signatureAlgorithm is used to create the signature whose cipher is
using the RSA algorithm, the 'old' RSA OID 1.2.840.113549.1.1.1 must be
used in the 'signatureAlgorithm' field. (12.2.2) The digestAlgorithm
field contains then the corresponding digest Oid, eg. SHA-1, MDx or
RipeMD160.
The usage of the signatureAlgorithmOids sha1WithRSAEncryption,
md5WithRSAEncryption or ripeMD160WithRsaEncryption is not allowed in
2630, the above mentioned schema must be used.
When using a signatureAlgorithm which has another cipher - like DSA or
ECDSA - the 'splitting' into a digest and a cipher algorithm is not
allowed, the signatureAlgorithmOid must be used. (e.g. sha1WithDSA
(1.2.840.10040.4.3)) and the digestAlgorithm field must contain the
digestAlgo 'included' in the signatureAlgo. Restrictions for the usage
of other signatureAlgoritms may be defined in other RFCs (like 3278).

- CMS (3369/70)
This successor of 2630 (more precise CMSALG) also allows the usage of
the signatureAlgorithmOID when a RSA cipher is used for the signature
process, which was/is not allowed in 2630. (sha1WithRSAEncryption,
md5WithRSAEncryption or ripeMD160WithRsaEncryption). For backward
compatibility, the 2630 schema (RSA) is also allowed here for the MD5
and SHA-1 digests.

Now my questions:

(1) Did I get the standard mentioned above right regarding the
     signatureAlgo/digestEncryptionAlgorithm?

(2) How should I handle a CMS (2630/3369) 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 Sha1WithDSA 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? Is the usage of the 'other'
     RSA signature OIDs (sha1WithRSAEncryption) really forbidden in 2630?

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

---------------------------------------------------------------------------
SignatureAlgorithm      digestAlgo        (I)   digestEncrAlgo(PKCS#7)
                                           (II)  signatureAlgo (RFC 2630)
                                           (III) signatureAlgo (RFC 3369)
---------------------------------------------------------------------------

(A) sha1WithRSA            1.3.14.3.2.26  (I)      1.2.840.113549.1.1.1
    (1.2.840.113549.1.1.5)                 (II)     1.2.840.113549.1.1.1
                                           (IIIa)   1.2.840.113549.1.1.1
                                           (IIIb)   1.2.840.113549.1.1.5

(B) md5WithRSA           1.2.840.1x9.2.5  (I)      1.2.840.113549.1.1.1
    (1.2.840.113549.1.1.4)                 (II)     1.2.840.113549.1.1.1
                                           (IIIa)   1.2.840.113549.1.1.1
                                           (IIIb)   1.2.840.113549.1.1.4

(D) sha1WithDsa            1.3.14.3.2.26  (I)      1.2.840.10040.4.1
    (1.2.840.10040.4.3)                    (II)     1.2.840.10040.4.3
                                           (III)    1.2.840.10040.4.3

---------------------------------------------------------------------------

(5) Or is the signatureAlgorithm check performed this way (for
     2630/3369):
     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: Russ Housley <[email-masked]>
Date: Thu, 20 Feb 2003 18:16:30 -0500

Holger:

PKCS#7 only supported the RSA algorithm, and it used field names that 
represent this situation.  signatureAlgorithm is the new name, indicating 
support for any digital signature algorithm.  The digestEncryptionAlgorithm 
is the old name, indicating the RSA operation that is performed to generate 
a digital signature with that algorithm.

<snip>

>     OID at the digestInfo field and a Sha1WithDSA OID in the signature-

I think that the digestAlgorithm must be consistent with the one used in 
the signature.

>     RSA signature OIDs (sha1WithRSAEncryption) really forbidden in 2630?

Be flexible in receive processing, but strict on send processing.  That 
said, if you need interoperability with some PKCS#7 implementations, you 
may need to send it the only way that they know how to accept it.

Russ