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

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 1 Dec 2010 11:50:11 +0100

David,

Nowhere in RFC 2560, it is said that OCSP clients must have a local clock available synchronized with UTC.
Those clients that have no such local clock, will use the nonce to detect replay attacks. Since those clients 
have no clock then cannot use a fallback position which requires a clock.

For those clients, if the OCSP server does not support the nonce extension, then these OCSP clients will not be able to work.
RFC 5019 mandates a clock synchronized with UTC which is necessary for the verification of pre-computed responses. 
RFC 5019 is only a special case of RFC 2560.

I agree with you, that I omitted to consider the fact that, in my text proposal, the nonce extension is OPTIONAL for the server.

So basically my text proposals require some changes. I would propose for RFC 2560bis:

   If the request includes a nonce extension (section 2.1.1.1) and the response does not include 
   a nonce extension that has the same value as the nonce extension in the request, then client 
   SHALL reject the response.

You asked the question: "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?"

RFC 5019 states:  "Clients SHOULD NOT include the requestExtensions structure".

In fact, the validation of pre-produced responses mandates the use of a local clock synchronized with UTC, 
hence why any test or verification related to the nonce extension present in a response is useless in the context of RFC 5019.

I now copy and paste three parts of your email below:

Part 1:

   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.

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

[Denis] RFC 5019  states:

   Clients MUST check for the existence of the nextUpdate field and MUST
   ensure the current time, expressed in GMT time as described in
   Section 2.2.4, falls between the thisUpdate and nextUpdate times.  If
   the nextUpdate field is absent, the client MUST reject the response.

By implication, nonces are not used or are useless in the context of RFC 5019.

A better wording for backwards compatibility would be :

   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 even if present in the response.

Part 2:
   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.
Where does RFC 2560 state that the nonce MUST be a "large random string"?

[Denis] It comes from the (new) ASN.1 structure where the nonce syntax is not an INTEGER but an OCTET STRING.

Part 3:

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 ?

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.

[Denis] Thank you for the explanation. I would then propose to melt the two sentences together:

   An OCSP responder MAY include a nonce extension in a response even if
   no nonce extension was included in the corresponding request. In such a case,
   clients that do not include a nonce in the request MUST ignore any
   nonce that may be present in the response.

Denis
----- Message reçu ----- 
De : David A. Cooper 
À : Denis Pinkas 
Date : 2010-11-30, 18:23:28
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-02.txt

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
   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.

The text that you proposed for 2560bis said:

   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.

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?

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.

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 
   the response or locally configured to accept pre-produced responses SHALL not use 
   a nonce extension in the request.

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
   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.  

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
   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.

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 ?

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: Rob Stradling <[email-masked]>
Date: Wed, 1 Dec 2010 11:04:45 +0000

On Wednesday 01 December 2010 10:50:11 Denis Pinkas wrote:
> David,
> 
> Nowhere in RFC 2560, it is said that OCSP clients must have a local clock
> available synchronized with UTC. Those clients that have no such local
> clock, will use the nonce to detect replay attacks. Since those clients
> For those clients, if the OCSP server does not support the nonce extension,
> then these OCSP clients will not be able to work. RFC 5019 mandates a
> clock synchronized with UTC which is necessary for the verification of
> pre-computed responses. RFC 5019 is only a special case of RFC 2560.

Surely "these OCSP clients will not be able to work" conflicts with RFC 5019's 
assertion that "this profile ensures that interoperability will still occur 
between a fully conformant OCSP 2560 client and a responder that is operating 
in a mode as described in this specification" ?

> I agree with you, that I omitted to consider the fact that, in my text
> proposal, the nonce extension is OPTIONAL for the server.
> 
>    If the request includes a nonce extension (section 2.1.1.1) and the
> response does not include a nonce extension that has the same value as the
> nonce extension in the request, then client SHALL reject the response.
> 
> 
> You asked the question: "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?"
> 
> In fact, the validation of pre-produced responses mandates the use of a
> local clock synchronized with UTC, hence why any test or verification
> related to the nonce extension present in a response is useless in the
> context of RFC 5019.
> 
>    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.
> 
> 
>    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 even if present in the response.
> 
> 
> Part 2:
>    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.
>    no nonce extension was included in the corresponding request. In such a
> case, clients that do not include a nonce in the request MUST ignore any
> 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:
> 
> 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:
> 
> 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 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.
> 
> 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 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.
> 
> 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.

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

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 1 Dec 2010 13:50:33 +0100

