Subject: [TLS] draft-ietf-tls-cached-info-14

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 28 Mar 2013 09:29:58 +0200

Hi all, 

I just submitted an updated version of the TLS cached info document to incorporate the suggestions initially raised by Stefan in http://www.ietf.org/mail-archive/web/tls/current/msg09038.html, later discussed on the mailing list at http://www.ietf.org/mail-archive/web/tls/current/msg09253.html and also presented during the IETF#86 meeting. 

The updated document does not yet include the recently raised issue by Rob (see http://www.ietf.org/mail-archive/web/tls/current/msg09352.html).

Ciao
Hannes

---

From: Sean Turner <[email-masked]>
Date: Thu, 28 Mar 2013 13:21:16 -0400

Does this version address all known outstanding issues?

spt

On 3/28/13 3:29 AM, Hannes Tschofenig wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 28 Mar 2013 20:41:06 +0200

Hi Sean,

It addresses all open issues we had at the IETF meeting. 

It does not yet contain the text for adding the OCSP response caching, as suggested by Rob (see http://www.ietf.org/mail-archive/web/tls/current/msg09352.html). 
I could propose some text by tomorrow since I believe it is useful functionality. 

Ciao
Hannes

---

From: Sean Turner <[email-masked]>
Date: Thu, 28 Mar 2013 14:43:15 -0400

I'd like to keep the pedal down on this one so please do suggest some 
text and let's try to get this one out the door.

spt

---

From: Rob Stradling <[email-masked]>
Date: Thu, 28 Mar 2013 21:23:21 +0000

> I could propose some text by tomorrow since I believe it is useful functionality.

Hannes,

For Multi-Stapling, there will be cases where a TLS client has 
previously seen the OCSP Response(s) for the Intermediate(s) but not yet 
seen the OCSP Response for the End-entity cert.

It would be useful in such cases if Cached-Info would enable the TLS 
server to only have to send the OCSP Response(s) that the TLS client 
hasn't previously cached.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 29 Mar 2013 20:34:28 +0200

Hi Rob, 

I worked on a document update and the current snapshot can be found here: 
https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-15.txt

Let me know if that fits your needs. 

Ciao
Hannes

On Mar 28, 2013, at 11:23 PM, Rob Stradling wrote:

> For Multi-Stapling, there will be cases where a TLS client has previously seen the OCSP Response(s) for the Intermediate(s) but not yet seen the OCSP Response for the End-entity cert.
> 
> It would be useful in such cases if Cached-Info would enable the TLS server to only have to send the OCSP Response(s) that the TLS client hasn't previously cached.
> 
>> Ciao
>> Hannes
>> 
> This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.