Jim,
I would guess that working on Sundays is no good. :-)
You did not look at my E-mail sufficiently.
From the messages to date, it would appear that we have the following
questions to be answered:
1. Should a hash of the certificate be part of the new attribute? From the
mail to-date (admittally very few people) the answer appears to be yes.
My E-mail is advocating *against* the use of the hash of the
certificate. Instead it is advocating for the use of the same structure
in the PKIX WG and the SMIME WG. A hash is needed, but it is NOT the
hash of the certificate, but the hash of the issuer public key.
This would allow to make the difference between two CAs having the same
name.
2. Should we try and use the same ASN object as is being used in OCSP?
The answer is yes.
A yes answer to this question has several different ramifications.
- First, this would give us yet another tie to the PKIX group in terms of
dependencies. We might well be able to finish before the OCSP group if we
don't have this dependency. On the other hand it means there is one less
ASN structure to write encode/decode functions for.
You may finsih before as long as we can reach an agreement on that
structure. Anyway there will be a dependency on PKIX Part 1.
- Second, the OCSP group needs to have much more information in their
structure than we do.
If the PKIX WG needs it, this means that the SMIME WG must be able to
supply it and therefore it has to be extractable from an SMIME message.
As Steve pointed out all we really need is the hash
of the certificate in the attribute as we have both the issuer and serial
number (required in our certificates) and the certificate or we don't even
get pass the initial part of the verification. The current OCSP structures
that I have seen include the issuerName, issuerAltName, serialNumber and
hash of certificate.
hash of the issuer public key.
(IssuerAltName is required for looking at CA
certificates, a problem we don't have.)
It depends whether or not DNs only can be used, or AltNames can be used
as well. This is currently a rather hot topic within the PKIX WG.
I have a strong desire for reduction of size and therefore
do like the ability to have just the serial number.
This would not work, unless we can get the other elements.
My answer to number 2 most likely be, gee it would be nice but....
and probably falls into the no category.
3. If the answer is NO to question 2. Should the structure consist of the
issuer/serial number or the hash. I personally like the hash as it is short
and provides additional information than the issuer/serial number option.
See above.
Denis
jim
-----Original Message-----
From: Dr Stephen Henson [mailto:shenson(_at_)bigfoot(_dot_)com]
Sent: Friday, May 15, 1998 6:30 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Denis Pinkas wrote:
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.
I may be missing something here but why can't the standard "outer"
issuerAndSerialNumber be used? Under the proposal (at least
how I meant it) it would still be there.
The extra binding caused by the SigningCertificate attribute crucially
relies on the fact that the authenticated attributes are
signed. If the signature on the authenticated attributes cannot
be checked (e.g. if the senders certificate is not available) then
checking the IssuerAndSerialNumber of the SigningCertificate
(assuming it is present) is no better than checking the outer
unsigned issuerAndSerialNumber.
If there is a situation where an agent would have access to enough
information to verify the signature on the authenticated attributes
(which would as a bare minimum require the senders public key) but not
have access to the senders certificate then yes I agree this
would be a problem.
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