Eric:
I just realized that I had not reponded to this message on the list.
I can accept the single rsaEncryption OID with the digest as a parameter.
Russ
At 07:23 AM 7/13/98 -0700, EKR wrote:
Russ Housley <housley(_at_)spyrus(_dot_)com> writes:
Eric & Blake:
I prefer the single OID approach; however, I do understand the backward
compatibility concern. Certificates use a single OID to specify the hash
(a.k.a. digest) and signature algorithm. I would prefer a solution that
was parallel. This admits the possibility of a common routine for all
signature verification.
I think that we all agree that id-dsa-with-sha-1 should be used for DSA and
SHA-1. So, lets put that ncontrovercial one aside.
I propose that sha-1WithRSAEncryption be used with RSA and SHA-1. This
combination is not deployed in any product that I am aware of, so there is
not an issue with backward compatability. PKIX Part 1 uses
sha-1WithRSAEncryption for certificate signatures with RSA and SHA-1.
For the reasons already stated, I would like to see implementations support
md2WithRSAEncryption and md5WithRSAEncryption. However, rsaEncryption is
already used in many implementations. So, for RSA with MD2 and MD5 mandate
(a MUST) the processing of rsaEncryption and allow (a SHOULD) the
processing of md2WithRSAEncryption and md5WithRSAEncryption.
Russ,
Maybe I missed a prior message where you spelled out your
reasoning more fully, but the first paragraph above implies that you
believe that the single OID solution is a convenience to
implementors. It's not. Since they now have to program to support two
representations, not one. As long as rsaEncryption is allowed
(mandated by backward compatibility) this will be true.
Lest you get the idea that I'm just avoiding work, let e state that I
don't like the single OID solution on protocol grounds. a bad
design. It proliferates identifiers unnecessarily, which seems
tasteless, and it makes combinations excessively difficult (in the
limit you need a lookup table to map OIDs to digest-signature
combinations). This information (the digest algorithm) is perfectly
well represented in the digestAlgorithm field. There's no need to
recapitulate it here.
Even if you believe this was a design mistake in PKCS-7, this change
doesn't really patch it. The signature validation algorithm
(and generation, FWIW) will have to be different for
PKCS-7 and X.509, because the PKCS-7 algorithm has to take
(and process) digestAlgorithm as the input in the rsaEncryption
case. Moreover, as I indicated earler, this change brings up the
unpleasant question (which I believe would have to be answered
in the protocol document) of what to do when the digestAlgorithm
and the digest in the signatureAlgorithm don't match.
-Ekr
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."