ietf-smime
[Top] [All Lists]

Re: Inclusion of the issuer and serial number in authenticated information

1998-03-23 10:46:51
From: EKR <ekr(_at_)terisa(_dot_)com>

Russ Housley <housley(_at_)spyrus(_dot_)com> writes:
I do not see the value in the certificate hash.  However, if many people
think it is desirable, then it should be optional.  We must trust CAs to
never issue more than one certificate with the same serial number.
Revocation will be all messed up if they do....

I don't see the value in the certificateHash either. Let's leave it
out.

-Ekr

Do you not see the problem that it is trying to solve, or do you believe
that solving it is not important?

I agree that CAs have to be trusted to correctly manage serial numbers.
However, do you believe that every end user will have a single trust
point, that that trust point is worthy, and that that trust point will
use X.509 mechanisms?

The current state of web browser technology is far from this ideal:
user agents maintain a database of CAs (multiple trust points), the
average user is clueless about what to include in that database, and
the user agent has no mechanism for assigning unique serial numbers to
the CAs in the database.

Given that state of affairs, I think it is reasonable to have some
assurance that a certification path can be traced back at least to the
top-level CA in that path, and not allow a single rogue CA inserted
into the database to corrupt everything.  The certificate hash
(or hash of the public key) provides local assurance, which I believe
has some value.  (Note that an arbitrarily-assigned subjectKeyIdentifier
is no more useful here than CertificateSerialNumber, you need a
determined function of the public key.)


I have a specific disagreement with Denis' suggestion:

There is no final position yet, but it seems that we are going towards
the following structure:

CertUID ::=     SEQUENCE {
    issuerDN           Name,
    issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
    serial             CertificateSerialNumber,
    certificateHash    CertHash
}

There is no reason to include both issuerDN and issuerAltName, since
GeneralNames includes X.400 name forms.  I think it is reasonable to
require CAs to have DNs, in which case the issuerAltName could be
eliminated altogether.  But if the rest of the world doesn't agree that
CAs MUST have DNs, then I suggest using X.509 IssuerSerial.

A hash algorithm specifier is needed too:

  CertUID ::= SEQUENCE {
     certID      IssuerSerial,
     certHash/keyHash  Hash }    -- of Certificate or SubjectPublicKeyInfo

  IssuerSerial ::= SEQUENCE {    -- defined in X.509
     issuer      GeneralNames,
     serial      CertificateSerialNumber,
     issuerUID   UniqueIdentifier OPTIONAL }

  Hash ::= CHOICE {
     sha1Hash     [0] OCTET STRING,
       .          [1] OCTET STRING,
       .
  }