Dave,
So how about:
1. If we can cycle v1 at Proposed (a big if); then
2. Define nonceUnsupported extension subject to the following semantics (I'm squeezing the words a bit but you'll get the drift)
3. Clients that send a nonce:
a. MUST reject a non-nonced response if that response includes either the value "good" or "revoked" AND it fails to include the nonceUnsupported extension;
b. Else, if such response includes the nonceUnsupported extension, 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 the nonceUnsupported extension.
Note that I made no distinction between "good", "revoked" or "unknown" in #3.b or #4. Thus, a plain nonceless response of "good" or "revoked" is non-conformant, while a caveated response is subject to the client's local security policy.
Does this seem a fair compromise? Note well it's highly dependent on cycling v1 at Proposed.
Mike
-----Original Message----- From: David Engberg [mailto:dave@xxxxxxxxxxxxxx] Sent: Thursday, November 27, 2003 10:58 AM To: Michael Myers Cc: ietf-pkix@xxxxxxx Subject: Re: DISCUSS: MUST reject in OCSPv1
Michael Myers wrote:
There's a chance we maybe can if we reset 2560 back
to Proposed,
still call it v1 and let it cycle there for a
while. I've yet
to hear back from Russ on that one so I've been reluctant to play that card. I think what will be the
determining factor on
that potential course of action is if we can all
agree on the
technical content. The number of implementors who would be affected is still quite manageable.
This sounds good to me.
I suspect though there still will remain the core issue: whether or not it is conformant in principle and in
the spirit
of the RFC to send a nonceless response to a nonced
request. I
would further refine that by saying any nonceless signed response containing either "good" or "revoked". I
could accept
"unknown" due to reasons of nonces not being supported as indicated by a small extension to the protocol.
I read the nonce description in the RFC as the client asking for something that it WANTS as opposed to demanding something that it NEEDS. I.e. a nonce is one element in a list of things like nextUpdate, thisUpdate, producedAt, etc. that a client may use to decide on response acceptance based on the local security policy.
The local policy needs to take all of these factors into account, and the absence/presence of a nonce is one factor which may help avoid a specific type of attack. The default, recommended, behavior is that a nonceless response should be rejected unless the client has a darned good reason for accepting the response based on other factors (e.g. the response comes with a signed letter from the cert's issuer saying it is safe [safer, IMHO, but that's a separate discussion] to accept the nonceless response for its certs).
It sounds like your interpretation is that the presence of a nonce is something the client NEEDS and that nonce absence supercedes all other policy considerations. I don't think this is a horrible interpretation, but it does imply some limitations, as discussed.