Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-02.txt

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 30 Nov 2010 12:09:37 +0100

I have a further concern with the current draft about the nonce:

In RFC 2560, the text is not explicit enough:

   The nonce cryptographically binds a request and a response to prevent
   replay attacks. The nonce is included as one of the requestExtensions
   in requests, while in responses it would be included as one of the
   responseExtensions. In both the request and the response, the nonce
   will be identified by the object identifier id-pkix-ocsp-nonce, while
   the extnValue is the value of the nonce.

In the current draft proposal the text states:

   If the request included a nonce extension (Section 2.1.1.1) then the
   response MUST either omit the nonce extension or include a nonce
   extension that has the same value as the nonce extension in the
   request.
   An OCSP responder MAY include a nonce extension in a response even if
   no nonce extension was included in the corresponding request. 

In RFC 3161, a nonce is also used with the following text:
   The nonce, if included, allows the client to verify the timeliness of
   the response when no local clock is available.  The nonce is a large
   random number with a high probability that the client generates it
   only once (e.g., a 64 bit integer).  In such a case the same nonce
   value MUST be included in the response, otherwise the response shall
   be rejected.

The basic idea is that if a nonce is present in the request, then it MUST be present in the response.
Unfortunately, this is not what the current drat proposal is saying.

I would thus propose the following text replacement:
   The nonce, if included, allows the client to verify the timeliness of
   the response when no local clock is available. The nonce is a large
   random string of octets with a high probability that the client generates
   it only once.  
   If the request includes a nonce extension (section 2.1.1.1), then the
   response MUST include a nonce extension that has the same value as 
   the nonce extension in the request, otherwise the client SHALL reject 
   the response.
   An OCSP responder MAY include a nonce extension in a response even if
   no nonce extension was included in the corresponding request. 
Denis

---

From: Rob Stradling <[email-masked]>
Date: Tue, 30 Nov 2010 11:49:26 +0000

> I have a further concern with the current draft about the nonce:
<snip>
> The basic idea is that if a nonce is present in the request, then it MUST
> be present in the response. Unfortunately, this is not what the current
> drat proposal is saying.
<snip>
>    the nonce extension in the request, otherwise the client SHALL reject

Hi Denis.  I cannot support this proposal, because it would cause problems for 
OCSP Responder implementations that use pre-generated Responses.

Consider these two paragraphs from RFC5019:

"  In the case where a responder does not have the ability to respond to
   an OCSP request containing a option not supported by the server, it
   SHOULD return the most complete response it can.  For example, in the
   case where a responder only supports pre-produced responses and does
   not have the ability to respond to an OCSP request containing a
   nonce, it SHOULD return a response that does not include a nonce."

"  Clients that opt to include a nonce in the
   request SHOULD NOT reject a corresponding OCSPResponse solely on the
   basis of the nonexistent expected nonce, but MUST fall back to
   validating the OCSPResponse based on time."

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 30 Nov 2010 15:10:42 +0100

Rob,

Pre-computed responses is one possibility, hence all OCSP servers do not need to support it.

RFC 2560 addresses that case in section 2.5:
   
   OCSP responders MAY pre-produce signed responses specifying the
   status of certificates at a specified time. The time at which the
   status was known to be correct SHALL be reflected in the thisUpdate
   field of the response. The time at or before which newer information
   will be available is reflected in the nextUpdate field, while the
   time at which the response was produced will appear in the producedAt
   field of the response.

The basic question is the following: how can a client know that an OCSP server is supporting pre-produced responses ?
One necessary but insufficient condition is whether the (optional) nextUpdate field is present.
In fact, it seems that the only way is to locally configure a client to accept or reject pre-produced responses.

RFC 5019 also states: 
   Because this profile specifies that clients SHOULD NOT include a
   requestExtensions structure in OCSPRequests (see Section 2.1),
   clients MUST be able to determine OCSPResponse freshness based on an
   accurate source of time.  

A a consequence, OSCP clients locally configured to accept pre-produced responses SHOULD NOT use nonces.

The behaviour of an OCSP client will be different whether it supports pre-produce signed responses or not.  
If it does, it will never use nonces in its requests. If it does not, it may use nonces in the request.

RFC 5019 allows to consider responders that only support pre-produced responses, which implicitely means 
that there may exist a category of OCSP servers which never support pre-produced responses.

The behaviour of an OCSP responder may then be be different whether it supports pre-produce signed responses or not.  
If it does, it will never use nonces in its response. If it does not, it may use nonces in the response.

As a consequence, I would propose the following text:

   OCSP clients locally configured to use nonces, SHALL include a nonce extension
   in the request and SHALL check that the response includes a nonce extension 
   that has the same value as the nonce extension in the request, otherwise they SHALL
   reject the response.
 
   OCSP clients locally configured to use a local clock for testing the freshness of 
   the response or locally configured to accept pre-produced responses SHALL not use 
   a nonce extension in the request.

   The nonce extesion, if included, allows the client to verify the timeliness of

