Re: [TLS] First TLS cached information draft posted

[Stefan Santesson <[e-mail]>]

Ming and Simon,

As you both seems to have misunderstood what I intended to say here.

What I currently think is the correct way is to include just one
CachedObject structure for each cached information type (e.g. One for
certificate data and one for CA names).

This CachedObject stucture may contain any number of hashes. This might be
hashes using different algorithms over the same object or it may be hashes
of the same kind over different objects (e.g. multiple acceptble certs). It
is just an unordered list of hashes.

The server now takes the data it intended to send. And compute the hash over
that data with as many algorithms it can out of the algorithms used by the
client. If one of the received hashes matches one of the generated hashes,
the match is accepted and the server will return one of the matching hashes
as acceptance of the cache (data replacement).

This is at least how it was intended in the current draft.

This is to me still the simplest, cleanest and easiest approach.

/Stefan



On 09-06-10 8:56 AM, "Min Huang" <[e-mail]> wrote:

> Hi, Stefan
> 
> You said:
> "1) Is it allowed to send over multiple CachedObject elements
> containing the same type identifier?
> Proposed answer = No (you can already include multiple hashes
> for each type)"
> 
> It means that the number of the cached certificate is one or
> it means the hash values of all cached certificates are contained
> in one CachedObject of the same type?
> 
> 
> regards,
> Min
> 
> 
> 
> 
>>>>>>>>>>>> 
> 
> I think I have to try to clarify this
> 
> The client send a cached_information extension which contains a list of
> CachedObject structures.
> 
> Each ChachedObject element contains:
> 
> - type identifier (CachedInformationType type)
> - a list of hash values (CachedInformationHash hashes)
> 
> Each CachedInformationHash contains:
> 
> - Algorithm identifier (HashAlgorithm hash)
> - Hash value (opaque hash_value)
> 
> 
> 
> There are a number of issues that need to be specified or clarified in the
> draft:
> 
> 1) Is it allowed to send over multiple CachedObject elements containing the
> same type identifier?
> 
> Proposed answer = No (you can already include multiple hashes for each type)
> 
> 
> 2) What should the server return in its server hello message for each
> acceptable CachedObject?
> 
> Alternative 1 = The CachedObject element, exactly as it was received by the
> client (with all hashes)
> 
> Alternative 2 = The CachedObject element, but only containing the
> CachedInformationHash elements that is recognize and support.
> 
> Proposed answer = Alternative 1 (This allows the server to say YES in
> principle without analyzing the hash values at the time of Hello exchange)
> 
> 
> 3) Is the server REQUIRED to honor its support of a CachedObject by
> replacing the identified handshake data with a received hash?
> 
> Proposed answer = NO (for reasons raised by Martin)
> 
> 
> 4) What does the server send as replacement for the replaced handshake data?
> 
> Proposed answer = One opaque hash_value (without hash type identifier) that
> was received by the client, which MUST contain a valid hash over the
> replaced data.
> 
> 
> 
> Do you agree?
> 
> /Stefan
> 
> 
>