RE: OCSP response pre-production

["Florian Oelmaier" <oelmaier@xxxxxxxxxxx>]

I have no problem with your proposal, but allow me to add one further differentiation to your point 3:

------ 

I think the options a responder might want to signal are instead:

1. Here is an answer..  it is cached as they are the only type I produce
2. Here is an answer..  it is cached, though I could have produced a custom-made response if you wanted it
3. Here is a custom-made answer tailored to the request
4. Here is a custom-made answer without having requested it
5. ERROR..  I cannot produce custom-made answers
6. ERROR..  I insist that clients use nonces for extra protection

------ 

-- 
Florian Oelmaier
SyTrust

On Tue, 30 Sep 2003 13:03:23 +1000, "Manger, James H" <James.H.Manger@xxxxxxxxxxxxxxxx> wrote :

> 
> Item B) should be:
> 
> B) Client wants to get a custom-made response, but will also accept a pre-produced/cached response IF AND ONLY IF THE SYSTEM IS INCAPABLE OF PROVIDING A CUSTOM-MADE RESPONSE.
> 
> 
> I think the options a responder might want to signal are instead:
> 
> 1. Here is an answer..  it is cached as they are the only type I produce
> 2. Here is an answer..  it is cached, though I could have produced a custom-made response if you wanted it
> 3. Here is a custom-made answer
> 4. ERROR..  I cannot produce custom-made answers
> 5. ERROR..  I insist that clients use nonces for extra protection
> 
> 
> 1 & 2 could be distinguished by the absence and presence of the nonce extension in the response respectively (the value of the response nonce is irrelevant).
> 
> 
> 
> -----Original Message-----
> From: Florian Oelmaier [mailto:oelmaier@xxxxxxxxxxx]
> Sent: Tuesday, 30 September 2003 9:58 AM
> To: 'Michael Myers'; ietf-pkix@xxxxxxx
> Subject: RE: OCSP response pre-production
> 
> > We have discovered a hole.  To give it a name let's call it 
> > Nonce Capability Discovery.  This hole will not be filled by 
> > artful requirements language alone.  We need proposed technical
> > components: a few bits of ASN.1 and associated semantics.
> 
> So we need some additional signalling between client and responder. I
> tried to list all the items a client would like to signal to the
> responder and the other way round.
> 
> The client has 3 options that he would like to signal to the responder:
> A) Client will accept a pre-produced/cached response. 
> B) Client wants to get a custom-made response, but will also accept a
> pre-produced/cached response.
> C) Client wants to get a custom-made response and will not accept
> pre-produced/cached responses.
> 
> A responder has 5 options that he would like to signal to the client:
> 1) Responder wants others to be able to cache (replay) this response
> 2) The response is a cached copy from another soure or was pre-produced
> 3) This is a custom-made response to a particular request (this
> obviously includes 4)
> 4) This particular response should not be used in any type of caching
> (replaying) 
> 5) Error: This Responder cannot produce custom-made responses
> 
> What about the following proposal (numbers corresponding to the signals
> above):
> 
> A) Client does not include nonce into request.
> B) Client includes nonce into request.
> C) Client includes nonce into request and marks it CRITICAL.
> 
> 1) Responder does not include nonce into response.
> 2) Responder does not include nonce into response.
> 3) Responder copies the nonce of the request into the response
> 4) If the request did not contain a nonce, the responder generates a
> nonce for the response
> 5) We add a new error code 7: "Nonce extension cannot be processed"
> 
> Advantage: We only need to change minor things in the RfC:
> - allow for CRITICAL on extensions
> - add a new error code
> - add some clarifications / text.
> 
> Disadvantage of this proposal: 
> - we miss the opportunity to signal the "source of validation" - CRL vs.
> fresh/live data.
> - We cannot distinguish 1) and 2).
> 
> -- 
> Florian Oelmaier
> SyTrust
> 
> 
> 
> 
>