Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt

From: Peter Sylvester <[email-masked]>
Date: Fri, 18 Sep 1998 10:56:24 +0200

> > 
> 
> I actually think OCVP is a bigger thing than just making the hash
> of the issuer's PUBLIC key NULL. That whole topic should be
> addressed at one shot
> 
I am *not* really talking about OCVP, I am talking about 'CertID',
a short way to identify a certificate. The syntax
for the identification should be flexible enough  

- not to require more than the original certificate in
  order to construct the identification.

- to allow identification of a certificate in a given context
  ==> serial number for example or/and hash of cert

- to allow the OCSP provider to find the source of 
  information provider.
  ==> name of issuer may be necessary, hash of issuer name
      may not be sufficient. 

- to ensure that the creator of the certificate really has
  a copy of a cert.
  ==> hash of cert for example, or serialnumber if authority
      allocates them in a sparse way.

If we assume that the orginal version of OCSP where it was
possible to just have a cert did make sense, thus I do not
see why there is a need for the issuer public key extract 
in the certID. At least it should be optional in some way.

It seems useful to me to fix a syntax for CertID that
is sufficiently open for extensions without requiring
a new protocol version..

Peter

---

From: Andreas Berger <[email-masked]>
Date: Fri, 18 Sep 1998 12:06:44 +0200

I agree with this discussion and would like to add some thoughts:

>   order to construct the identification.
The is a very good assumption. While the authority key *may* be
available, it certainly isn´t always available.
 
>   ==> serial number for example or/and hash of cert
The serial number is a little bit weaker but supported by other parts of
X.509, PKIX and several mail protocols, using issuer/serial for
identification of a certificate. So issuer/serial or
issuer/certificate-hash look like valid combinations. It may be a good
idea to be able add a subject public key hash if necessary.

>   ==> name of issuer may be necessary, hash of issuer name
So for identification of issuer we probably have a choice of issuer-name
or issuer-hash, probably in combination with issuer-public-key or
issuer-public-key-hash as an optional parameter.

> is sufficiently open for extensions without requiring

The removal of the certificate proper as a means to "identify" a
certificate forced us to specify an extension to OCSP to do this
(transport the certificate in the request - optional, or in the reply -
optional). If the consensus is that OCSP should not be able to transport
the certificate proper, I think we should at least open the possibility
to transport a certitficate hash.

That leads me back to the idea of making a lot of the identification
parameters in "CertID" optional. But we will get serious
interoperability issues. So either we build specific CertIDs with
specific purposes in mind or we need some profiling (and probably a
means for the responder to transport valid combinations back to the
client).

Andreas
-- 
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 18 Sep 1998 17:14:48 -0700

Andreas,

I share your concerns.

The current definition of CertId is as follows:

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

CertID is used both in the request and in the response.
I would suggest to change it to:

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

making the issuerKeyHash optional.

The issuerKeyHash would be optional for a request but mandatory for
a response. The rational is as follows: the requester needs "at
some time" to get the public key of the issuer in order to verify
the certificate. If we mandate that field to be always present
thent it must get it *before* the request to the OCSP server. If we
make it optional, then it may get it before or after the request to
the OCSP server. This gives some flexibility, without too many
options.

The OCSP server should anyway have the Issuers public key and thus
its hash. The hash may allow the requester to disambigous some
responses in case of anonymity. 

Denis

-- 
 Denis Pinkas     Bull S.A.          mailto:[email-masked]
 Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
 78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21