Jim,
I am joining the thread since your document directly relates to the
presentation I made at the Los Angeles meeting.
I will also attempt to bridge the gap between the smime WG and the pkix
WG.
I will first comment on this E-mail and then address some other issues
related to your document.
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.
I do have a strong preference. :-)
In the pkix WG we are discussing the OCSP protocol, where basically
giving the reference of a certificate it should be possible to know
*on-line* from an OCSP whether this certificate is or is not revoked.
If this is done in the context of S/MIME then we would extract that
reference and then send it to the OCSP. Ideally a COPY and PASTE
operation would be nice: the same data structure should be used for both
the SMIME WG and the PKIX WG.
The proposal of using simply the hash of the certificate does not work
... because of the minimum assumption we are making in the PKIX WG: the
OCSP has only access to the newest CRL but no access to the individual
certificates themselves. Under such assumption the OCSP is thus UNABLE
to verify the hash of the certificate and therefore to make sure it is
pointing to the right certificate. For solving the case Ambarish
proposed to replace the hash of the certificate by the hash of the
public key of the CA, which is a technically adequate solution.
In that case the minimum assumption we are making works fine, since the
OCSP server must anyway know the value of the public key of the CA to
verify the CRL. So it can compute its hash.
The conclusion is then simple: what is need is a triple consisting of :
a) the issuer name,
b) the certificate serial number, and
c) a hash of the public key of the CA.
All that information needs to be part of the authenticated attributes.
At this time, in the PKIX WG we are discussing the details of such an
ASN.1 data structure.
Please join the PKIX mailing list if you wish to participate.
Now a few more comments on the document:
A. In section 2. Re-issue of Certificate.
Either I do not see this as a problem or I do not understand your
problem.
Cross certificates can be revoked. So if the CA wishes to re-issue a
certificate it simply revokes it before and may use different policies
in the new issued certificate. Where is the problem ?
B. The discussion and explanations about the need for the hash
mentionned in the discussion above should be added.
C. In the Open Issues section. The inclusion for a complete chain of
certificates would have some advantages (I do not claim it is necessary
in all the cases). It allows the signer to specify its own belief for
the verification process. If the verifier wants to use a different
chain, this is fine for him, but then under his own risk.
The "rollover" argument is not a problem since anyway it is important to
capture all the certificates that were valid at the time the signature
was created, but this is a minor detail.
Finally I could not understand the issue expressed in the last paragraph
of "B. Open Issues". A different wording might be necessary.
Denis
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 that
something that complemented the outer issuerAndSerialNumber rather than
duplicated it would be preferable.
B. Open Issues
Some people have expressed a desire to solve the "Reissue
of Certificate" attack. I see no pressing need to address
this attack. Any certificate authority that allowed for
this attack is operating in an improper fashion and should
not be used. In the event that the attack is deemed to be
of importance, it could be solved by the addition of a
hash to the SigningCertificate ASN structure. This would
allow the relying entity to verify that the certificate
was exactly the same as the signing entity claimed to have
used.
I would respectfully suggest that if the SigningCertificate structure
contained a hash of the signers certificate (or some equivalent) the
IssuerAndSerialNumber structure would be redundant.
This prompts the question: why not make the SigningCertificate structure
consist wholly of the hash?
In addition the hash is likely to be more compact than the
issuerAndSerial number structure.
I agree that there is no pressing need to address the other attacks (a
rogue CA could do much nastier things invisibly) but if they can be
addressed (in addition to the original "Substitution Attack") this is no
bad thing IMHO.
Steve.
--
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)bigfoot(_dot_)com
PGP key: via homepage.
--
Denis Pinkas Bull S.A.
mailto:Denis(_dot_)Pinkas(_at_)bull(_dot_)net
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21