[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Candidate for moving OCSP to a Draft Standard



Ambarish,

Section 3.1 of RFC 2560 (unchanged in draft -03) includes the following:

   CAs that support an OCSP service, either hosted locally or provided
   by an Authorized Responder, MUST provide for the inclusion of a value
   for a uniformResourceIndicator (URI) accessLocation and the OID value
   id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.

This requirement prohibits local elements (i.e. LAN administrators) from
operating Authorized Responders, because every LAN URI would have to be
included in every EE certificate.  There are potentially hundreds or
thousands of local elements that may wish to operate Authorized Responders
(although I expect that isn't part of your business model :-), and it
would be completely impractical to list them all in each EE certificate.

>From a security perspective, the thing that distinguishes a Trusted
Responder from an Authorized Responder is the existence of the delegation
certificate described in section 2.6.  AIA is an operational convenience
that allows clients to find responders without needing additional
configuration information.  It (AIA) is not security-critical.

I request that the MUST in section 3.1 be changed to MAY.  Leaving it
at MUST imposes a severe and unnecessary restriction on the possible
operational scenarios.

Regards,
Dave




Ambarish Malpani wrote:
> 
> Hi Guys,
>     Here is a candidate for moving OCSP to a Draft Standard. There
> are no changes in the bytes that go across the wire - basically all
> clarifications.
> 
> A list of all the changes between this document and RFC 2560 are
> in Appendix D (reproduced here).
> 
> I hope we can get to the Draft Standard state before this IETF.
> 
> Regards,
> Ambarish