Found 2 records.

Status: Reported (2)

RFC 6797, "HTTP Strict Transport Security (HSTS)", November 2012

Errata ID: 5204
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Dilßner
Date Reported: 2017-12-13

Section 6.1.2 says:

includeSubDomains

It should say:

include-sub-domains

or

includesubdomains

Notes:

- In Section 6.1 the Strict-Transport-Security is defined as follows:

Strict-Transport-Security = "Strict-Transport-Security" ":" [ directive ] *( ";" [ directive ] )

- valueless Directive "includeSubDomains" is defined as a optional directive
- a directive is definied as followed:

directive = directive-name [ "=" directive-value ]

- so "includeSubDomains" is only a directive-name which is defined as "token"
- according to "[RFC2616], Section 2.2" a token is any octet from 0 - 127 except CTL's (octets 0 - 31 + 127) and separators which NOT exclude '-' (octet 45)


So all Fine? Yes, BUT at [RFC6797], Section 6.1 the "overall reuqirements for directives", Rule 3 defines:

3. Directive names are case-insensitive.

And there is no other specification in Section 6.1.2 or has a IANA policy definition [RFC5226] like it is defined for additionals.



- That means the "directive-name" includeSubDomains is "case-insensitive"!

The "case-sensitive" camelized directive-name is misleading, because of many other definitions with "-", like seen in all examples or in Header Field itself.


- to aware the clear understanding the "directive definition" in section 6.1.2 and ALL occurences needs to be renamend.

the minimum of renaming is "includesubdomains" OR "INCLUDESUBDOMAINS", but this is not readable anymore.
- So it should be renamed like other valuless directives for Example the "schemes-source's" directives at "Content-Security-Policy", which means:

"include-sub-domains"


Best Regards

Nick

Errata ID: 5372
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Claudio Saavedra
Date Reported: 2018-05-29

Section 8.1 says:

o  Update the UA's cached information for the Known HSTS Host if
      either or both of the max-age and includeSubDomains header field
      value tokens are conveying information different than that already
      maintained by the UA.

It should say:

o  Update the UA's cached information for the Known HSTS Host.

Notes:

Section 8.1 states:

Update the UA's cached information for the Known HSTS Host if either
or both of the max-age and includeSubDomains header field value
tokens are conveying information different than that already
maintained by the UA.

The way I understand this is that if a HSTS host keeps sending the same values to a conforming client, this should not update the information cached and hence the cached information will expire after max-age seconds have passed since the _first_reception_ of this header.

However, section 11.2 states:

The "constant value into the future" approach can be accomplished by
constantly sending the same max-age value to UAs.

For example, a max-age value of 7776000 seconds is 90 days:

Strict-Transport-Security: max-age=7776000

Note that each receipt of this header by a UA will require the UA to
update its notion of when it must delete its knowledge of this Known
HSTS Host.

This seems to contradict what I quoted from section 8.1. If the server constantly sends a max-age of 7776000 and includeSubDomains is not changed (which is implicit in the example), then by 8.1 the cache
information won't be updated.

I believe that the desired implementation behavior is as described in 11.2, that is, UA must update the cached information, regardless of whether either of the max-age or includeSubDomains header field values are different from what is already maintained by the UA.

Report New Errata