Subject: Re: OCSP I-Ds going forward

From: "Tom Gindin" <[email-masked]>
Date: Mon, 25 Nov 2002 17:35:08 -0500

Mike:

      If the purpose of CertIdWithSignature is to extend IssuerSerial in a
way which is both unambiguous and compact, why are both the signatureValue
field and tbsCertificateHash present?  Either the signatureValue field or
the signatureAlgorithm/tbsCertificateHash combination should be unique.
IMHO there isn't much point in doing a signature validation based on an
asserted hash without access to the base certificate.

            Tom Gindin

"Michael Myers" <[email-masked]>@mail.imc.org on 11/25/2002 01:51:41
PM

Sent by:    [email-masked]

To:    <[email-masked]>
cc:
Subject:    OCSP I-Ds going forward

FYI all,

As many of you know, in March 2001 Carlisle, Stephen and I
proposed two OCSP-based services.  We called them Delegated Path
Validation (DPV) and Delegated Path Discovery (DPD).  That I-D
was allowed to lapse pending WG resolution of the DPV/DPD
requirements.  In Atlanta, I committed to the chairs to refresh
that I-D.

However, that I-D also addressed the separable need to expand
the certificate identification mechanisms.  This changed changed
core syntax, hence a v2 version number (i.e. OCSPv2).  To
complicate matters further, given that the original OCSPv2 I-D
was allowed to lapse, the certID/v2 issue has recently been
refreshed with yet another OCSP-based I-D that once more speaks
to v2-ness but also introduced yet another proposed
extension--the CRL Locator.

So to simplify matters for all of those in the WG that continue
to have the patience to review and comment on these things, two
new, unifying I-Ds are being produced and will be available
shortly.  This work will enable parallel and non-conflicting
consideration of the cert identification and DPV/DPD issues.

The first working document will be the "core".  It's primary
purpose is to enable consideration of alternative certificate
identification mechanisms.  It will propose a ReqCert syntax
that provides a CHOICE of: legacy-interoperable support for
2560's certID; full certificate (including ACs); the
CertIdWithSignature syntax as recently proposed; and
issuerAndSerialNumber as recently advocated by Peter Gutman.

The second working document will be a "Services and Extensions"
document.  It will include: the basic service of revocation
checking; all extensions as currently documented in 2560; the
new proposed CRL Locator extension; and the definition of DPV
and DPD services as originally proposed.  Thus, for OCSPv2, the
upcoming DPV/DPD question reduces to whether or not to retain
that related text in the S&E working document.

Following resolution of the DPV/DPD issue, both these working
documents will be reintegrated into a final I-D for WG last call
on what we want to call OCSPv2.

Mike

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 26 Nov 2002 13:26:14 +0100

Tom, Peter (Gutmann) and the list,

Explanations are provided in the draft (see after).

Peter, this mail also answers to the mail you just posted.

> asserted hash without access to the base certificate.

draft-ietf-pkix-ocspv2&ext-00.txt specifies:

certIdWithSignature is a more compact way to specify *unambiguously* a 
certificate.

    CertIdWithSignature ::= SEQUENCE {
         issuerSerial              IssuerSerial,
         tbsCertificateHash        BIT STRING,
         certSignature             CertSignature
    }

Page 19 contains the following text when using CertIdWithSignature:

     (...)
                                             However, two CAs
     might have the same DN and be certified under different
     branches of a certification tree.

     (...)

     When the OCSP responder does not have access to the data base
     of the issuer, then it may use either *CRLs* or the OCSP
     responder designated by the CA that has issued the certificate.

     When the OCSP responder does *not* have access to the data base
     of the issuers, then it *shall* first make sure that it is the
     right certificate.

     In the general case, this can be done by verifying the
     signature over that certificate.  For doing this, the OCSP
     responder first needs to build a certification path up to one
     of its trust anchors (without necessarily verifying the
     revocation status of the CAs from the path).  The presumed
     issuer key is then used to verify the signature of the
     certificate using both the tbsCertificateHash and the signature
     value. That issuer key will then be used to verify that this
     key is used to sign the *CRL* or the OCSP response, or the
     certificates issued to designate the CRL issuer or the OCSP
     responder.

So the answer to the question "why are both the signatureValue
field and tbsCertificateHash present" is:

It is needed when the OCSP responder is *only* using CRLs in the back 
office. signatureValue field and tbsCertificateHash MUST be both present so 
that the OCSP responder can verify the signature of the certificate. By 
doing this, possible ambiguities between identical CA names vanish: the 
right CA is being used by the fact that two CAs can't have the same issuing 
key.

This means that the OCSP responder must first find out the value of the 
issuing key. If it got the wrong value, the verification of the signature of 
the certificate will fail and the OCSP responder will either look for 
another one, or will say that it does not know.

Now, Peter, I am very sorry that you invested time to write 
draft-ietf-pkix-ocsp-sensible-id-00.txt "Sensible Identifiers for OCSP".

The big mistake is the text that you claim to be extracted from RFC 3369 and 
which is not:

    issuerAndSerialNumber uniquely identifies a certificate by the
    distinguished name of the certificate issuer and an issuer-specific
    certificate serial number [RFC 3369]

The right text is:

10.2.4  IssuerAndSerialNumber

    The IssuerAndSerialNumber type identifies a certificate, and thereby
    an entity and a public key, by the distinguished name of the
    certificate issuer and an issuer-specific certificate serial number.

RFC 3369 does NOT use the wording "uniquely identifies".

IssuerAndSerialNumber used alone does not work.

Now, let me also explain why using certHash alone does not work: it cannot 
work when the OCSP responder is *only* using CRLs, since certHash cannot be 
computed in that case (there is simply no access to the full certificate !).

Since clients are ignorant of the information used by the OCSP responder in 
the back office, they MUST always provide an unambiguous reference.

Your draft is not yet available on the IETF web server, but you will 
probably be a lucky winner anyway, since you might get a PKIX or an IETF 
record: the draft with the shortest life time in the history of PKIX and 
even, maybe, the IETF !  :-)

Now, I concur that these explanations are not straightforward for everybody.

So my question: the security considerations section already contains
the above explanations (and much more !). Are they insufficient ?
If insufficient, I would be happy to improve them. Text proposals are welcome.

Denis