Subject: Re: [TLS] TLS Cached Information Extension - version 11

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Jul 2012 12:40:38 +0300

Hi Rob, 

me again. 

> 
> 2. Currently, cached-info only allows a TLS Client to indicate to the TLS Server a list of static Objects that it _doesn't_ want to receive (because it already has them).
> i.e. "Don't send me any Objects of Type X, Y or Z that match Digests A, B or C".
> 
> How about extending this so that the TLS Client can indicate types of Object that it _does_ want to receive?
> i.e. "Do send me any Objects of Type X, Y and Z that you have, excluding any that match Digests A, B or C".

I am open for feedback from the group on this issue. I have not heard anyone asking for it so far. 

> 
> This added functionality could meet the needs of several other TLS extensions that are being proposed, for example...
>  - Multiple OCSP Responses [2].
>  - Audit proofs for Google's Certificate Transparency proposal [3].
>  - TACK rules for Convergence [4].
> 
> Or, is it your explicit intention to restrict cached-info so that it only supports the "standard" TLS handshake objects (e.g. Certificate, Trusted CAs list).
> (I can see that such a restriction could help to ensure that client-side code can be implemented entirely within the network layer rather than bleeding into the application layer).

There is no intention to restrict the functionality to certain extensions. 

I do, however, believe that new documents should add a description to their document how this document could be used in combination with the TLS cached information extension. 

I don't think it makes sense to add text about, for example, draft-pettersen-tls-ext-multiple-ocsp when that work is still in progress. 

Ciao
Hannes

[2] http://tools.ietf.org/html/draft-pettersen-tls-ext-multiple-ocsp
[3] http://www.links.org/file/CertificateAuthorityTransparencyandAuditability.pdf
[4] https://github.com/moxie0/Convergence/wiki/TACK