Subject: RE: OSCP BIG BANG

From: "Linn, John" <[email-masked]>
Date: Tue, 4 May 1999 11:20:11 -0400

I think that another point remains from Denis' comment, independent of the
suggestion to move information from leaf certificates to the CA certificate.
This concerns the CA conformance level for ability to include OCSP
accessLocation and accessMethod information in generated certificates, which
changed from MAY in -07 to MUST in -08.  Since the case of OCSP
accessLocations being locally configured, without need for
certificate-resident indicators, is explicitly allowed, I read the first
paragraph of 4.1 as appropriately conditional, not mandating that a CA be
able to include AIA extensions within environments where OCSP
accessLocations are to be configured locally.  I believe that the same
conditionality should apply to the second paragraph as well, covering
specific contents within the AIA, which -08 states as covering all CAs that
support OCSP services.

--jl

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 May 1999 12:26:11 -0400

John,

>specific contents within the AIA, which -08 states as covering all CAs that

The change from MAY to MUST was intentional. The notion is that a CA is
considered as OCSP compliant only if it is capable of putting the AIA
extension, with OCSP-specific values, into certs that it generates.  All
compliant OCSP clients MUST be locally configurable re OCSP servers, but
this is independent of what a CA does re OCSP, e.g., even if the CA puts in
the OCSP server pointer, the client is free to ignore it.

To maximize interoperability, we want it to be the case that if a CA
asserts OCSP compliance, then it MUST be able to generate certs that will
point to an OCSP server. Also, remember the difference between the CA being
ABLE to generate this extension, and actually puttiong it in certs. Only
the capability is required of the CA to be compliant; the election to  ake
use of the facilility is a local matter.  A CA that does not support this
use of AIA can still be PKIX compliant re 2459, just not compliant with the
OCSP RFC.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 04 May 1999 18:58:21 +0200

Steve,

My reply is along the lines.

> extension, with OCSP-specific values, into certs that it generates.

What do you mean here ? He is capable to do it, but it does not  ? This is a very
odd concept to me.

>  All

The case of OCSP client is different but is not the center of the discussion.

> point to an OCSP server.

I cannot understand the above sentence. Do you mean " MUST generate certs that
will point to an OCSP server" or "MAY chose not to generate certs that will point
to an OCSP server " ?

> Also, remember the difference between the CA being

The first question is whether a certificate, whose status may be queried using
OCSP, MUST always contain this extension or not. What is the answer ?

Then, according to this answer, the second question is : does this solve the "BIG
BANG" situation ?

Denis

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 May 1999 16:48:05 -0400

Denis,

>What do you mean here ? He is capable to do it, but it does not  ? This is

Yes, I do mean that the CA must be capable of generating such certs, but it
is a local matter as to whether such certs are, in fact, generated.  We are
manadting a capability for a compliant product, not usage constraints on
the product.

<snip>

>will point to an OCSP server" or "MAY chose not to generate certs that

I mean MUST be capable of generating such certs, as explained above.  Of
course the CA may choose not to do so, as a matter of local policy.  Again,
we are discussing what a product MUST be able to do in order to be
compliant, not how someone operating the CA must behave.

>OCSP, MUST always contain this extension or not. What is the answer ?

A CA may choose to not insert the extension in a cert, which presumes that
the clients will have local config info that allows them to locate one ore
more OCSP servers that they choose to rely on.  For example,

>Then, according to this answer, the second question is : does this solve

No, I have to admit that none of this addresses the BIG BANG scenario, any
more than that scenario was addressed in the initial OCSP draft.  Depending
on the environment, this may be a big problem, or it may be easy.  As John
Linn mentioned in his message, if the CA deals with a closed community,
then the local config option for clients can ease the transition and the CA
can issue new certs with the extension on a gradual basis.  A massive
reissuance may be needed in a completely open PKI, but that can be effected
in various ways, not just revocation of all the EE certs, e.g., one might
revoke the CA cert and reissue it as well as all of the EE certs.  One
might introduce new EE certs with the extension, and continue to maintain
CRLs, to smooth the transition.

So, unless the WG feels that the BIG BANG scenario is sufficiently critical
as to warrant a move of the AIA extension to the CA cert, from EE certs, I
feel that we should not re-open this issue.

Steve