[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