Re: [TLS] First TLS cached information draft posted

[Min Huang <huangmin123 at huaweisymantec.com>]

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