Subject: RE: OCSP identifiers

From: "Grant, Alistair" <[email-masked]>
Date: Mon, 11 Dec 2000 23:49:24 +1100

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:		[email-masked]
Phone:		+61 3 9825 5692
Mobile:		+61 408 565 080

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Thursday, November 30, 2000 5:34 AM
To: Stephen Kent
Cc: [email-masked]
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

---

From: Michael Myers <[email-masked]>
Date: Mon, 11 Dec 2000 09:18:58 -0800

Alistair,

We will be talking about these issues face to face later today and
throughout this week.  Will you be in San Diego to join us?  Taking up your
question by cases though, we have:

Many wireless environments are best enabled by use of a direct cert blob via
Certificate syntax rather than performing the ASN.1 parsing, hash
computation and ASN.1 construction necessary to produce certID.

Certain other wireless environments find use of a name via GeneralName
syntax more closely aligned with their PKI deployment requirements.

In the disjoint S/MIME case, it is intutively obvious to the casual observer
that use of IssuerandSerialNumber is a far more natural choice.

Use of IssuerandSerialNumber may also benefit the classic SSL, TLS and IPSEC
use cases.

Finally, the certHash option enables a fairly compact means of producing an
identifier against any form of certificate we know of today and any that may
be produced in the future.

By the way, this proposal *enables* environments to use these identifiers.
The requirements need to be sharpened in this area to ensure at least one
SHALL for interoperability purposes.  Myself, I would propose
IssuerandSerialNumber since it seems to be the single most widely deployed
identifier in the marketplace today.  Others may feel differently.

Any opinions then on this rationale?  And have you any further opinions on
the recent proposal to extend the response spectrum to include valid,
invalid, suspended and expired?

I fully agree with Simon's observation that zero length Issuer Key Hash
removes the need for the CA
certificate.  I had first brought this approach to the WG attention at the
most recent D.C. IETF.

I'm not yet sold that an extension-based approach is in the long run offers
any benefit over the CHOICE approach.  Could you elaborate on why you
believe this to be the case?

Mike

> From: Grant, Alistair [mailto:[email-masked]]
> Sent: Monday, December 11, 2000 4:49 AM
> To: [email-masked]
> Cc: Michael Myers; Ambarish Malpani; Simon Tardell