ietf-smime
[Top] [All Lists]

RE: SigningCertificate and IssuerAndSerialNumber.

1998-05-17 18:22:41
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.

2.  Should we try and use the same ASN object as is being used in OCSP?  

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.

-  Second, the OCSP group needs to have much more information in their
structure than we do.  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.  (IssuerAltName is required for looking at CA
certificates, a problem we don't have.)  I have a strong desire for
reduction of size and therefore do like the ability to have just the serial
number.

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.

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.