ietf-smime
[Top] [All Lists]

Re: SigningCertificate and IssuerAndSerialNumber.

1998-05-18 08:04:17
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 
thei 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?

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