Subject: RE: OCSP response pre-production

From: "Deacon, Alex" <[email-masked]>
Date: Fri, 3 Oct 2003 15:54:49 -0700

Yes, I have an issue with "re-assert[ing] that it is not conformant to
RFC2560 to send back a response without to nonce to a request requiring a
nonce"

You can't re-assert something that was never asserted in the first place.
The current spec does not mandate that servers support extensions in OCSP
requests. (as Florian pointed out in a recent email)  Mandating that servers
MUST respond to a nonce extension would make currently compliant responders
non-compliant.   Not good...

Alex

> -----Original Message-----
> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Friday, October 03, 2003 10:35 AM
> To: 'Michael Myers'; 'Jean-Marc Desperrier'; [email-masked]
> Subject: RE: OCSP response pre-production
> 
> 
> 
> 
> Yup, sounds good to me. Is there rough concensus that this is what
> folks want? Anybody with a strong opinion to the contrary, please
> pipe up now.
> 
> Regards,
> Ambarish
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Michael Myers
> > Sent: Friday, October 03, 2003 9:17 AM
> > To: Jean-Marc Desperrier; [email-masked]
> > Subject: RE: OCSP response pre-production
> > 
> > 
> > 
> > 
> > This works for me, especially the part about getting 
> > definitive on 2560 as it stands.  Ambarish?
> > 
> > Mike
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> > > [mailto:[email-masked]]On Behalf Of Jean-Marc 
> > Desperrier
> > > Sent: Friday, October 03, 2003 8:09 AM
> > > To: [email-masked]
> > > Subject: Re: OCSP response pre-production
> > >
> > >
> > >
> > > Frank Balluffi wrote:
> > > > My preference would be to define an extension (e.g., via an 
> > > > informational RFC) that can be used with v1 bits on
> > > the wire, and
> > > > then to formally incorporate the extension into v2.
> > > Again, if a
> > > > strong case can be made for v2 to use a different
> > > mechanism (than the
> > > > extension defined above), I am OK with that.
> > >
> > > I know understand better the case against the
> > > round-trip error discovery
> > > solution without a signed assertion from server.
> > >
> > > I think the above solution is something everybody can
> > > agree on, and stop
> > > discussing the point for ever.
> > >
> > > So can everybody agree on creating an informationnal
> > > RFC about how to
> > > handle cache response in OCSP v1 that would :
> > >
> > > - define an extension that enable a responder to
> > > assert the answer is a
> > > cached answer and not an answer to a nonce-less request
> > >
> > > - [MAYBE] define a value for that extension that says
> > > this answer does
> > > not include a nonce, but that the server can provide
> > > one if requested
> > >
> > > - re-assert that it is not conformant to RFC2560 to
> > > send back a response
> > > without to nonce to a request requiring a nonce (it
> > > might change in OCSPv2)
> > >
> > > - precise what error amongst the already defined one
> > > the OCSP server
> > > should send back when receiving a nonce if it can not
> > > send one back
> > >
> > > - describe that a client who wants the best possible
> > > answer can :
> > > * Ask for a nonce
> > > * Receive an error
> > > * Ask without nonce
> > > * Receive an answer that includes the extension that
> > > the server can not
> > > able to include nonces in answers.
> > >
> > > - describe another possible solution :
> > > * Don't ask for a nonce
> > > * Receive an answer that includes the extension that
> > > the server can
> > > include nonces in answers.
> > > * Ask with a nonce, because I want the very best I can have.
> > >
> > > The second solution might be better if the servers
> > > that send back cached
> > > answer have a very heavy load and want to avoid the 
> > round-trip, whilst
> > > the one that are ready to provide nonces are more
> > > likely not to have a
> > > problem with round-trips.
> > >
> > > An evolution could then be included in OCSPv2 to
> > > avoid the round-trip
> > > completely.
> > >
> > >
> > 
> > 
>

---

From: "Michael Myers" <[email-masked]>
Date: Sat, 4 Oct 2003 07:47:48 -0700

Well, it certainly wasn't in *my* mind at the time that nonces,
if used, would be ignored.  To my recollection, the discussions
between Carlisle and myself that lead to their definition were
quite robust on the point.

Indeed, as the poll indicates something close to 11 of 12 of
client side implementors treat (or can treat) the practice as an
error.  So it's not like this is a great revelation to anybody.
Yes, extensions are optional.  But extensions may have
additional semantics associated with their use.  The fact that
the definition of the nonce extension does not is where we got
started with a view towards clarifying original intent.

