Re: [websec] #42: STS exception for CRL fetching

[=JeffH <[e-mail]>]

 > This is about fetching CRLs from a domain that happens to be the same as
 > that of a website.
 >
 > Obviously you can't get a CRL or an OCSP response over HTTPS. Jeff's
 > response was that they should use a different domain name for the CRLs (if
 > they want to deploy HSTS)
 >
 > Obviously, it's too late to change AIA or CDP in existing certificates. But
 > I think it goes deeper. HSTS affects what the browser is doing. Different
 > resources from the same domain should all be protected by TLS. But we don't
 > expect this to affect things that are outside the browser, like email or
 > system updates. IMO the fetching of CRLs or OCSP responses is not part of
 > the browsing, but part of the HTTPS handshake. The fact that some browsers
 > implement both is besides the point. Internet Explorer uses an OS library to
 > do the TLS handshake, including any checking of revocation. In fact getting
 > the CRL fetch function to apply the HSTS policy would require extra effort
 > from the browser implementer.
 >
 > I think we should simply say that HSTS does not apply to non-content.
 > Fetching CRLs or browser software updates is not content, and HSTS should
 > not apply to it.

Unfortunately, we would then have to define what comprises "content", and 
that's a huge rathole I think we should unequivocally avoid.

I've taken a (ad-hoc, limited, unscientific) look at the AIA and CDP in some 
existing certificates (from major CAs), and all of the ones I checked used a 
dedicated subdomain for their OCSP responder, e.g...

   evsecure-crl.verisign.com
   evsecure-ocsp.verisign.com
   SVRSecure-G3-crl.verisign.com
   ocsp.verisign.com
   ocsp.thawte.com
   crl.thawte.com


So in order not to cause themselves and their customers problems, CAs simply 
shouldn't issue HSTS policy with "includsubdomains" from their top-level domain 
name, and they will be fine. This is already discussed in S 10.3 of the HSTS 
draft.

HTH,

=JeffH