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

[Andreas Berger <aberger@xxxxxxxxxxxxxxxx>]

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

Peter Sylvester wrote:
> > 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.
The is a very good assumption. While the authority key *may* be
available, it certainly isnīt always available.
 
> - to allow identification of a certificate in a given context
>   ==> 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.

> - 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.
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.

> - 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..

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