RE: OCSP identifiers

["Grant, Alistair" <Alistair.Grant@xxxxxx>]

Hi Mike,

Would you please provide a summary of why multiple certificate identifier
formats are required in OCSPv2, overall and for each proposed identifier.
In particular using CertHash seems problematic as it forces the responder to
provide additional indexes for looking up certificates.

Without sufficient justification (which I have not yet seen), I would add my
voice to those opposing the additional identifiers (Simon Tardell, Ambarish
Malpani, etc).  

Simon Tardell's suggestion of keeping the current CertId and adding an
extension to check issuance seems like a better alternative.

As Simon has said, a zero length Issuer Key Hash removes the need for the CA
certificate.  In combination with Simon's extension the client can still be
confident that the correct certificate is being identified.

The wording for good/revoked/unknown discussion, as raised by Ambarish, does
not seem to have been closed.



Cheers,

Alistair Grant
E-Mail:		Alistair.Grant@ca.com
Phone:		+61 3 9825 5692
Mobile:		+61 408 565 080


-----Original Message-----
From: Michael Myers [mailto:MMyers@verisign.com]
Sent: Thursday, November 30, 2000 5:34 AM
To: Stephen Kent
Cc: ietf-pkix@imc.org
Subject: RE: OCSP identifiers


Steve,

It's our objective to amend RFC 2560's certID syntax while preserving all
that RFC 2560 has established.  I have always presumed this would lead to a
new RFC number.  We're doing so in order to address known needs to expand
the means by which certificates can be identified in the OCSP bit stream.
Alternatively, we could editorially amend RFC 2560 and so move it from
proposed to draft.  As briefed in Pittsburg however, many of us believe it's
best to take the former course of action.

To that end, the v2 certID syntax is amendend in a fashion that enables v1
interoperability.  Further, both OCSPv2 servers and clients are required to
be capable of backwards interoperablity with their v1 peers.  There's no
need to deprecate the use of v1 if the original certID syntax satisfies
local requirements.  It's only when environments wish to, say, use CMS's
IssuerandSerialNumber vs. original certID that use of the v2 version number
in the bit stream is required.  Other than that,  it's precisely the same
protocol, simply amended to enable its use in other contexts.

Hope that clarifies things.

Mike