Jim wrote:
I have to admit that I like this proposal for a couple of reasons. First it
makes the message shorter as the hash is almost certianally smaller than the
issuer/serial number. Secondly it removes duplicated information from the
certificate.
I originally proposed the issuer/serial number for two reasons. First this
is the currently accepted method of identifying a certificate. Second, it
makes the process of validating the correctness easier. A binary compare of
the issuer DNs and the serial numbers can be binary compared to validate the
certifiate. Using the hash requires that the certificate be present (so it
can be pre-validated by a gateway) and potentially adds a more complicated
computation (hashing the certificate) to validate the attribute.
I don't really have a strong preference about which way this should be done.
In an earlier thread dealing with ACs Dave Kemp wrote:
"A single attribute containing a list of (issuerName, serialNumber,
hash(issuerPublicKey)) could serve the dual purpose of binding a normal
certificate into the transaction (to prevent spoofing) and to bind selected
attribute certs into the transaction (to prevent third parties from inserting
unwanted-but-valid attribute certs)."
Thinking along the line of Steve and using Dave's method for binding X.509 v3
to ACs, the signingCertificate attribute binding could be hash(issuerName,
serialNumber, issuerPublicKey).
jim
-----Original Message-----
From: Dr Stephen Henson [mailto:shenson(_at_)bigfoot(_dot_)com]
Sent: Wednesday, May 13, 1998 7:30 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: SigningCertificate and IssuerAndSerialNumber.
While I feel that the principle of the specification is good I have to
admit that I have been swayed by the argument in favour of using
something other than IssuerAndSerialNumber to bind the signers
certificate.
One reason is that as things stand use of the signing certificate
attribute makes the "outer" issuerAndSerialNumber redundant. I feel