Subject: RE: DISCUSS: MUST reject in OCSPv1

From: Russ Housley <[email-masked]>
Date: Tue, 02 Dec 2003 08:42:27 -0500

I am not very happy with the way that this discussion is going.  I am not 
convinced that a new extension is the best compromise.

I have just reread the nonce-related portions of RFC 2560.  I must say, it 
is quite under specified.  It does not even provide a syntax for a 
nonce.  It really only provides the OID to identify the nonce extension and 
which extension location in which it is carried.

It says:

    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.

    id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

Rather than defining a new extension, called nonceUnsupported, you have the 
opportunity to specify a syntax to go with this OID that does the same 
thing.  Something like:

    OCSPNonce ::= CHOICE {
       nonceValue  OCTET STRING,
       unsupported  NULL }

Text that goes with the syntax definition ought to make it illegal for the 
request to use the NULL.  That is, it is only allowed in the response.

I still prefer the "MUST reject" approach, but this seems like a cleaner 
solution than a new extension.

Russ

Ambarish wrote:

>Hi Florian,
>    The reason for including a nonce in the request is to enable a
>client that doesn't have a very precise knowledge of time to still
>be sure the response he got from the server was generated for this
>specific request.
>
>While I do agree with Mark and think that the "right" way would be
>to require the client to require the nonce in the response, in the
>interests of moving ahead, I vote to accept Mike's compromise
>proposal that a client MUST require the nonce in the response
>unless it is accompanied by a nonceUnsupported extension in
>the response and the client is willing to accept a response w/o
>a nonce. This preserves the semantics for current clients and
>still allows caching servers to supply responses to clients
>who will take them.
>
>Regards,
>Ambarish

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 2 Dec 2003 08:33:24 -0700

Russ,

So if I'm reading this correctly, a server that receives a
request containing a value for nonceValue MAY ignore the nonce
and return NULL?

By the way, Ambarish and I had already planned to clarify nonce
syntax as OCTET STRING as 2560 goes from Proposed to Draft.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Russ Housley
> Sent: Tuesday, December 02, 2003 6:42 AM
> To: [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>

---

From: "Ambarish Malpani" <[email-masked]>
Date: Tue, 2 Dec 2003 07:48:03 -0800

Hi Russ,
    This would *definitely* break compatibility with exisiting
software.

Currently, some folks put in some random bytes as the value of
the nonce extension, while others put in an OCTET STRING, whose value is
the random bytes.

The only check the clients do, is verify that the request contains
the same set of bytes.

Servers that include the nonce in the response include the bytes
they got in the request in the response.

The solution suggested by Mike would allow current servers and clients
to work as they do, and allow a way for smarter servers/clients to
work together where a server wanted to provide a response without the
nonce.

If we wanted to break compatibility, it would make more sense to use the
criticality bit in extensions (as suggested by others on the list).

Regards,
Ambarish

> Sent: Tuesday, December 02, 2003 5:42 AM
> To: [email-masked]

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 2 Dec 2003 09:07:38 -0700

> From: Russ Housley

Russ,

More precisely, based on the prior proposal, we have:

1. Cycle v1 at Proposed with the above
   amendment to nonce value syntax and
   the following semantics.

2. Clients that send a nonce:

   a. SHALL use the nonceValue CHOICE of
      OCSPNonce value syntax.

   b. MUST reject a response that fails
      to include the nonce extension
      (errors notwithstanding);

   c. Else, if such response includes a
      nonce extension with a value of
      "unsupported", clients MAY accept the
      response subject to the advice in the
      Security Considerations section of
      this document.

4. Conversely, if a server receives a nonced
   request but is unable to incorporate the
   nonce in its response, the server MUST
   include a nonce extension with the value
   "unsupported" for OCSPNonce.

So basically, it is pretty much the same semantics as previously
proposed, only using the "unsupported" CHOICE for OCSPNonce as
the caveat instead of an extension-based OID of "unsupported".

Is this what you had in mind?  Note that we still have a "MUST
reject" for plain responses.

Mike

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 2 Dec 2003 14:54:49 -0500

Mike and Russ:

One topic that has not been discussed is what if the server switches back
and forth from nonce supported and "not supported".  May be server supports
nonce during working hours and not during non-working hours.

Seems like we have the following options:

1.  Servers shall not switch.  If that is the case, the RFC should state
that.

2.  Servers can do this ad hoc.  Clients need not be notified.  In that
case, no change is required.

3.  It will nice for the servers to be able to declare when they will start
supporting nonce.  In that case, ASN.1 could be revised as follows: 

OCSPNonce ::= CHOICE {
        nonceValue  OCTET STRING,
        unsupported  NULL,
        supportedAt  GENERALIZED TIME }

Option 3 does not commit the server to start supporting nonce's.  It
requires the server to start producing nonce's at that time or produce new
responses at that client.  A client SHOULD reject responses when the current
time is past the supportedAt time.

Option 3 reduces the temporal window of replay attack. 

If there is a desire for option 3, the ASN.1 can be further compacted by
using 99991231235959Z in place of NULL for unsupported.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Myers
Sent: Tuesday, December 02, 2003 11:08 AM
To: Russ Housley; [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1

Russ,

So basically, it is pretty much the same semantics as previously proposed,
only using the "unsupported" CHOICE for OCSPNonce as the caveat instead of
an extension-based OID of "unsupported".

Is this what you had in mind?  Note that we still have a "MUST reject" for
plain responses.

Mike

---

From: David Engberg <[email-masked]>
Date: Tue, 02 Dec 2003 15:36:48 -0500

Santosh -

Would it be possible to achieve this same result using the existing 
"nextUpdate" mechanism instead of adding a new nonce-related expiration 
time ("supportedAt")?

If I have a caching-only responder that plans to support nonces in 4 
hours, I could pre-generate the OCSP responses with a "nextUpdate" for 
that scheduled time.  These responses will automatically be rejected by 
any OCSP software (backward compatible) in 4 hours when nonces are 
supported.

(Going the other direction from nonce to nonceUnsupported isn't a 
problem, obviously.)

Thanks,
Dave

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 2 Dec 2003 16:19:39 -0500

David:

I agree.  There is no need for the added complexity.

-----Original Message-----
From: David Engberg [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2003 3:37 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: DISCUSS: MUST reject in OCSPv1

Santosh -

Thanks,
Dave

Santosh Chokhani wrote:

> 3.  It will nice for the servers to be able to declare when they will 
> start supporting nonce.  In that case, ASN.1 could be revised as 
> follows:
> 
> OCSPNonce ::= CHOICE {
>         nonceValue  OCTET STRING,
>         unsupported  NULL,
> requires the server to start producing nonce's at that time or produce 
> new responses at that client.  A client SHOULD reject responses when 
> the current time is past the supportedAt time.
> 
> If there is a desire for option 3, the ASN.1 can be further compacted 
> by using 99991231235959Z in place of NULL for unsupported.

---

From: Russ Housley <[email-masked]>
Date: Tue, 02 Dec 2003 16:29:59 -0500

Yes, that is my compromise proposal.

---

From: Russ Housley <[email-masked]>
Date: Tue, 02 Dec 2003 16:32:28 -0500

Ambarish:

This lack of interoperability is a result of the under specification of the 
nonce extension.  I do not see a way to specify the return of the same 
random blob that was received or a specific flag to indicate the 
unsupported nonce response.

Russ