RE: OCSP response pre-production

["Frank Balluffi" <frank.balluffi@xxxxxx>]

I too like the proposal to use a flag or an extension. Perhaps an extension could say the equivalent of, "This is a cached response."

Frank



                                                                                                                                       
                      "Terry Hayes"                                                                                                    
                      <thayes0993@xxxxx        To:       "David Engberg" <dave@xxxxxxxxxxxxxx>                                         
                      om>                      cc:       ietf-pkix@xxxxxxx                                                             
                      Sent by:                 Subject:  RE: OCSP response pre-production                                              
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      
                                                                                                                                       
                                                                                                                                       
                      10/02/2003 01:47                                                                                                 
                      PM                                                                                                               
                                                                                                                                       
                                                                                                                                       





I also like this proposal.  I believe that it is compatible with
existing responders that use pre-produced nonces, in the sense that
there aren't any changes required to allow them to continue operations.

Responders that only use pre-produced responses (with no nonce) would
benefit from changing their implement to add the extension.  This would
allow them to support the clients that implement dual-mode policy as
described in this thread.

As Florian has pointed out, this proposal is easier to understand than
having the server generate nonces.  In fact, I was going to write an
email that complained about overloading the nonce field to represent
this bit of information.  Given this proposal, I don't have to!

I also agree with Mike that we need to define an error that says that a
nonce is required for this responder.  This error is subject to
denial-of-service attacks (since it's unsigned), but we're already
exposed to that in this protocol anyway.

Terry

David Engberg wrote on 10/1/2003, 3:10 PM:

 > As an alternative, pre-generated responses could include a flag or
 > extension in their signed body to indicate that not only are they not
 > supplying a nonce with this response, but that they don't supply nonces
 > with any response, and if you trust that responder (via its public key
 > cert), then you may choose to accept the non-nonce-bearing response from
 > that server with this explicit flag (if that is your policy).
 >
 > This avoids the risk of someone replaying a response to you in which the
 > attacker chose not to supply a nonce, but you did.  It allows a client
 > to distinguish between a server saying "Here's a response without a
 > nonce because you I think you didn't ask for one" and "Here's a response
 > without a nonce because the responder for you or your CA does not use
 > nonces."
 >
 > I believe the following is a valid security policy which some (most?)
 > clients may choose to implement as an option:
 >
 >    - Send a nonce with every request
 >    - Accept a response with a matching nonce from any trusted responder
 >    - Accept a response with a nonceUnsupported extension from any
 >        trusted responder
 >    - Reject a response with no nonce and no nonceUnsupported extension
 >
 > This would allow the client to be much more usable with random public
 > certs (using AIA fields and delegated responder certs) in real-world
 > settings like secure email, etc.
 >







--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.