On 16 Jun 2012, at 20:19, Tobias Gondrom <[email protected]> wrote:
> <hat="individual"> Same here in this message. > +1. I would agree with Jeff on that. > (Mostly because I see no other good solution.) > Any other comments/ideas on this one? I tend to think that "don't use this hammer if it doesn't suit you" is the best answer here. Exceptions are bad (hard to handle properly). > > Best regards, Tobias > > On 15/06/12 02:06, =JeffH wrote: >> > 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 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