Since nonces break caching, don't use nonces in a cached
environment.  Send a non-nonced response anyway due to
server-side lack of control on the client side?  Maybe.  If the
chairs and the AD are comfortable allowing the IETF to
standardize the practice, I'd be happy to oblige.

Mike

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 15 Oct 2003 14:02:39 -0700

All,

I recently received permission from the chairs to poll the WG
against the following question.

Should we standardize an OCSP *V1* error code that enables a
responder to indicate its inability to respond to nonced
requests?

Please respond with either YES or NO.

Mike

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 16 Oct 2003 09:34:09 +0200

Mike,

> Please respond with either YES or NO.

I would suggest to you provide a resumé of the advantages of this new error 
code (and disadvantages if not supported), so that people do not have to 
look back at that long thread on that topic to make up their opinion.

Denis

---

From: "Liaquat Khan" <[email-masked]>
Date: Thu, 16 Oct 2003 15:26:37 +0100

NO

Not really needed in my opinion, generally the person (i.e. an
administrator) setting up the OCSP client software will know upfront the
capabilities of the responders that will be accessed by the OCSP client
and therefore configure the client accordingly (i.e. with or without
nonce).  

In the case that OCSP clients are dealing with random, previously
unknown OCSP responders, then such an error code may have some use in
pin-pointing the problem from the various things that may go wrong.  But
I don't think the limited value it adds is worth the change.  

Anyway, I agree with Denis, a summary would be useful though...in case I
have missed something important somewhere down the line...

Regards,
LK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: 15 October 2003 22:03
To: [email-masked]
Subject: POLL: Nonce-specific error code for OCSP

All,

Mike

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 16 Oct 2003 09:05:09 -0700

> [mailto:[email-masked]]On Behalf Of Denis Pinkas
> Sent: Thursday, October 16, 2003 12:34 AM
> To: Michael Myers
> Cc: [email-masked]
> Subject: Re: POLL: Nonce-specific error code for OCSP
>
>
>
> Mike,
>
> > All,
>

A reasonable request.

In summary, we need to standardize the treatment of nonces when
nonces aren't supported.  RFC2560 is regrettably silent on the
point.  The need to do so is particularly acute in the context
of heterogeneous populations of clients and servers (i.e. not
operating under a single administrative authority).  Some may be
set up to use or support nonces and some may not.  The question
is of course moot for requests that don't contain nonces.

The issue is further complicated by the use of pre-produced
responses to achieve scalability through caching (i.e.
non-signing) servers.  A relay back to a master signing server
could work, but that doesn't seem to be a popular option.  So
that leaves us with two server-side options.  Either: 1) send
back a non-nonced response anyway with technical extensions; or
2) send back an error code.

Variations on option 1 have been discussed, with the likelihood
that an extended response syntax or equivalent technical
mechanisms will force a v2 and all that entails with regard to
IETF process.

Yet we also need to do something sooner about v1.  In this case,
an existing error could be designated or we could define a new
one that servers can send back in the event they don't support
nonces.  Absent a designated error code, it is predictable that
ad-hoc selections will be made to to address the issue with a
consequent reduction in Internet-wide OCSP interoperability and
security.

This poll is focussed on the narrower v1 issue ONLY. Should we
or should we not standardize a v1 error code? If this poll is
inconclusive, then I suppose we'll get into the heart of the
matter, which is whether it is acceptable in v1 to disregard a
client's nonce.  But let's leave those discussions to another
thread and first get a vote tally.

Mike

---

From: Richard Sinn <[email-masked]>
Date: Thu, 16 Oct 2003 10:36:59 -0700

YES.

In general, the less information given out, the more secure the 
environment is. However, if I view OCSP could run in two different 
modes, one with nonce and one without, then, an error code will be 
useful to indicate which type of responder is out there. However, I 
agree with Denis, a resume of advantages vs disadvantages would be 
useful ... just do not want to miss anything.

Thanks,

Richard Sinn
Infoblox, Inc.

---

From: [email-masked] (Julien Pierre)
Date: Thu, 16 Oct 2003 17:20:34 -0700

NO.

-- 
I am the dog in dogfood

---

From: "Joseph A. Doekbrijder" <[email-masked]>
Date: Fri, 17 Oct 2003 08:17:16 +0200

No.

Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
Löwenstrasse 1, CH-8001 Zürich
Tel: +41 433 44 88 11
Mobile: +41 79 211 24 46
www.swisssign.com
--------------------------------------------------

