Cert. identifiers in OCSP and ESS

Certificate identifiers are used both the OCSP specification from the PKIX WG
and in the ESS specification from the S/MIME WG. This is the reason why this
mail is posted to both the S/MIME and PKIX WGs.

A recent proposal made by Jim Schaad has been to change the "CertID
"definition from the S/MIME WG to "ESSCertID" because we had two different
ASN1 definitions for the same name. :-(

I would prefer to call the later "SigningCert", since the Certificates are
signed attributes and thus remove the ESS co-notation. We would then have :

     SigningCertificates ::=  SEQUENCE {
          certs        SEQUENCE OF SigningCert,
          (stuff deleted)

This is (only) a naming issue. :-)

A much more important concern is how to use the CertID content from ESS and
the CertID from the OCSP protocol altogether.

The current definition of CertID in ESS-08 is as follows:

     SigningCertificate ::=  SEQUENCE {
          certs        SEQUENCE OF CertID,
          policies     SEQUENCE OF PolicyInformation OPTIONAL
     }

   CertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
   }

   Hash ::= OCTET STRING -- SHA1 hash of entire certificate

   IssuerSerial ::= SEQUENCE {
        issuer                   GeneralNames,
        serialNumber             CertificateSerialNumber
   }

The current definition of CertID in OCSP-07 is as follows:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuer's public key
       serialNumber        CertificateSerialNumber }

One of the problems is that the current definition places limitations when
using both specifications.

A receiver of a signed message will be able to extract directly the
issuerSerial from the received message either from the CertID field or from
the issuerAndSerialNumber field contained in SignerInfo. It would be nice if
he would then immediately be able to ask to an OCSP server whether the
certificate is revoked or not. However, it can't.

He needs to obtain first the right issuerKeyHash, i.e. the hash of the
issuer's public key. For this he needs to fetch the certificate BEFORE making
the OCSP request AND to get the issuer public key. This can take long.

The goal is to be able to perform the operations in parallel or in whatever
order.

For this, what should be changed ? In which specification ?

I could end up the mail here. However, I will attempt to make a proposal which
is certainly not the single way to solve this issue. So other proposals
reaching the same goal are welcomed.

The idea is to optimise the cases where there is no name collisions for the
DNs of the CAs, without sacrifying any security. In case of name collision,
i.e. the same OCSP server supports two CAs with the same DN - which will be
very scarce in practice - performance will be much lower.

Let us redefine CertID in OCSP-07 is as follows:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING OPTIONAL,
                           -- Hash of Issuer's public key
       serialNumber        CertificateSerialNumber }

i.e. let us make the issuerKeyHash OPTIONAL in the OCSP request. This means
that the receiver can immediately construct its OCSP request and send it to
the OCSP server while fetching after or in parallel the certificate and the
issuer public key.

In order to make sure that the right issuer was indeed selected, the OCSP
server will have to include in its response the issuerKeyHash. Thus "after the
fact", i.e. after fetching the certificate and the issuer public key, the
receiver can check that he got the right response from the OCSP server. If
not, he will have to query again the OCSP server using the issuerKeyHash in
its request.

I would thus propose that we modify OCSP to make issuerKeyHash optional and
this we add some text to explain that issuerKeyHash is optional for the
request but mandatory for the response.

I would also propose that we use the term "SigningCert" in the ESS document.

Denis