Denis Pinkas wrote:
Bob,
Denis,
I had expected to agree with you, but I am not sure I do.
We discussed on the PKIX list the need to tie an e-mail message to a
specifc certificate, in particular in the case where the same public key
has been included in two certificates with different expriation dates,
different attributes, etc. We agreed to move that discussion to the S/MIME
group, since they were working in that area.
If you want to "tie" an email message to a certificate (specific or
otherwise) you need to be able to verify the messages signature. This
usually necessitates the posession of the senders certificate chain.
At this point what you put in SigningCertificate is there solely to
verify the right certificate is being used.
If you can assume posession of the senders certificate chain then OCSP
should be happy: any information it wants is available.
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 term "in the context of S/MIME" needs clarification. If this means
in the context of an S/MIME implementation then there is no problem.
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.
OCSP doesn't have to verify the hash of the certificate or make sure it
is pointing to the right certificate in an S/MIME implementation. The
S/MIME implementation would do that as part of the verification process
and feed the information to OCSP (assuming the signatures were OK).
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."
If you did do that and just copy and paste the relevant information in a
relevant S/MIME implementation it would be unable to use OCSP for any
S/MIME messages not complying to the standard, for example v2 or the
majority of S/MIME messages currently in use. A bad idea IMHO.
If on the other hand the OCSP request is formed as part of the normal
S/MIME signature verification process you can use OCSP for v3, v2 and
all those highly popular sub-v2 implementations (you know who you are!)
that are in use.
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.