Subject: Re: [pkix] Revising OCSP - way forward

From: Stefan Santesson <[email-masked]>
Date: Thu, 01 Jul 2010 10:40:38 +0200

All,

As I have discussed with David, the problem and the reason why David
submitted this as an individual draft initially, is that the decision of
this WG was to create an update document (that updates RFC 2560).

The current draft is a "bis" document that replaces RFC2560.

The advantages with an update document is that it may show more clearly what
the changes are and that it may help limit the scope of work.

The advantage of a "bis" document is that the final product is easier to
use. The implementer has one document instead of a collection of documents
that defines the protocol.

Personally I agree with David that the advantages with a "bis" document in
this case are greater and hence I would support that we use this draft as a
starting point for the WG effort.

/Stefan

On 10-06-29 12:32 AM, "David A. Cooper" <[email-masked]> wrote:

> All,
> 
> I have created an initial draft of an update to RFC 2560.  It is
> available at http://www.ietf.org/id/draft-cooper-pkix-rfc2560bis-00.txt.
> 
> The main goal of this draft was to address confusion about the trust
> models supported by OCSP while avoiding introducing any technical
> changes to the protocol.  In order to facilitate incorporating the
> necessary changes to clarify the trust models, I reorganized the text in
> a way that I hope will improve the readability of the document.  I also
> adding a new Appendix with lots of informative examples (probably too
> many examples).
> 
> If this draft makes any technical changes to OCSP, then those were
> errors on my part.  I did, however, incorporate the changes from
> draft-ietf-pkix-ocspagility-08 and I also incorporated two changes from
> RFC 5019, The Lightweight Online Certificate Status Protocol (OCSP)
> Profile for High-Volume Environments.  The changes that were
> incorporated from RFC 5019 are clearly marked and include references to
> the sections in RFC 5019 that were the source of the change.
> 
> I plan to be at the next IETF meeting and to give a presentation on this
> draft.
> 
> While comments about the details of the draft are welcome, the initial
> question that needs to be answered (on the list and during the PKIX
> session at the next IETF meeting) is whether the working group feels
> that it is appropriate to use this draft as the starting point for
> developing the revision to OCSP.
> 
> Thanks,
> 
> Dave
> 
> On 05/26/2010 04:02 AM, Stefan Santesson wrote:
>> All,
>> 
>> Apology for taking time to get back to the list after the show of
>> hands request regarding the future handling of OCSP.
>> Steve has been on a few vacation and business trips over the last 2
>> months, and have been slowly catching up with PKIX list traffic.
>> 
>> After looking at the list traffic and discussing the issue we agree
>> that PKIX ought to update OCSP documentation (option 2), e.g., to deal
>> with the various ambiguities that folks have identified and to
>> incorporate the OCSP agility update. As folks noted on the list, we
>> want to keep this effort small, not open one or more cans of worms, so
>> the scope will be very limited.
>> 
>> David Cooper has done a great job on 5280, so we are happy to name him
>>  lead editor.  Stefan, as the lead editor of the agility document,
>> will also contribute, as we would like the update to incorporate that
>> document as well. Other folks who have offered to help are welcome to
>> do so.
>> 
>> In such case, send us and David a note. Otherwise expect a first draft
>> for discussion in a not to distant future.
>> 
>> Steve & Stefan
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 1 Jul 2010 11:26:25 +0200

I also support a "bis" document, rather than an update document.

Would it be possible to reserve or catch RFC number 6560 ? 

:-)

Denis

----- Message reçu ----- 
De : pkix-bounces 
À : David A. Cooper,[email-masked] 
Date : 2010-07-01, 10:40:38
Sujet : Re: [pkix] Revising OCSP - way forward

All,

/Stefan

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 01 Jul 2010 12:56:39 +0200

David A. Cooper wrote:
> [...]

Great

> [...] I also

It's good to have full information.
I do wonder a little however about giving so much details about some 
cases that serve to work around deficiencies of clients (I'm a bit 
afraid it ends up one day as being used to justify that the CA *should* 
have done that, and reverse the responsibilities). OTOH I'm all for 
explaining it can be done !

> [...] I also incorporated two changes from RFC 5019,[...]

Which includes :
    [...] an OCSP responder that can only provide
    pre-generated responses may send an error response when it does not
    have a pre-generated response that corresponds to the request.

Maybe it would be better to say that the error to send back is 
"unauthorized"  ?

Except if I missed something, a limitation of RFC5019 is that it does 
not say explicitly what a responder that only supports RFC5019 should do 
when it received a valid OCSP request that is not RFC5019 compliant. For 
exemple if the request contains several Request element, or includes 
singleRequestExtensions.

Would it be out of scope to precise this here ? Maybe as "a responder 
that does not support multiple Request should do this", "a responder 
that does not support singleRequestExtensions should do this" ...

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 07 Jul 2010 17:06:08 -0400

Rob,

Thanks for your comments.  I tried to clarify the use of the 
id-ad-ocspSigning OID in draft-cooper-pkix-rfc2560bis-00.txt, especially 
in Appendix D, which includes all of the examples.

