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

[Rob Stradling <[e-mail]>]

On 08/04/13 21:07, Yngve N. Pettersen wrote:
<snip>
>> Example:
>>    - Client visits https://www.google.com and https://mail.google.com,
>> each for the first time ever, and caches the certificate chains and
>> OCSP Responses for the End-entity and Intermediate certs.  Client
>> observes that the same "Google Internet Authority" Intermediate is
>> used in both cases.
>>    - A while later, client performs another full handshake to
>> https://www.google.com and gets back a different OCSP Response (with a
>> more recent thisUpdate value) for the same Intermediate cert.
>>    - A while later, client performs another full handshake to
>> https://mail.google.com.  It sends the CachedObject for the
>> Intermediate OCSP Response that https://www.google.com just returned,
>> because it knows that this OCSP Response is relevant for the
>> Intermediate cert that https://mail.google.com used last time the
>> client connected to it, and because this OCSP Response is the freshest
>> one that the client has available.
>
> What about www.co.uk and bank.co.uk?
>
> Such things get complicated very fast, which is why we had to develop
> the public suffix list.
>
> Please, let us stay way, way, *way* out of that particular thorny area.

If the End-entity certs at https://www.co.uk and https://bank.co.uk are 
both issued by the same Intermediate, then what's the problem?
Why are the domain names even relevant when deciding whether or not it's 
"safe" for the client to send an Intermediate cert's OCSP Response that 
a different server provided?

I agree that my proposal should be rejected _if_ the consensus is that 
it adds too much extra complexity.  But IMHO the more bytes on the wire 
we can save, the more chance there is that Multi-Stapling + Cached-Info 
will actually get deployed widely.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online