RE: Candidate for moving OCSP to a Draft Standard

["Michael Myers" <myers@xxxxxxxxxxxxx>]

Dave,

Is your issue one of deployment or code-level implementation?
Because my intent was to drive into existence functionality that
MAY be deployed on an as-needed basis.  Note the text "provide
for".  That doesn't mean you have to use that functionality.  It
means that the server you use MUST be capable of such.

Mike


> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of
> David P. Kemp
> Sent: Tuesday, March 19, 2002 1:16 PM
> To: 'ietf-pkix@xxxxxxx'
> Subject: 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
>