> Sent: Thursday, October 16, 2003 18:05
> To: [email-masked]
> Subject: RE: POLL: Nonce-specific error code for OCSP
> 
> 
> 
> > > responder to indicate its inability to respond to nonced requests?
> >
> In summary, we need to standardize the treatment of nonces 
> when nonces aren't supported.  RFC2560 is regrettably silent 
> on the point.  The need to do so is particularly acute in the 
> context of heterogeneous populations of clients and servers 
> (i.e. not operating under a single administrative authority). 
>  Some may be set up to use or support nonces and some may 
> not.  The question is of course moot for requests that don't 
> contain nonces.
> 
> non-signing) servers.  A relay back to a master signing 
> server could work, but that doesn't seem to be a popular 
> option.  So that leaves us with two server-side options.  
> Either: 1) send back a non-nonced response anyway with 
> technical extensions; or
> Variations on option 1 have been discussed, with the 
> likelihood that an extended response syntax or equivalent 
> technical mechanisms will force a v2 and all that entails 
> with regard to IETF process.
> 
> Yet we also need to do something sooner about v1.  In this 
> case, an existing error could be designated or we could 
> define a new one that servers can send back in the event they 
> don't support nonces.  Absent a designated error code, it is 
> predictable that ad-hoc selections will be made to to address 
> the issue with a consequent reduction in Internet-wide OCSP 
> interoperability and security.
> 
> This poll is focussed on the narrower v1 issue ONLY. Should 
> we or should we not standardize a v1 error code? If this poll 
> is inconclusive, then I suppose we'll get into the heart of 
> the matter, which is whether it is acceptable in v1 to 
> disregard a client's nonce.  But let's leave those 
> discussions to another thread and first get a vote tally.
> 
> Mike
> 
> 
>

---

From: "Miguel Rodriguez" <[email-masked]>
Date: Fri, 17 Oct 2003 08:44:19 -0500

NO

Miguel A Rodriguez
SeguriDATA
Mexico

---

From: David Engberg <[email-masked]>
Date: Fri, 17 Oct 2003 17:26:28 -0400

Dumb question:  why is it possible to add a new OCSPResponseStatus code 
value (a non-backward-compatible addition) for v1, but not to convey 
this information through a new responseExtension in the signed body (a 
backward compatible change with better security semantics)?

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 17 Oct 2003 15:53:02 -0700

Because willful disregard of a client's nonce violates first
principles.  Enabling service providers a legal basis to do so
via reliance on an IETF standard is a whole different question.

Mike

> From: David Engberg [mailto:[email-masked]]
> Sent: Friday, October 17, 2003 2:26 PM
> To: Michael Myers
> Cc: [email-masked]
> Subject: DISCUSSION: Nonce-specific error code for OCSP
>
>
>
> Dumb question:  why is it possible to add a new
> OCSPResponseStatus code value (a non-backward-
> compatible addition) for v1, but not to convey
> this information through a new responseExtension in
> the signed body (a backward compatible change with
> better security semantics)?

---

From: "Richard Sinn (Infoblox)" <[email-masked]>
Date: Fri, 17 Oct 2003 18:03:59 -0700

NO. 

Clearly after all these discussion. 

- Richard.

---

From: "Florian Oelmaier" <[email-masked]>
Date: Sat, 18 Oct 2003 12:52:06 +0200

> principles.  Enabling service providers a legal basis to do 
> so via reliance on an IETF standard is a whole different question.

It is not a "willful disregard"! A caching responder CANNOT answer
nonces. 

And the IETF standard already defines a "legal basis" for a service
provide to do so: simply not answering the nonce. Thats not a perfect
way - but thats the way RfC2560 suggests.

Can you please tell me where those "first principles" of the IETF you
mention are defined? Where can I read more about it? What "first
principles" do you mean exactly?

Thanks for your help,

-- 
Florian Oelmaier
SyTrust

---

From: "Florian Oelmaier" <[email-masked]>
Date: Sat, 18 Oct 2003 12:48:49 +0200

David Engberg wrote:
> OCSPResponseStatus code 

/agree

Even more as all extension procressing is optional, meaning that such an
addition IS completely backward compatible with all clients out there by
definiton. Why did we add the extension system in the first place? I
thought this was done with such extensions in mind.

After all this discussion, we have two options for adding such an
extension:

Option A) "The-signer-of-this-response-intended-it-to-be-cached
extension": Even when the request containes a nonce a responder may
answer with a response containing no nonce but this extension.

