Re: [TLS] Cached-info substitution

[Stefan Santesson <[e-mail]>]

I had the same type if use case in mind.

I think it is better and rather harmless to allow the flexibility.
Client provide a list.... Server picks one. That is an old, well tested and
useful concept.

/Stefan

On 10-02-19 5:52 PM, "Adam Langley" <[e-mail]> wrote:

> On Fri, Feb 19, 2010 at 11:44 AM, Brian Smith <[e-mail]> wrote:
>> I had been making the (apparently incorrect) assumption that only one
>> CachedObject per CachedInformationType value was allowed in the client
>> hello. I thought the intention here was to have the client always cache/send
>> the value for each information type that was most recently received from the
>> server (perhaps out-of-band). Is there a need for more flexibility than
>> that? AFAICT, for the uses identified so far, there isn't.
> 
> I had interpreted the draft to mean that multiple possible
> CachedObjects with the same type could be presented.
> 
> I can imagine some use cases where this would be helpful: an
> organisation which can multiple serving clusters for the same domain
> name, where each cluster has a different certificate. Or when a new
> certificate was being rolled out to a number of servers, but clients
> were getting load balanced between them.
> 
> However, given that this is only an optimisation, these cases might be
> sufficiently unimportant that we can forbid multiple CachedObjects
> with the same type and reap the benefits in a simpler substitution
> scheme. I think I would be happy with that unless some particularly
> compelling use case arises.
> 
> 
> AGL
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls