John,

>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.

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