Clients supporting nonces should not accept a nonce-less response
without this extension.

Option B) "Usually-I-support-nonce extension": Responders that are able
to generate nonces and get a request without nonce add this extension.
(A responder could also indicate this by producing a server-generated
nonce). 

Clients supporting nonces should not accept responses containing this
extension but NOT containing a fitting nonce. Getting a response without
nonce and without this extension indicates, that the responder is not
able to generate nonces.

Mind: These options do basically the same, we only need one of them.

I strongly vote to include an extension according option A (Davids
proposal) into OCSPv1. 

If this is not possible, I would like to advise all responder
implementers to use Option B with server-generated nonces, as this
behaviour is already covered by OCSPv1 and does not need any changes to
the RfC. For OCSPv2 we should then go for an extension according to
option A.

-- 
Florian Oelmaier
SyTrust

---

From: "Michael Myers" <[email-masked]>
Date: Sat, 18 Oct 2003 10:24:51 -0700

It seems to me that an extended response is no improvement upon
a plain response when applied to replay detection.  It too can
be replayed because there is no dynamic binding between request
and response.  That's what the nonce extension was defined to
enable: client-side elimination of replay risks via dynamic
binding.

Further, the requestor which sent a nonce and received a
non-nonced response can today infer "responder does not support
nonces."  Something like 11 of 12 client side implementors claim
ability to detect such.  Inclusion of an extension which in
effect asserts that "I as responder give myself permission to
disregard your nonce" does nothing to improve upon that.

Mike

---

From: "Florian Oelmaier" <[email-masked]>
Date: Sat, 18 Oct 2003 19:49:23 +0200

> It seems to me that an extended response is no improvement 
> upon a plain response when applied to replay detection.  It 
> too can be replayed because there is no dynamic binding 
> between request and response.  That's what the nonce 
> extension was defined to
> enable: client-side elimination of replay risks via dynamic binding.

The response can be replayed. Thats true. But the client now has a way
of dectecting if the responder supports nonces. So the client will ask
itself: Why should I accept a response without nonce from a responder
that supports nonce? Coming to the conclusion that something is wrong
the client can now disregard the response.

Today, when a client sends a request with nonce and gets a response
without nonce that can mean:

A) the responder does not support nonces
B) the responder would support nonces but this is a replay (the attacker
is replaying the response to a request without nonce)

With either one of the proposed extensions, the client would get a
secure method of differentiation between these two cases.

Imagine an attacker now recording an OCSP response to a request without
nonce and replaying this response to another request with nonce. With
the proposed extensions, the replayed response contains information
saying that this responder usually supports nonces. Thus the client will
reject the response, as it did not contain a nonce but the responder
simultaneous indicates that it would support nonce generation.

> non-nonced response can today infer "responder does not 
> support nonces."  Something like 11 of 12 client side 
> implementors claim ability to detect such.  Inclusion of an 
> extension which in effect asserts that "I as responder give 
> myself permission to disregard your nonce" does nothing to 
> improve upon that.

I know that 11 of 12 client side implementors think they can infer such
a conclusion. But - sad to say - this conclusion is not necessarily true
in the current state of RfC2560. The response could also be a replay of
a response to a request without nonce. Thats why we need the extension
(or server-generated nonces as a work-around).

So the inclusion of an extension saying that "I AS RESPONDER give myself
permission to disregard your nonce" has a real value. It indicates that
the responder KNOWS that this response may be used in replay or caching
situations. It is a lot better than the current situation. Currently a
response without nonce asserts that "I as responder OR ATTACKER give
myself permission to disregard your nonce".

I hope that clarifies why we want something to the effect of this
proposal so urgently.

-- 
Florian Oelmaier
SyTrust

---

From: David Engberg <[email-masked]>
Date: Sat, 18 Oct 2003 16:14:23 -0400

> disregard your nonce" does nothing to improve upon that.

I believe that it is not currently possible to infer this under the 
current spec.  An existing client can't tell the difference between a 
server that doesn't support nonces and a replay attack by an attacker 
who made a nonceless request.  An explicit "nonceUnsupported" extension 
in the signed body of the response allows a client to securely tell the 
difference between these cases.

OCSP and other PKIX standards currently allow some policy decisions to 
be made by the infrastructure authorities (CAs, responders) and others 
by the relying parties.  For example, the pkix-nocheck extension allows 
the infrastructure to tell clients that they should accept a delegated 
responder cert without performing validation.  This extension was 
approved, even though someone could have made an argument that "only 
clients should be allowed to set responder validation policies."