Rob,

A "fully conformant OCSP 2560 client" must only support the mandatory features, 
not all the optional features. Support of the nonce is optional.
The nonce is unnecessary/useless/unuseful in the context of RFC 5019.

Denis
----- Message reçu ----- 
De : pkix-bounces 
À : pkix,denis.pinkas 
Date : 2010-12-01, 12:04:45
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-02.txt

> ----- Message re¡¡u -----
> De : David A. Cooper
> ¨¤ : Denis Pinkas

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Rob Stradling <[email-masked]>
Date: Fri, 3 Dec 2010 09:56:37 +0000

Denis,

I concede that it's reasonable for a 2560-compliant OCSP Client to reject a 
nonce-less OCSP Response if that Client is locally configured to only support 
Responses that contain nonces.

However, I object to your proposal that ALL Clients "SHALL reject" a nonce-
less Response when the Request contained a nonce.  I see no reason why 2560bis 
should disallow 5019-compliant Clients:
"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."

I'd say that there are 3 (not 2) classes of OCSP Client:
1. Only support nonces.  (Requests MUST contain nonces; Responses MUST contain 
nonces, or they will be rejected).
2. Only support time-based checking.  (Requests MUST NOT contain nonces; 
Responses SHOULD NOT contains nonces).
3. Support nonces where possible, but will fall back to time-based checking if 
necessary (Requests MAY contain nonces; Responses MAY contain nonces).

My vote is that 2560bis should allow all 3.

On Wednesday 01 December 2010 12:50:33 Denis Pinkas wrote:
> Rob,
> 
> A "fully conformant OCSP 2560 client" must only support the mandatory
> features, not all the optional features. Support of the nonce is optional.

RFC 5019 only says that nonces SHOULD NOT be used.  It doesn't say MUST NOT or 
SHALL NOT.

I'm sure you already know that RFC 2119 says:
"4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label."

RFC5019 does not prohibit nonces, hence why it makes sense for it to say 
"Clients that opt to include a nonce in the request..."

> > For those clients, if the OCSP server does not support the nonce
> > extension, then these OCSP clients will not be able to work. RFC 5019
> > mandates a clock synchronized with UTC which is necessary for the
> > verification of pre-computed responses. RFC 5019 is only a special case
> > of RFC 2560.
> 
> Surely "these OCSP clients will not be able to work" conflicts with RFC
> 5019's assertion that "this profile ensures that interoperability will
> still occur between a fully conformant OCSP 2560 client and a responder
> that is operating in a mode as described in this specification" ?
> 
> > response does not include a nonce extension that has the same value as
> > the nonce extension in the request, then client SHALL reject the
> > response.
> > 
> > 
> > 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?
> > 
> > 
> > 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.
> > 
> > 

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: Fri, 3 Dec 2010 12:22:15 +0100

Rob,

Since we both consider that there are  3 classes of OCSP Clients, it seems that we are converging.
However, the three classes I consider are not exactly the same as yours. There are:

1. OCSP clients that only support nonces. (Requests MUST contain nonces; Responses MUST contain 
nonces, or they will be rejected).

2. OCSP clients that only support replay protection using time-based checking with a "small" window period. 
(Requests MUST NOT contain nonces; Responses SHOULD NOT contains nonces, and the time difference 
between the producedAt and the local time must be in the magnitude of a few seconds).

3. OCSP clients that accept pre-computed responses and that support replay protection using time-based 
checking with a "large" window. 