I believe that relabeling the id-kp-OCSPSigning OID (RFC 2560 
incorrectly calls this id-ad-ocspSigning in 2 places, as does 
draft-cooper-pkix-rfc2560bis-00.txt) is outside the scope of what the 
working group agreed to do.  While relabeling an OID may seem minor, 
since it has no affect on the bits on the wire or the semantics of the 
protocol, it is my understanding that implementors prefer to avoid any 
unnecessary changes to the ASN.1 since it would change the code 
generated by ASN.1 compilers, which would force them to make 
corresponding changes in their source code.

I don't think it would be a good idea to include more details about the 
id-kp-OCSPSigning OID in 5280bis, but 5280bis could include a note that 
urges readers to see RFC 2560 (or an update to RFC 2560) for more 
information on the use of the id-kp-OCSPSigning OID.

Dave

On 06/07/2010 07:55 AM, Rob Stradling wrote:
> Hi Stefan, David.
>
> I tried posting this message to the pkix mailing list a few weeks ago, but for
> some reason it was rejected.
>
> I'd like to see some further clarification of when to (and when not to)
> use/require the id-ad-ocspSigning Extended Key Usage OID, because...
>
> 1. I've seen 2 major OCSP client implementations that have mistakenly required
> id-ad-ocspSigning to be present when the OCSP Response was signed by "the
> certificate of the CA that issued the certificate in question" (Section
> 4.2.2.2 Criteria 2).
>
> 2. I've seen 1 CA company (let's call them X) who, when using their widely
> distributed root certificate to issue a subordinate CA certificate to another
> CA company (let's call them Y), very nearly included id-ad-ocspSigning in the
> Extended Key Usage extension of the subordinate CA certificate, on the
> mistaken understanding that this was necessary for Y to be able to offer any
> kind of workable OCSP service.  (Y had to point out to X that this was
> unnecessary and would have enabled Y to sign OCSP Responses for various other
> certificates issued by X!)
>
> 3. I'm aware of 1 major OS that *by default* implements a "local configuration
> of OCSP signing authority" (Section 4.2.2.2 Criteria 1) by enabling an "OCSP
> Signing" trust bit for many of the root certificates that it ships with.  (The
> OS manufacturer is happy to do this at the simple request of a root
> certificate's owner).  This means, IINM, that each of these root certificates
> is *by default* an "Authorized Responder" for signing OCSP Responses for any
> certificate issued by any of the root certificates that the OS trusts!  I
> think this behaviour is certainly questionable and probably undesirable, and I
> think it may well have come about because of misunderstandings over what id-
> ad-ocspSigning is supposed to be used for.
>
> I suggest that "id-ad-ocspSigning" should be relabelled to something like "id-
> ad-delegatedOCSPSigning".  I think this might help to make it clear that it's
> intended to be used with Criteria 3, but is not required for the other
> Criteria.
>
> Also, I think the related wording in RFC 5280 Section 4.2.1.12 is also
> contributing to the confusion:
> "   id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
>     -- Signing OCSP responses"
> ...so I'd suggest changing this to "id-kp-delegatedOCSPSigning" and adding
> some verbosity to the comment if/when 5280 is updated.
>

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 08 Jul 2010 11:44:32 -0400

> exemple if the request contains several Request element, or includes

Section 2.3 of my draft says that a non-error response "MUST include a 
SingleResponse for each certificate in the request".  So, a responder 
that could only serve pre-generated responses and that had only 
pre-generated responses that each included only a single SingleResponse 
element could not provide a non-error response to a request that asked 
for status information for more than one certificate.  So, the responder 
could only provide an error response, and "unauthorized" (as extended by 
RFC 5019) would be the only appropriate error value.  Perhaps this could 
be more clearly worded in the text, but I just copied the definition of 
the "unauthorized" error response from RFC 5019.

As for extensions, unless the client includes a critical extension in 
the request (and RFC 2560 says that all extensions defined in that 
document should be marked as non-critical), the responder may simply 
ignore the presence of the extension in the request.

> that does not support singleRequestExtensions should do this" ...

I'm not sure.  As for support for a request that asks for status for 
more than one certificate, it seems that the responder should send back 
an "unauthorized" error response whenever it cannot create a valid 
non-error response and none of the other error responses 
(malformedRequest, internalError, tryLater, sigRequired) are appropriate.

As for support for extensions, I think the text is clear if the 
extensions are marked non-critical but it is less clear what to do in 
the case of an unrecognized critical extension (perhaps since no 
critical extensions have been defined).  My guess would be that an 
unrecognized critical requestExtension would result in an "unauthorized" 
error response and an unrecognized critical singleRequestExtension would 
result in a non-error response in which the certStatus for the 
certificate corresponding to the unrecognized critical 
singleRequestExtension would be "unknown".  However, this is just my guess.

So, for the moment, I would be hesitant to change the text to clarify 
either of these issues as others may consider such "clarifications" to 
be changes to the protocol.

Dave