Subject: RE: OCSP & Authority Information Access

From: Michael Myers <[email-masked]>
Date: Thu, 21 Jan 1999 08:05:53 -0800

Denis,

This response took a bit longer to get to.

> -----Original Message-----
> > You can operate your CA without using the noted extension and
> > still comply with the spec.
> 
> I would like that !
> 
> The text however says:
> 
> "CAs SHALL provide the capability to include the 
> AuthorityInfoAccess extension
> (defined in [PKIX1], section 4.2.2.1) in certificates that 
> can be checked using
> OCSP."
> 
> I have thus difficulties to interpret that sentence and 
> understand what the
> SHALL means.

It means the capability shall be there, but its use in any particular
circumstance is a matter of choice.  I would have preferred the simplicity
of a single way of doing things, but legacy effect considerations alone
warranted the wording of the requirement.

Mike

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 25 Jan 1999 14:42:47 +0100

Michael,

My comments are along the text.

> warranted the wording of the requirement.

Well, let me see ...

Suppose I propose a PKIX Part 1 compliant PKI issuing CRLs. My customer later
on decides to install an OCSP server. According to the wording it seems that
my PKIX Part 1 compliant software suite is no more compliant with the
standard. My customer might then complain that I provided him with a non
compliant software.

It seems to me that this sort of situations should not happen. We need to
revise the wording now or later.
At the minimum the SHALL "shall" be turned into a "SHOULD". I did not say  the
SHALL "should l" be turned into a "SHOULD".  :-)

Besides that point I also want to deprecate the use of such an extension in
leaf certificates. This this respect I am proposing again my previous text,
but changing the SHALL into a SHOULD:

" 4.1  Certificate Content

In order to convey to OCSP clients a well-known point of information
access, CAs SHOULD provide the capability to include the
AuthorityInfoAccess extension (defined in [PKIX1], section 4.2.2.1)
in their self-signed certificates (CA certificate) so that it can be
known that some or all the subjects certificates from that CA can be
checked using OCSP. Alternatively, the accessLocation for the OCSP
provider may be configured locally at the OCSP client."

Regards,

Denis