I wonder whether the following text is still useful:
   An OCSP responder MAY include a nonce extension in a response even if
   no nonce extension was included in the corresponding request.

If it is, in which case ?
Final note: there is an error in RFC 5019. The text states:

   If the nextUpdate field is present, the client MUST ensure that it is
   not earlier than the current time.  

The nextUpdate field must always be present, thus the sentence is incorrect.

Denis
---------- 
De : Rob Stradling 
À : pkix,denis.pinkas 
Date : 2010-11-30, 12:49:26
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-02.txt

<snip>
<snip>

Rob Stradling

---

From: Rob Stradling <[email-masked]>
Date: Tue, 30 Nov 2010 14:43:38 +0000

Is RFC2560bis intended to update, obsolete or break compatibility with RFC5019 
?

On Tuesday 30 November 2010 14:10:42 Denis Pinkas wrote:
> The basic question is the following: how can a client know that an OCSP
> server is supporting pre-produced responses ? One necessary but
> insufficient condition is whether the (optional) nextUpdate field is
> present. In fact, it seems that the only way is to locally configure a
> client to accept or reject pre-produced responses.
> 
> RFC 5019 also states:
> The behaviour of an OCSP client will be different whether it supports
> pre-produce signed responses or not. If it does, it will never use nonces
> in its requests. If it does not, it may use nonces in the request.
> 
> RFC 5019 allows to consider responders that only support pre-produced
> responses, which implicitely means that there may exist a category of OCSP
> servers which never support pre-produced responses.
> 
> The behaviour of an OCSP responder may then be be different whether it
> supports pre-produce signed responses or not. If it does, it will never
> use nonces in its response. If it does not, it may use nonces in the
> response.
> 
>    OCSP clients locally configured to use nonces, SHALL include a nonce
> extension in the request and SHALL check that the response includes a
> nonce extension that has the same value as the nonce extension in the
> request, otherwise they SHALL reject the response.
> 
>    OCSP clients locally configured to use a local clock for testing the
> freshness of the response or locally configured to accept pre-produced
> responses SHALL not use a nonce extension in the request.
> 
>    The nonce extesion, if included, allows the client to verify the
> timeliness of the response when no local clock is available. The nonce is
> a large random string of octets with a high probability that the client
> generates it only once.
> Hi Denis. I cannot support this proposal, because it would cause problems
> for OCSP Responder implementations that use pre-generated Responses.
> 

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 30 Nov 2010 16:01:13 +0100

RFC 5019 is a profile of RFC 2560 to be used only in the context of pre-computed OCSP responses.

In particular, it questionable whether the following sentence from RFC 5019 is correct since RFC 5019 
is focussing on pre-computed OCSP responses and this sentence is out of this context.

"Clients that opt to include a nonce in the
request SHOULD NOT reject a corresponding OCSPResponse solely on the
basis of the nonexistent expected nonce, but MUST fall back to
validating the OCSPResponse based on time."

Maybe "technical errata" will be needed on it.

Denis
---------- 
De : pkix-bounces 
À : denis.pinkas 
Date : 2010-11-30, 15:43:38
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-02.txt

On Tuesday 30 November 2010 14:10:42 Denis Pinkas wrote:
> ¨¤ : pkix,denis.pinkas

Rob Stradling

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Rob Stradling <[email-masked]>
Date: Tue, 30 Nov 2010 15:16:34 +0000

> pre-computed OCSP responses.

I read RFC 5019 to "permit...OCSP response pre-production and distribution", 
not require it.

> In particular, it questionable whether the following sentence from RFC 5019
> is correct since RFC 5019 is focussing on pre-computed OCSP responses and
> this sentence is out of this context.
> 
> Is RFC2560bis intended to update, obsolete or break compatibility with
> RFC5019 ?
> 
> > responses, which implicitely means that there may exist a category of
> > OCSP servers which never support pre-produced responses.
> > 
> > > The basic idea is that if a nonce is present in the request, then it
> > > MUST be present in the response. Unfortunately, this is not what the
> > > current drat proposal is saying.
> > 
> If you have received this email in error please notify the sender by
> replying to the e-mail containing this attachment. Replies to this email
> may be monitored by Comodo for operational or business reasons. Whilst
> every endeavour is taken to ensure that e-mails are free from viruses, no
> liability can be accepted and the recipient is requested to use their own
> virus checking software.

Rob Stradling

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 30 Nov 2010 08:11:00 -0800

>In RFC 3161, a nonce is also used with the following text:

Why are you mixing up a timestamp protocol with a real-time protocol?

>I would thus propose the following text replacement:

