[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.