Subject: Re: OCSP response pre-production

From: "Florian Oelmaier" <[email-masked]>
Date: 2 Oct 2003 11:43:54 -0000

> David Engberg wrote:
> > I would prefer a signalling mechanism that does not require two 
> > round-trip communications to establish nonce support, 
> 
> May I say we should *NOT* aim to fullfill this ?

Seeing that it is rather easy to do it (as shown in both proposals), I would vote for fullfilling this requirement.

> My opinion is :
> - in real life implementations, it's not so common to both trust an OCSP 
> responder, and not know in advance if it can supply fresh responses or 
> not. 

A lot of clients use AIA to find the OCSP-URL and use the OCSP-signing certificate extension to trust the OCSP Responder. The case of contacting an "unknown" OCSP-Responder will even become more important the more PKIs we find our there.

> - The global security brought by trying to get a fresh response, but 
> being ready to accept a non-fresh one, can hardly be said to be any 
> different from directly accepting a non-fresh one. If the system was 
> audited, I'm doubtful auditors would think it brings any real difference.

With our proposals this depends on the responder. If your responder supports nonces, the described client WILL use it. If your responder does not, the client will not. The client will NOT accept a nonce-less response from a responder being able to support nonces. 

Thus an auditor will see a real difference regarding certificates from some CAs - as for certain CAs a client will not accept nonce-less OCSP responses. This is a very common thing for every auditor out there: having CAs with different trust levels.

Additionally when an OCSP client (for example an SCVP server) detects multiple paths for a given certificate, the "freshness" of a validation may be used in a policy to establish a certain "trust level".

-- 
Florian Oelmaier
SyTrust

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 3 Oct 2003 04:30:04 +1200

"Michael Myers" <[email-masked]> writes:

>If we don't define a nonce-specific error, it's predictable that client
>developers will choose one of the existing 5 unsigned error values in order
>to pop up a dialog that says, essentially, "You used a nonce and received an
>error.  If you want to try again not using nonces, click here."

.... which the user will mentally translate to "Quadrant change in relocatable
expression in subspace $CODE$" (yes, that's a real error message from HP-UX)
which after another level of mental translation becomes "Go boom fall down.
Click here make better".  After clicking OK, everything works again (or at
least something happens, either a cached response or a replay attack, but in
any case the annoying warning goes away so everything's all right).

Peter.

---

From: "Frank Balluffi" <[email-masked]>
Date: Fri, 3 Oct 2003 10:08:41 -0400

Please disregard "Again," below. It referred to something I deleted before sending.

Frank

                      "Frank Balluffi"                                                                                                     
                      <frank.balluffi+exter        To:       [email-masked]                                                              
                      [email-masked]>                  cc:       [email-masked]                                                             
                      Sent by:                     Subject:  RE: OCSP response pre-production                                              
                      owner-ietf-pkix@mail.                                                                                                
                      imc.org                                                                                                              

                      10/03/2003 09:11 AM                                                                                                  

Mike,

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 hope this answers your question.

Frank

                      "Michael Myers"
                      <[email-masked]        To:       Frank Balluffi/NewYork/DBNA/DeuBa@DBNA, <[email-masked]>
                      >                        cc:       "David Engberg" <[email-masked]>, <[email-masked]>
                      Sent by:                 Subject:  RE: OCSP response pre-production
                      owner-ietf-pkix@m
                      ail.imc.org

                      10/02/2003 06:08
                      PM

> -----Original Message-----
> From: Frank Balluffi
>
> . . .
>
> 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,

Would you object the v1/v2 dual paths as means of getting this
into place?

Mike

--

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.

--

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.