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

From: Dan Weinstein <[email-masked]>
Date: Fri, 18 Sep 1998 01:41:01 -0700

>some remarks about the lastest OCSP draft:
>
>- It seems that the remarks about not knowing the public
>  key of an issuer are not addressed. 
>
>  It seems sufficient to ME to allow that the
>  hash of the issure private key MAY be a length 0 octet string,
>  something like that, or one might add the public
>  key of the OCSP responder instead. 
>
>  Thoughts?

I thought the issue with this was that in a case of a request where the
certificate was sent in place of the certID, a response could not be
formed unless the responder already had the issuer cert (or at least
knew its key hash).  This has been dealt with, since request now must
have a certID for each requested cert.  Was there some additional issue
I wasn't aware of?

Dan Weinstein
[email-masked]

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 18 Sep 1998 11:02:53 +0200

> have a certID for each requested cert.  Was there some additional issue

The original text provided to USE a certificate and nothing else
to form a request. This is no longer possible.

CertID in its current form cannot be used as a replacement for a
certificate in the case where the client does not have the issuer cert.
 
The syntax for CertID has not been discussed in the context where
this is the ONLY way to identify a cert. 

Peter

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 18 Sep 1998 17:41:07 +0200

I support the suggestion from Denis.

I suggest that one adds an optional hash of the certificate.
it MAY be returned by the OCSP server, and it MAY be
requested by the OCSP server. one could use the now obsolete
error code certrequired (rename it certhashrequired).

Whenever a client actually has the cert I would expect that
it always sets the certHash in the request, the OCSP server
may remove the certHash in the response if the certHash
value was not used in order for identification, e.g. when
only the serialNumber was used. 

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

   }

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 20 Sep 1998 19:41:28 +0200

> All,
You :-) ,

> 
> The intent was to provide an alternative to CRLs.  Following that model,
> there's an underlying assumption that the end-entity is in possession of
> the CA's certificate (as would be needed to validate the signature on a CRL.)
This is a description that is somewhat strange.

What is an alternative to CRLs? Read part1 of pkix. An alternative is 
something that replace completely the usage of CRLs. CRLs by definition
are one means to detect revoked certs, YOUR intention was to have just
access to a remotely manged CRL. 

There has been a lot of discussion that OCSP is a service that allows
what it says in its definition, online status verification, and not just
lookup of a remote CRL base. A lot of effort has been made to ensure that
a minimal OCSP service can actually implemented using CRLs, otherwise
one may have just used a certHash in the request, and not used the
serial number.

Anyway, an alternative has not a defined model, so what do we have to follow?
And why is there any underlying model. This is NOT documented in OCSP, and
the contrary seems to be indicated in pkix part 1. 

Splitting a local logic that looks into a list a CRLs into a client server
protocol MAY require additional security (as it is mentioned in pkix part1).

You MAY require that a request an a response to be signed by requestor
and the responder sign the response. A server MAY require that the client
proves in some way that it is actually in possession of a cert, or
whatever else you can image. 

Or: CRLs are ONE way to obtain status information of certs OCSP is not
a client server implemention of CRL lookup but a general mecanism to
obtain status information about certificates, and it CAN be implemented
using just CRLs on the server side but it is open to provide MORE service.

> 
> OCSP never had a requirement to validate an end-entity certificate in the
> absence of the CA certificate at the requestor end.  It's not just a
> requirement on syntax at the request.  This would also imply path
> validation logic on the server.  The consensus has been conclusively
> established that full certificate validation is beyond the scope of this
> protocol.
> 
The first version of the protocol allowed just to present a certificate
in a request. Whether the client actually has the corresponding cert
before or after the validation is left to the client.

Denis proposal does not put any requirement for path validation on the 
server, on the contrary,

The server otherwise tell: I know about ONE CA and it's public key hash
is what I return in the response. It the request needs to contain a key
hash, the server MUST validate the public key in order to return 'unknown'
if it doesn't match. Thus, in some sense the actual text requires
validation on the server, and Denis' proposal removes that requirement. 

The only TECHNICAL problem that can happen is that the server KNOWS about
more than ONE certificate having the SAME serial number and the same CA name.
In this case the server should return the status of all of them, 
and let the client decide. 

> There's consequently no need to alter the request syntax.

You can always deduce everything from an empty or false premises.

Peter