<hat="individual">
+1. I would agree with Jeff on that.
(Mostly because I see no other good solution.)
Any other comments/ideas on this one?
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
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