(Requests SHOULD NOT contain nonces; Responses SHOULD NOT contains nonces, OR 
Requests SHALL NOT contain nonces; Responses SHALL NOT contains nonces, 
[To be debated since it is not backwards compatible with RFC 5019] ,

and the current time SHALL be between thisUpdate and nextUpdate,
 
either whatever the time difference  between the two values is, or 
only if that time difference is less than X hours/minutes.

We means that the third case has two subcases in practice (which are not described in RFC 5019).

Anyway, once we agree on these three cases, we would then need to describe the OCSP server behavior 
taking into consideration that the server has no other means than looking to the content of the request to know/guess 
in which mode the OCSP client is operating. There is therefore a difficulty to distinguish between case 2 and case 3.

Keep in mind that it does not really make sense to include a nonce in pre-computed responses, 
since it would serve at most for a single request whereas the goal of pre-computed responses 
is that the reusable for many requests.

This is the reason why I think that in the third case, requests SHALL NOT contain nonces; 
responses SHALL NOT contains nonces [To be debated since it is not backwards compatible with RFC 5019].

Denis

----- Message reçu ----- 
De : Rob Stradling 
À : pkix,denis.pinkas 
Date : 2010-12-03, 10:56:37
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-02.txt

Denis,

> ¨¤ : pkix,denis.pinkas
> > ----- Message re¡¡¡¡u -----
> > De : David A. Cooper
> > ¡§¡è : Denis Pinkas

Rob Stradling

---

From: Rob Stradling <[email-masked]>
Date: Fri, 3 Dec 2010 11:35:37 +0000

Denis, yes it seems that we are starting to converge.  I favour not breaking 
compatibility with RFC 5019.  (I personally wouldn't call it "backwards" 
compatibility, because I don't believe there are any plans to obsolete or 
update 5019).

By the way, "openssl ocsp" is a common example of an OCSP Client that will put 
a nonce in each Request by default, but won't reject a Response if it doesn't 
contain a nonce.

On Friday 03 December 2010 11:22:15 Denis Pinkas wrote:
> Rob,
> 
> Since we both consider that there are  3 classes of OCSP Clients, it seems
> that we are converging. However, the three classes I consider are not
> exactly the same as yours. There are:
> 
> 1. OCSP clients that only support nonces. (Requests MUST contain nonces;
> Responses MUST contain nonces, or they will be rejected).
> 
> 2. OCSP clients that only support replay protection using time-based
> checking with a "small" window period. (Requests MUST NOT contain nonces;
> Responses SHOULD NOT contains nonces, and the time difference between the
> producedAt and the local time must be in the magnitude of a few seconds).
> 
> 3. OCSP clients that accept pre-computed responses and that support replay
> protection using time-based checking with a "large" window.
> 
> (Requests SHOULD NOT contain nonces; Responses SHOULD NOT contains nonces,
> OR Requests SHALL NOT contain nonces; Responses SHALL NOT contains nonces,
> Anyway, once we agree on these three cases, we would then need to describe
> the OCSP server behavior taking into consideration that the server has no
> other means than looking to the content of the request to know/guess in
> which mode the OCSP client is operating. There is therefore a difficulty
> to distinguish between case 2 and case 3.
> 
> Keep in mind that it does not really make sense to include a nonce in
> pre-computed responses, since it would serve at most for a single request
> whereas the goal of pre-computed responses is that the reusable for many
> requests.
> 
> This is the reason why I think that in the third case, requests SHALL NOT
> contain nonces; responses SHALL NOT contains nonces [To be debated since
> it is not backwards compatible with RFC 5019].
> 
> Denis
> 
> ----- Message reçu -----
> De : Rob Stradling
> À : pkix,denis.pinkas
> nonce-less OCSP Response if that Client is locally configured to only
> support Responses that contain nonces.
> 
> less Response when the Request contained a nonce. I see no reason why
> 2560bis should disallow 5019-compliant Clients:
> 1. Only support nonces. (Requests MUST contain nonces; Responses MUST
> contain nonces, or they will be rejected).
> 3. Support nonces where possible, but will fall back to time-based checking
> if necessary (Requests MAY contain nonces; Responses MAY contain nonces).
> 
> > features, not all the optional features. Support of the nonce is
> > optional. The nonce is unnecessary/useless/unuseful in the context of
> > RFC 5019.
> 
> RFC 5019 only says that nonces SHOULD NOT be used. It doesn't say MUST NOT
> or SHALL NOT.
> 
> > > Nowhere in RFC 2560, it is said that OCSP clients must have a local
> > > clock available synchronized with UTC. Those clients that have no such
> > > local clock, will use the nonce to detect replay attacks. Since those
> > > clients have no clock then cannot use a fallback position which
> > > requires a clock.
> > > 
> > > You asked the question: "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?"
> > > 
> > > 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.
> > > case, clients that do not include a nonce in the request MUST ignore
> > > any nonce that may be present in the response.
> > > 
> > > 
> > > Denis
> > > responders are not required to support the nonce extension. Section
> > > 4.1.2 says:
> > > 
> > > 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:
> > > 
> > > 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?
> > > 
> > > 
> > > this requirement in 2560bis would make the RFC 5019 profile
> > > inconsistent with the base standard.
> > > 
> > > 
> > > 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.
> > > 
> > > Where does RFC 2560 impose this requirement? If RFC 2560 did impose
> > > this requirement, then why did RFC 5019 say:
> > > 
> > > 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.
> > 
> > Rob Stradling
> 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