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

["Piyush Jain" <[e-mail]>]

> > [Piyush] Not sure if I understood it correctly. TLS has strict
> > guidelines on
> 
> "Chain sequence" was maybe the wrong expression. The point was that the
> server can change to a completely new set of certificates, including an
> unrelated certificate authority.

[Piyush] Agreed. However, this is usually a rare event. And the cached
certificate_list and stapled OCSP responses would become invalid anyway.
> 
> However, some server can have certificates incorrectly ordered, and that
> might get fixed after a while (or it could get broken).
[Piyush] It probably does not matter as long as the client is assuming the
same order that it received. Please note that certificate_list cache
representation is a single hash. All the client is saying is that this is
the certificate list (containing certificates a,b,c,d) that I have cached
and btw I don't need the status for "a" and "b" but I need the status for
"c" and "d".
> 
> > sequence of certificates in the chain. The certificate chain sequence
> > would change only when the server certificate changes (or in some rare
> > cases when intermediate CA's certificate rolls over). Right? If that
> > happens than certificate_list cached object held by the client would
> > become invalid and consequently any stapled responses associated with
> > the old certificate chain would also become invalid.
> 
> My point is that the information sent to the server about which resources
are
> cached need to connect the resources to what the server have, in such a
way
> that if the server configuration changes the server will know that it does
not
> have the necessary information.
> 
[Piyush] That requirement is met. If the server configuration is changed in
the way that you describe above, certificate_list cache becomes invalid and
consequently the OCSP response cache becomes invalid.
In other words the server will send the certificate list again and all the
OCSP responses again. This would be the behavior even when you fingerprint
the OCSP responses.
I think it becomes more intuitive if you think about the actual goal from
client's perspective. Clients need to determine the status of each
certificate in the server certificate chain. They don't need to make sure
that the OCSPResponses that they use to make this determination are in sync
with those on the server.
The way I see it stapled OCSP responses are not resources on the TLS server.
TLS server is just a channel that delivers these responses to the client.