Subject: Re: OCSP I-Ds going forward

From: "Tom Gindin" <[email-masked]>
Date: Tue, 26 Nov 2002 12:19:24 -0500

Denis:

      I had not read the entire draft in detail (I was responding to Mike's
message), and now I see why you did this.  However, IMHO expecting a
hash-only signature verification to be carried out in the OCSP responder is
overweight for its stated purpose (verifying the hash of either the issuing
certificate or the issuing key is sufficient) and involves extra
difficulties of implementation.  I will go into detail on both points.
      The responder needs to identify the applicable one of multiple CA
certificates with the same DN, but that does not require him to verify the
signature of the certificate.  To quote your own draft "When the OCSP
responder ..., it shall make sure that it is the right certificate."  One
can construct several cases in which the combination of issuer with serial
number does not uniquely identify a certificate.  Some relatively plausible
ones are: the operation of two independent CA's with the same DN, the
resumption of operation by a CA which has lost its record of serial numbers
issued while issuing them in (usually closely packed) ascending order, and
the coincidence of serial numbers between separate processes of a CA
running simultaneously.  These last two conditions are defects in the
operation of the CA, and they make it IMPOSSIBLE to distinguish revocation
of one of these two certificates from revocation of the other using CRL's.
All other scenarios in which the same issuer duplicates serial numbers (and
there are other though less plausible possibilities) will share this
problem.  So, irrespective of the other standards which rely on the
uniqueness of Issuer/Serial, only the case where there are two independent
CA's with the same DN permits any meaningful verification which would be
helped by further specification of the certificate.  Using a hash of either
the issuer's key or of his certificate is more efficient than performing a
signature verification, and just as effective in distinguishing between the
two conflicting CA's.
      The implementation difficulty is that some verification engines may
not have entry points to take a pre-computed hash, which would cause your
suggested technique to not be executable.  The java.security.Signature
class (as a prominent example) does not recommend support for using a hash
as the input data to signature or signature verification, and some
cryptographic providers follow those recommendations - although you could
write a provider that would support this mode of operation while complying
with that API.

            Tom Gindin

Denis Pinkas <[email-masked]> on 11/26/2002 07:26:14 AM

To:    Tom Gindin/Watson/IBM@IBMUS, Peter Gutmann
       <[email-masked]>
cc:    Michael Myers <[email-masked]>, [email-masked]
Subject:    Re: OCSP I-Ds going forward

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.

>       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

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

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 28 Nov 2002 13:04:58 +0100

Tom,

I picked up your e-mail but this e-mail is responding to many other e-mails 
from others on the same topic. So it is a very loooong e-mail.

> message), and now I see why you did this.  

:-)

 > However, IMHO expecting a

> number does not uniquely identify a certificate.  

Correct.

> Some relatively plausible
> ones are: the operation of two independent CA's with the same DN, 

This single example is sufficient.

 > the
> helped by further specification of the certificate.  

 > Using a hash of either

You are missing a point here. The main idea is to allow better performances.

With OCSP v1 the client needs first to build the path and then to check the 
revocation status of the certificate.

With OCSP v2 (using certIdWithSignature), the client may first check the 
revocation status of the certificate and then build the path, or can do both 
operations in parallel.

> write a provider that would support this mode of operation while complying

In order to understand the arguments, it is important to concentrate on what 
the OCSP responder does with the information from the request and what the 
client needs to do as well.

Let us first address the problem of the non-uniqueness of CA DNs
(not for you, but for the whole list).

Currently RFC 3280 does not say much about the issuer field:

    The issuer field MUST contain a non-empty distinguished name (DN).

  . (…)

    As noted above, distinguished names are composed of attributes.
    This specification does not restrict the set of attribute types
    that may appear in names.  However, conforming implementations
    MUST be prepared to receive certificates with issuer names
    containing the set of attribute types defined below.

This means that there is no constraints for a CA for the attributes that 
compose its DN.

So it is perfectly valid for a CA to have a DN with a single attribute and 
thus a DN with a common name like “Platinium CA”. Then two CAs around the 
world may perfectly pick that DN.

