sections 6.1.1 and 6.1.2 describe the syntax particular to max-age and
includeSubDomains directives, and neither of those directives employ
quoted-string, and I don't think they need to or should.
I think they should, because it's likely that people will write parses
that allow
#33: HSTS: quoted-string grammar in (extension) directives ?
Changes (by jeff.hodges@…):
* status: closed = reopened
* resolution: fixed =
Comment:
Need to re-fix STS grammar that appears in -06 (see entire thread rooted
here)...
#39: appropriately acknowlege and accommodate DANE
see..
Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06
until April-9 (paul hoffman)
https://www.ietf.org/mail-archive/web/websec/current/msg01092.html
This document pretends that the TLSA protocol from the DANE WG
#40: Various editorial comments on -06
https://www.ietf.org/mail-archive/web/websec/current/msg01092.html - paul
hoffman
Editorial:
annunciate (used a few times) is a fancy word for announce. Maybe use
the far more common word instead.
In section 3.1, suboptimal downside is unclear. Is
On 2012-03-26 10:29, =JeffH wrote:
I'm not sure how to cleanly and unambiguously define them in terms of
both token and quoted-string (and retain max-age's basis on
delta-seconds). Perhaps you could propose how to do this?
Just define the base grammar for the overall parsing; such as
Hi
It was my review that triggered this, so I'd like to explain my position.
There are several things that could be considered failures of the TLS layer:
1. Revoked certificate
2. No CRL/OCSP response
3. Expired certificate
4. Expired CRL (yes, I know NextUpdate is not expiry…)
5. Mismatch
Hi
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
