RE: DISCUSS: MUST reject in OCSPv1

["Michael Myers" <mmyers@xxxxxxxxx>]

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