Subject: Re: [pkix] OCSP handling of unrecognized critical extensions

From: Stefan Santesson <[email-masked]>
Date: Tue, 07 Sep 2010 19:47:49 +0200

I agree that the proposal overloads the "unauthorized response".

"The response "unauthorized" is returned in cases where the client is not
authorized to make this query to this server."

.. Is not the same as sending an unrecognized critical extension.

It sounds to me more like "malformedRequest" as it does not conform to the
OCSP syntax expected/implemented by the server.

Yeah, I know.. It is a bit of a stretch too, but perhaps a smaller one and
closer to what you would expect.

/Stefan

On 10-08-12 2:23 PM, "Kemp, David P." <[email-masked]> wrote:

> 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
> 
> 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?
> 
> On 08/11/2010 05:12 PM, Dr Stephen Henson wrote:
>> 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.
>>    
> 
>> On 11/08/2010 21:31, David A. Cooper wrote:
>>    
>>> 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")
>>> 
>>> 
>>> 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).
>>> 
>>> 
>>> 
>>> Thoughts?
>>> 
>>>      
>>    
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix