ietf-smime
[Top] [All Lists]

Re: SigningCertificate and IssuerAndSerialNumber.

1998-05-18 09:06:11
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.

(I would be happy to recapitulate the argument on the PKIX list for those on 
the list that might have missed the discussion.)

Assuming that the hash covers the entire certificate, _including_ the public 
key, this would seem to satisfy that requirement.

I don't understand what purpose a hash of the key, as opposed to a hash of 
the entire certificate, would serve.  I'm not saying there isn't such a need, 
only that I don't understand. Could you explain?

This has been discussed just before and after the SMIME session at LA
with Ambarish. I do remember that you could not attend the last meeting.
However ... all the information you need is in a very recent E-mail from
May the 15 th. Please take a close look at it. It contains all the
explanations you need. Here it is again:

" 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."

Denis

Bob

Denis Pinkas <Denis(_dot_)Pinkas(_at_)bull(_dot_)net> 05/18 4:00 PM >>>
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.

This doesn't appear to make sense. Obviously a hash of the entire 
certificate, including the public key, would staisfy the same goal. But more 
importantly, it would allow discrimination between two certificates issued by 
the same CA with differnt attrigbutes but the same key.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman(_at_)novell(_dot_)com

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

-- 
      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