Subject: [pkix] OCSP handling of unrecognized critical extensions

From: "David A. Cooper" <[email-masked]>
Date: Wed, 11 Aug 2010 16:31:05 -0400

All,

As I noted during my presentation on the update to OCSP 
(http://www.ietf.org/proceedings/78/slides/pkix-2.pdf), one issue that 
has been raised is that RFC 2560 does not specify how OCSP responders 
should respond to a request that includes an unrecognized critical 
extension.  This is mainly a theoretical issue (at least at the moment) 
since all extensions defined so far are intended to be marked as 
non-critical, but the update to RFC 2560 should address this anyway.

Does anyone know if any existing code has been written to cover this 
scenario and if so what it would do?

In the absence of any input about current practice, I suggested the 
following behavior:

1) If the requestExtensions field of a request includes an unrecognized 
critical extension, then the responder must return an "unauthorized" 
error response.  (This is based on RFC 5019's extension of the 
definition of "unauthorized")

2) If the singleRequestExtensions field of a Request includes an 
unrecognized critical extension, then the CertStatus for that 
certificate must be "unknown".  (OCSP responders that only provide 
pre-generated responses may instead return an "unauthorized" error 
response).

These changes would be added the the document as follows:

1) In Section 2.2.1, the definition of "unauthorized" would be changed to

    o  unauthorized: the client is not authorized to make
        this query to this server, the request includes an
        unrecognized critical extension, or the server is
        otherwise not capable of responding authoritatively
        (cf. [RFC5019], Section 2.2.3).

2) In Section 2.3.1, the description of "unknown" would be changed to:

    A status of "unknown" indicates that the responder doesn't
    know about the certificate being requested or the
    singleRequestExtensions field in the Request corresponding
    to this CertID included an unrecognized critical extension.

Thoughts?

Dave

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 11 Aug 2010 22:12:55 +0100

>        (cf. [RFC5019], Section 2.2.3).

A potential issue with "unauthorized" is that the response is unsigned and could
be produced by an attacker.

Consider a a client requesting some future capability using a critical
extension, seeing an unauthorized response and then falling back to a request
without that extension.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 11 Aug 2010 17:26:47 -0400

This is true.  It also further overloads the definitions of 
"unauthorized" and "unknown", leaving a greater degree of uncertainty 
for the client as to why the given response was returned.  But, is there 
a better alternative given the current protocol?

---

From: "C.J. Adams-Collier KF7BMP" <[email-masked]>
Date: Wed, 11 Aug 2010 14:38:44 -0700

> extension, seeing an unauthorized response and then falling back to a request

Would it be possible for a list member to give me the name of a
reference OCSP implementation (preferably one in the public domain or
released under a DFSG-compliant license), so that I can exercise the
graceful degradation of functionality as critical extension recognition
is disabled?

Thanks in advance,

C.J.

-- 
0xBA27A83C
[email-masked]
+1 206 226 5809
Member, Collier Technologies LLC
KF7BMP

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 12 Aug 2010 00:05:43 -0700

> extension, seeing an unauthorized response and then falling back to a request

If the client is willing to fall back, that's what a non-critical
extension is for.

-- 
Matt

---

From: "Todd E. Johnson" <[email-masked]>
Date: Thu, 12 Aug 2010 07:25:48 -0400

I can't speak to the specific license type, but there is the OpenCA 
OCSPD Project:

http://www.openca.org/projects/ocspd/

It is built upon OpenSSL.

I know Max has posted here from time to time, perhaps he could provide 
more info.  I recently sent him a patch to address an issue with digests 
which I can make available if needed.

I believe he is working on an updated release...

On 08/11/2010 05:38 PM, C.J. Adams-Collier KF7BMP wrote:
> <http://keyserver.colliertech.org:11371/pks/lookup?op=vindex&search=0x8E562765BA27A83C>
> [email-masked] <mailto:[email-masked]>
> +1 206 226 5809
> <http://www.colliertech.org/index.php/Main_Page>
> KF7BMP
> <http://wireless2.fcc.gov/UlsApp/UlsSearch/license.jsp?licKey=3091240>
>
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

-- 

Regards,

Todd E. Johnson

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 12 Aug 2010 13:39:16 +0200

EJBCA, http://ejbca.org/ also has an OCSP responder. It uses LGPL license.
I'm not sure how critical extensions are handled.

Regards,
Tomas

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 12 Aug 2010 08:23:14 -0400

I guess that is an argument for being more meticulous when creating
ASN.1 definitions.  Because OCSPResponseStatus is missing three
characters (an ellipsis ... after "unauthorized(6)") the original
protocol does not explicitly state that the ENUMERATED list is
extensible.

But the rules of extensibility in effect for '88 ASN.1 permitted new
elements at the end of SETs/SEQUENCEs, as well as new ENUMERATED values
without inclusion of an ellipsis.  Could it be argued that RFC 2560,
being written in '88 ASN.1, permits definition of new ENUMERATED
Response Status values just as it permits new extension OIDs?   The
scope of RFC 2560bis may arguably not permit such a change to that
document, but if not it should also NOT define an overloaded
interpretation of "unauthorized" precisely so any new document defining
a critical extension COULD define an "unrecognized critical extension"
status code.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David A. Cooper
Sent: Wednesday, August 11, 2010 5:27 PM
To: Dr Stephen Henson
Cc: [email-masked]
Subject: Re: [pkix] OCSP handling of unrecognized critical extensions