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

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

Paul,

Responses in-lines.
---------- 
De : pkix-bounces 
À : denis.pinkas,pkix 
Date : 2010-11-30, 18:43:14
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-02.txt

At 5:32 PM +0100 11/30/10, Denis Pinkas wrote:
>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.
You don't provide any argument to support your claim. 
Both protocols support nonces for the same purpose, i.e. to detect replay attacks.
If you are still inconvinced, here is a copy and paste from RFC 5019:
   In order to ensure that a client does not accept an out-of-date
   response that indicates a 'good' status when in fact there is a more
   up-to-date response that specifies the status of 'revoked', a client
   must ensure the responses they receive are fresh.
 
   In general, two mechanisms are available to clients to ensure a
   response is fresh.  The first uses nonces, and the second is based on
   time.  
>RFC 2560 was not precise, adding clarifications does not necessarilly mean major changes.

True, and irrelevant to your proposal to force nonces in responses.
Your response is not relevant. 
>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.

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.
Peter Gutmann gave you one response. Our implementation is doing the same.
Denis

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

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

Extract from RFC 5019:

   This document addresses the scalability issues inherent when using
   OCSP in PKI environments described above by defining a message
   profile and clarifying OCSP client and responder behavior that will
   permit:
  
   1) OCSP response pre-production and distribution.

Note that RFC 2560 already permits it. 

RFC 5019 is a profile of RFC 2560, and, for example, states that extensions, hence nonce extensions 
SHOULD NOT be used.

Denis
----- Message reçu ----- 
De : pkix-bounces 
À : pkix,denis.pinkas 
Date : 2010-11-30, 16:16:34
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-02.txt

On Tuesday 30 November 2010 15:01:13 Denis Pinkas wrote:
> RFC 5019 is a profile of RFC 2560 to be used only in the context of
> 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.
> 
> "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
> Is RFC2560bis intended to update, obsolete or break compatibility with
> RFC5019 ?
> 
> On Tuesday 30 November 2010 14:10:42 Denis Pinkas wrote:
> > 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 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.
> > 
> > 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
> > On Tuesday 30 November 2010 11:09:37 Denis Pinkas wrote:
> > > 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.
> > 
> > > I would thus propose the following text replacement:
> > <snip>
> > 
> > > 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.
> > 
> > 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
> 
> 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.

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.
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

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

David,

I took a second look at your email from september 10, trying to find out your arguments why 
a "same key" requirement would be inconsistent with RFC 2560 (and RFC 5280 and X.509).

For RFC 2560, my interpretation is that, even the text does not say it explicitly, it is implicitly the same key; 
but the main arguments of the discussion are not in RFC 2560. See below.

For RFC 5280, you stick to what is a self-signed certificate or a self-issued certificate, 
whereas the real discussion is relative to the certificate path validation of the OCSP responder.

In fact, I could not find any argument  in your email explaining that the "same key" requirement would be 
inconsistent with RFC 5280. If you still believe in such an argument, please provide more details.

Let me come now to the core topic: certificate path validation of the OCSP responder.
I will make a demonstration, that if the key is not the same, most of the current implementations 
will not work anymore.

Let us assume that we have one trust anchor (root key) in the form of a self-signed certificate. 
Everything is working well: a certification path is constructed and the OCSP certificate 
is verified using that trust anchor. The root CA then makes a key rollover. 
With ther curren text from draft-ietf-pkix-rfc2560bis-02.txt, clients that are not aware 
of the key rollover are suddenly unable to verify the revocation status of the certificates 
issued under the first root key.

Another case is when verifying certificates in the past.

When signatures policies are used to verify electronic signatures in the past, only the root CAs
that are in the signature policy can be used (see RFC 3125). Then, if the root key is not the same, electronic signatures 
made while the signer's certificate was still valid cannot be verified as soon as there would be a root CA key rollover.

Nowhere in RFC 5280, it said that root keys SHALL be automically changed by clients using the certificate structures 
defined in RFC 2510, i.e. "old-by-new" and "new-by-new". This is however an implication of draft-ietf-pkix-rfc2560bis-02.txt.

So I would say that  draft-ietf-pkix-rfc2560bis-02.txt is placing a new requirement for clients that does not exist in RFC 5280 (nor in X.509).

Denis

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

Denis,

While you say that your goal is to "allow for backwards interoperability", your proposed changes would result in a change to the OCSP protocol, which is outside of the scope of this effort.  On September 10, I provided a detailed response to your message proposing, among other things, that 2560bis require OCSP responses or OCSP responder certificates to be signed using the same key as the target certificate (http://www.ietf.org/mail-archive/web/pkix/current/msg28345.html).  While you have since then sent proposed text that would impose a "same key" requirement, you never responded to my September 10 message.  I argued why a "same key" requirement would be inconsistent with RFC 2560 (and RFC 5280 and X.509).  If my argument was wrong, why haven't you responded with an explanation of what it was about my argument that was incorrect?

Dave

On 11/02/2010 07:45 AM, Denis Pinkas wrote: 

I am concerned as well.

In order to allow for backwards interoperability, the designated OCSP responder certificate 
MUST be signed by the same key that certificate in question was signed.

I sent emails on this topic :
on October, 8:  12 comments on draft-cooper-pkix-rfc2560bis-00 (re-sent), and
on October 12: 12 comments on draft-cooper-pkix-rfc2560bis-00

In the later e-mail, I  have proposed text to solve the issues that have been raised.

I would appreciate a response to these emails, at least from the authors of the draft.

Denis