Something like "nonceUnsupported" would fall in the same category ... 
the infrastructure is telling interested clients about the security 
characteristics of that PK infrastructure and suggesting a security 
policy based on that information.

---

From: "Piyush" <[email-masked]>
Date: Sat, 18 Oct 2003 16:41:00 -0700

NO.

Piyush

---

From: "Michael Myers" <[email-masked]>
Date: Sat, 18 Oct 2003 18:14:26 -0700

Dave,

A few thoughts embedded below.

Mike

> From: David Engberg
> . . .
> An existing client can't tell the difference between a
> server that doesn't support nonces and a replay
> attack by an attacker who made a nonceless request.
> An explicit "nonceUnsupported" extension in the signed
> body of the response allows a client to securely tell the

The requirement is to bind a request to its associated response
and thus enable relying parties to mitigate replay risks.  I
remain curious to an understanding of how unilateral server-side
response extensions achieve this effect.

> OCSP and other PKIX standards currently allow some
> policy decisions to be made by the infrastructure
> authorities (CAs, responders) and others by the
> relying parties.  For example, the pkix-nocheck
> extension allows the infrastructure to tell clients
> that they should accept a delegated responder cert
> without performing validation.  This extension was
> approved, even though someone could have made an
> argument that "only clients should be allowed to
> set responder validation policies."

In the instance of explicit delegation from a certification
authority, there then exists a business entity which places
itself in a position of risk against damage claims.  Are you
suggesting that an OCSP responder's unilateral inclusion of a
technical artifact is an assertion of willingness to absorb such
risks?

Bear in mind that the relying party problem is notoriously
difficult.  It only appears in the heterogeneous context we are
now debating; else contracts suffice.  If you are unfamiliar
with the issue, you may wish to consult with our legal peers in
the American Bar Association's Information Security Committee.

> Something like "nonceUnsupported" would fall in the
> same category ... the infrastructure is telling
> interested clients about the security characteristics
> of that PK infrastructure and suggesting a security

Infrastructure should serve the needs of its participants rather
than the other way around.

Mike
(602) 739-7744

---

From: David Engberg <[email-masked]>
Date: Sat, 18 Oct 2003 22:49:39 -0400

Sorry, didn't mean to start a rehash of the original nonce argument.
My original point was in response to precise protocol assertion from 
Mike's last email:

     nonces."

I was basically trying to say that, at a protocol level, this statement 
is false.

If a client sends a request to a responder that includes a nonce, and 
that client receives either:
    (a) an unsigned OCSPResponseStatus
     - or -
    (b) a signed response with no nonce and no special extensions
then that client has no way to tell whether that OCSP responder is 
intentionally configured to ignore nonces, or whether an attacker on the 
network is providing (a) bogus or (b) replayed information.

If the signed body of the response contains an extension that says "this 
OCSP infrastructure never provides nonces for any requests", then the 
client can securely determine that this declaration came from a trusted 
entity (the OCSP signer) and not an intermediate attacker.

> response extensions achieve this effect.

I disagree.  The real requirement is that the certificate status 
response be as provably up-to-date as possible for a given request.  All 
this "binding" stuff is just a particular mechanism which MAY achieve 
that requirement.

A nonce can be used to strongly bind a response to a specific request. 
This proves that the response is "fresh" from a responder.  This MAY 
give indication that the underlying status information is up-to-date. 
If, however, the response was provided by a responder which is using a 
CRL that is 11 hours old, the nonce is only providing me with the 
illusion of immediacy.  If a cert was revoked 6 hours ago, that 
responder will provide "fresh" responses validating that cert until the 
next CRL is released and processed.

A response based on a start time (thisUpdate) and end time (nextUpdate) 
more accurately reflects the real underlying status information in any 
system with responders using periodic CRLs.

> technical artifact is an assertion of willingness to absorb such

Oh, I don't think that lawyers would be quite as clear on the liability 
distinction between ACME Novelty's CA and its Responders.  In both 
cases, ACME has IT personnel running servers with HSMs that provide 
digitally signed information attesting to the identity and status of 
ACME employees.  I don't think you'd avoid any lawsuits by asserting 
that a revoked certificate was "validated" using a compromised ACME OCSP 
Responder rather than a bad CRL from a compromised ACME CA.

But I certainly wouldn't advocate any sort of unilateral inclusion of 
technical artifacts ... that's why we're discussing this as part of the 
standards process.

Thanks,
Dave