Subject: Re: Candidate for moving OCSP to a Draft Standard

From: [email-masked] (Peter Gutmann)
Date: Wed, 13 Feb 2002 06:49:23 +1300 (NZDT)

Al Arsenault <[email-masked]> writes:

>Further, what happens if, as Michael McIntosh suggested, the CA private key
>that issued the OCSP responder certificate is compromised, and the attacker
>creates a new OCSP responder (and points all new/bogus certificates to it).
>Now we have two communities, with two OCSP responders, each of which claims
>the OTHER is invalid.  How is this resolved?

In the same way that two monotheistic religions consign their believers to the
other side's hell for reason of heresy :-).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 8 Feb 2002 20:23:18 +1300 (NZDT)

"Khaja E. Ahmed" <[email-masked]> writes:

>This sounds like a perfectly reasonable solution. Surprised it was rejected.
>After-all this would be an optional extension, why not add it?  

The reasoning as I recall was that OCSP shouldn't include facilities which
aren't bug-compatible with CRLs.  Since CRLs can only provide a negative
response, and even that only for some cases of invalid certs, OCSP doesn't
include a straighforward yes/no indication.

(IMHO any poor guy who's stuck with feeding their online status service from
 offline CRLs has bigger things to worry about than this...).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 9 Feb 2002 07:06:33 +1300 (NZDT)

"Housley, Russ" <[email-masked]> writes:

>If the extension is specified in an IETF document, then I will gladly issue an
>OID from the PKIX arc.  Otherwise, it is a private extension, and it should
>not be issued an OID from the PKIX arc.

It's not specified anywhere, I'm just nervous about using private OIDs because
(historically) they've proven awkward for implementors to deal with because no-
one knows where they're defined.  This particular one's a bit of a grey area,
it's not specified in an RFC, but since others are going to use it it's not
really private either.  I'm not really fussed about it, it just seemed a bit
cleaner to have a well-known OID.

Peter.

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 19 Mar 2002 16:15:51 -0500

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