RE: OCSP identifiers

[Michael Myers <MMyers@xxxxxxxxxxxx>]

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



> -----Original Message-----
> From: Grant, Alistair [mailto:Alistair.Grant@ca.com]
> Sent: Monday, December 11, 2000 4:49 AM
> To: ietf-pkix@imc.org
> Cc: Michael Myers; Ambarish Malpani; Simon Tardell
> Subject: RE: OCSP identifiers
> 
> 
> 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
>