Why are you trying to make a major change in the protocol instead of just adding text that says "if you wanted a fresh response and the response didn't have your nonce, you didn't get what you wanted"?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 30 Nov 2010 17:32:59 +0100

Hi Paul,

The time-stamp protocol and the OCSP protocol are both on-line protocols that share a same concern: to detect replay attacks.

Both protocols allow for the use of a nonce which is very simple to use: same value in the response and in the request.
Using a clock is not always possible and in any case more difficult since there is a need to use a clock skew (2 seconds, 30 seconds, one minute ?).

Then, what kind of checks should be done whether the client accepts or not pre-computed responses ?
Since the checks are different, a given client should be especially configured to accept pre-computed responses. 
The current text is silent about this difference.

RFC 2560 was not precise, adding clarifications does not necessarilly mean major changes.

If the response does not include the nonce and the client only supports nonces, then there would be an interoperability problem: 
we would be breaking the existing protocol.

Denis
---------- 
De : pkix-bounces 
À : denis.pinkas,pkix 
Date : 2010-11-30, 17:11:00
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-02.txt

--Paul Hoffman, Director
--VPN Consortium

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 30 Nov 2010 12:23:28 -0500

Denis,

You are again proposing a change in the protocol.  RFC 2560 states that
responders are not required to support the nonce extension.  Section
4.1.2 says:

Support for any specific extension is OPTIONAL. The critical flag

SHOULD NOT be set for any of them.  Section 4.4 suggests several

useful extensions.  Additional extensions MAY be defined in

additional RFCs. Unrecognized extensions MUST be ignored (unless they

have the critical flag set and are not understood).

Section 4.4 says that "Support for all extensions is optional for both
clients and responders."

As Rob noted, changing 2560bis to require clients that include nonces
in their requests to reject responses that don't include nonces would
make RFC 5019 inconsistent with 2560bis, since RFC 5019 permits clients
to include a nonce in a request but states that clients should not
reject a response solely because it does not include a nonce.  RFC 5019
says:

Clients SHOULD NOT include the requestExtensions structure.  If a

requestExtensions structure is included, this profile RECOMMENDS that

it contain only the nonce extension (id-pkix-ocsp-nonce).

Clients that opt to include a nonce in the

validating the OCSPResponse based on time.

The text that you proposed for 2560bis said:

the response.

If this text were used in 2560bis, then the profile (RFC 5019) would be
inconsistent with the base standard.

On 11/30/2010 09:10 AM, Denis Pinkas wrote:

A a consequence, OSCP clients locally configured to
accept pre-produced responses SHOULD NOT use nonces.

The behaviour of an OCSP client will be different whether it
supports pre-produce signed responses or not.

If it does, it will never use nonces in its requests. If it does
not, it may use nonces in the request.

Can you please point to the text in RFC 2560 (or RFC 5019) that says
that a client that is willing to accept pre-produced responses will
never include a nonce in its request?

OCSP
clients locally configured to use nonces, SHALL include a nonce
extension

reject the
response.

As noted above, there is no such requirement in RFC 2560 and including
this requirement in 2560bis would make the RFC 5019 profile
inconsistent with the base standard.

OCSP
clients locally configured to use a local clock for testing the
freshness of

Where is the text in RFC 2560 (or RFC 5019) to support the existence of
this requirement?

The nonce extesion, if included,
allows the client to verify the timeliness of

random string of octets with a high probability
that the client generates

it only once.

Where does RFC 2560 state that the nonce MUST be a "large random
string"?

If the request includes a nonce extension
(section 2.1.1.1), then the

response MUST include a nonce extension that has the
same value as

the nonce extension in the request,
otherwise the client SHALL reject

the response.

Where does RFC 2560 impose this requirement?  If RFC 2560 did impose
this requirement, then why did RFC 5019 say:

Clients that opt to include a nonce in the

validating the OCSPResponse based on time.

An OCSP responder MAY include a nonce extension in
a response even if

no nonce extension was included in the
corresponding request.

RFC 5019 specifically states that this may occur:

Clients that do not include a nonce in the request MUST ignore any

nonce that may be present in the response.

Appendix A of draft-ietf-pkix-rfc2560bis-02 explains why a responder
may include a nonce in a response even if the request did not include a
nonce.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 30 Nov 2010 09:43:14 -0800

>The time-stamp protocol and the OCSP protocol are both on-line protocols that share a same concern: to detect replay attacks.

No, they don't. You may wish them to, but they don't.

>RFC 2560 was not precise, adding clarifications does not necessarilly mean major changes.

True, and irrelevant to your proposal to force nonces in responses.

>we would be breaking the existing protocol.

That seems absurd. Can you name a single deployed OCSP client that supports nonces that has an interoperability problem when it receives a pre-computed response? I would want to investigate this further.

--Paul Hoffman, Director
--VPN Consortium