>> Strict-Transport-Security = "Strict-Transport-Security" ":"
>> directive *( ";" [ directive ] )
>>
>> STS directives:
>>
>> directive = max-age | includeSubDomains | STS-d-ext
>>
>> max-age = "max-age" "=" delta-seconds
>
> What happens with
>
> max-age="1"
>
> ?
>
> Do you expect all recipients to reject this? Depending on the parsing
> API they use they might not even know that the value was quoted on the wire.
Offhand, I'm not super sure, but after thinking about it while
researching/writing the below, I'm thinking "yes", max-age="1" is invalid
according to the ABNF and we should do whatever we do in error cases (which is
a separate open question). But implementors' parsing API and its problems are
out-of-scope for a spec such as this.
This obviously isn't the first HTTP response header field with such a syntax
and thus these potential issues (this one with a delta-seconds value, and the
issue you note below wrt "includeSubDomains"), yes?
In doing a quick grep on RFCs for delta-seconds, I note that some of the specs
using it (I didn't look at them all) appear to not directly address the case above.
Except for RFC6265, which in the algorithm for parsing "Max-Age=", it
algorithmically provides for ignoring a value that doesn't match the effective
value ABNF of..
["-"]*DIGIT
..which would catch the max-age="1" case, but doesn't seem to explicitly
address..
max-age=
But in any case, perhaps (additional) browser implementor folk could chime in
here -- do we really need to address such detail-level issues (both of the
examples above and below) in the syntax/grammar we specify in specs such as
these? Or is the new ABNF proposed in the original message in this thread
sufficient?
> > includeSubDomains = "includeSubDomains"
>
> There's a tiny risk that some implementations will handle value-less
> parameters the same way as parameters with empty values, such as
>
> includeSubDomains=
>
> or
>
> includeSubDomains=""
>
> but maybe I'm over-engineering here.
Yes, I'm wondering if this might be over-engineering -- I note that in
RFC 6266 you didn't distinguish/address this sort of case for "inline" or
"attachment" -- are you feeling now that you should have, and thus we ought to
do so going forward?
> Also, identifiers "max-age" and "includeSubDomains" are
> case-insensitive, right? This follows from the ABNF,
yes, and yes.
> but might be worth
> saying again in prose; in particular because it also needs to be the
> case for all future extensions.
Agreed. I see how you did it in RFC 6266 and will endeavor to do similarly.
thanks again,
=JeffH
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
