HSTS: explain some practical implications of includeSubDomains directive

[jeff.hodges@…]

the includeSubDomains directive has some practical implications -- for example, if a HSTS host offers http-based services on various ports, then they will all have to be TLS/SSL-based in order to work properly.

For example, certification authorities often offer their CRL distribution and OCSP services over plain HTTP, and sometimes at a subdomain of a publicly-available web application which may be secured by TLS/SSL. E.g. ​https://example-ca.com/ is a publicly-available web application for "Example CA", a certification authority. Customers use this web application to register their public keys and obtain certificates. Example CA generates certificates for customers containing <​http://crl-and-ocsp.example-ca.com/> as the value for the "CRL Distribution Points" and "Authority Information Access:OCSP" certificate fields.

If example-ca.com were to issue an HSTS Policy with the includeSubDomains directive, then HTTP-based user agents implementing HSTS, and that have interacted with the example-ca.com web application, would fail to retrieve CRLs and fail to check OCSP for certificates because these services are offered over plain HTTP.

In this case, Example CA can either..

• not use the includeSubDomains directive, or,

• ensure HTTP-based services offered at subdomains of example-ca.com are uniformly offered over TLS/SSL, or,

• offer plain HTTP-based services at a different domain name, e.g. example-ca-services.net.