Of course a *single* immediately “superior CA” will never accept to issue 
two certificates for two CAs that are indeed different, but two different 
“superior” CAs can perfectly do it.

There are two possible ways to realize that these CAs, with the same DN name 
are different:

1° to consider the chain of DNs names formed by a certification path 
starting from a root CA and finishing with “Platinium CA”. It is similar to 
identify two files with the same name, but placed in a different directory. 
This technique is not optimum since the full path would need to be 
constructed first, and since additionally Peter objected to have a SEQUENCE 
of DNs, it has been discarded).

2° to consider the fact that the two “Platinium CAs” will necessarily get 
their certificates from two different superior CAs that have necessarily two 
different private keys. Hence the combination of the issuing key of superior 
CA + the DN of the CA is unique. This feature is used in OCSP v1, and this 
is not by accident.

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

issuerKeyHash, which is mandatory, allows the OCSP responder to uniquely 
identify the certificate. Certainly explanations are missing in RFC 2560 to 
say what should/shall be done with this field by the OCSP responder, but its 
presence is of primary importance (I believe that few people, except OCSP 
implementers, had paid attention to the reason for the presence of that 
field and to what should be done with it).

In OCSP v1, issuerKeyHash is used in combination with issuerNameHash and 
serialNumber.

We could also use the following combination:
issuerKeyHash + IssuerAndSerialNumber.

Let me explain, why this structure has *not* been proposed in the OCSP v2 draft.

Inserting issuerKeyHash in the request mandates the client to first build 
the certification path, so that it can know the value of the issuing public 
key of the certificate. This process may be quite long.

The idea is thus to allow to check first if the certificate is not revoked, 
without the need to build first the certification path. If the certificate 
is revoked, then it does not make sense to build the path.

Another way to look at the problem is in terms of performances, and to allow 
a client to check the certificate revocation status and to build the 
certification path in parallel.

In fact the burden of the path construction goes first on the OCSP responder.

Now let me explain again why certIdWithSignature is being used. It is 
following the same spirit like OCSP v1 where the OCSP responder has to make 
sure that the right issuer key is being used for the certificate that 
corresponds to a given IssuerSerial as defined in RFC2634 section 5.4.1.

This is obtained by verifying the digital signature of the certificate by 
providing the hash value of it and the signature value (and algorithm 
identifier). So the OCSP responder picks what it believes might be the right 
key and thus makes the signature verification of the certificate (full 
explanations are in my previous e-mail on that topic).

Now, ESSCertID is not a good vehicle either, because it mandates the client 
to build the path first. For that reason (and another one pointed by 
Ambarish when we were co-editing OCSP v2 about the use of CRLs in the back 
office) it has *not* been included either.

Finally let us go back to the signer’s point of view. A signer has always 
access to its certificate, but not necessarily relying parties. In RFC 3126 
ESSCertID was being used. The advantage is a short structure that uniquely 
identifies the certificate and can be easily locally computed by a signer 
and placed as a signed attribute. The disadvantage is that it mandates the 
relying party to first build the path.

So a new idea would be to recommend to include as a signed attribute of CMS: 
CertIdWithSignature instead of ESSCertD.

Note: there is a side advantage to this structure: there is no more a choice 
for the hash function. The one that is used is the one included in the 
signature algorithm of the certificate.

CertIdWithSignature can easily be locally computed by a signer and placed as 
a signed attribute. The other major arguments are :

   a) it also preserves the privacy of the signer, since the full
      certificate is not transmitted, and

   b) it is much shorter than the full certificate.

CONCLUSION

certIdWithSignature is flexible, since it allows a client to check first the 
revocation status of the certificate and then build the path, to do both 
operations in parallel or even in thd reverse order.

What has been mentioned above works in any case, including the case where an 
OCSP responder is a front-end of several OCSP responders or is only using 
CRLs and of course including the case where two CAs have the same DN.

If, and if only if [with a single if, the world could be rebuilt] we were 
considering different kinds of OCSP responders (and would be able to know in 
which category they play) then they are cases where IssuerAndSerialNumber is 
enough. At present, we have no feature in the protocol that allows to make 
this distinction, but this could be added.

Sorry for this long e-mail, but it seemed that theses explanations were needed.

Denis