[ resent with correct Subject: ]
Hi Alexey, thanks for the review, apologies for latency.
> The two directives defined in this specification are described below.
> The overall requirements for directives are:
>
> o The order of appearance of directives is not significant.
>
> o All directives MUST appear only once in an STS header field.
>
> o Directive names are case-insensitive.
>
> o UAs MUST ignore any STS header fields containing directives that
> do not conform to their ABNF definition.
>
> Should this list also say something about how unrecognized directives
> should be treated? I.e. are they ignored by default, is the whole
> STS header field ignored, etc.
Does the last bullet item above not address those questions?
> Additional directives extending the semantic functionality of the STS
> header field may be defined in other specifications (which "update"
> this specification),
>
> Is this a requirement on future extensions?
> (In general "updating" this specification using Updates: in the header
> of the relevant RFC
> is a) a heavy weight mechanism (it prevents Experimental extensions) and
> b) this seems
> like a wrong mechanism anyway, as Updates usually means that the
> document being
> updated can't be implemented without the document which updates it.)
We can place in the above para whatever we/you/ourADs wish. Suggestions welcome.
> 8.3. Errors in Secure Transport Establishment
>
> When connecting to a Known HSTS Host, the UA MUST terminate the
> connection (see also Section 11 "User Agent Implementation Advice",
> below) if there are any errors (e.g., certificate errors), whether
> "warning" or "fatal" or any other error level, with the underlying
> secure transport. This includes any issues with certificate
> revocation checking whether via the Certificate Revocation List (CRL)
> [RFC5280], or via the Online Certificate Status Protocol (OCSP)
> [RFC2560].
>
> This was discussed in Paris, but I had this in my notes already and would
> like to emphasize this: I assume that explaining the reason for the failure
> to the user (without letting the user to opt-out) is Ok? I think the
> document
> needs to make it clear that this is not prohibited.
the above is being discussed in the "Showing errors in HSTS" thread.
> 10.3. Implications of includeSubDomains
>
> For example, certification authorities often offer their CRL
> distribution and OCSP services over plain HTTP, and sometimes at a
>
> The first use of OCSP needs an Informative reference.
It's referenced way up at beginning of spec, but now ref'd here also in my -07
working copy.
> subdomain of a publicly-available web application which may be
> secured by TLS/SSL. For example, <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.
>
> 13. Internationalized Domain Names for Applications (IDNA): Dependency
> and Migration
>
> IDNA2008 obsoletes IDNA2003, but there are differences between the
> two specifications, and thus there can be differences in processing
> (e.g., converting) domain name labels that have been registered under
> one from those registered under the other. There will be a
> transition period of some time during which IDNA2003-based domain
> name labels will exist in the wild. User agents SHOULD implement
> IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of
> [RFC5894]) or [UTS46] in order to facilitate their IDNA transition.
>
> I might be kicking a dead horse here, but MAY sounds a bit weak.
> I especially dislike having the choice between 2 incompatible specs,
> I think this might cause some interop problems.
As far as I can tell, having had fairly extensive discussions with IDNA folk
both privately and on various lists such as idna-update@, the above relects the
the unfortunate state of the world at this time. For instance, Pete Resnick
signed off on the language in the spec in this message to websec@...
Re: [websec] wrt IDN processing-related security considerations for
draft-ietf-websec-strict-transport-sec
https://www.ietf.org/mail-archive/web/websec/current/msg01015.html
we should probably fork off any further discussion on this topic to that thread.
> Also, does "in order to facilitate their IDNA transition" apply
> to the second reference or to both references?
It applies to both. One may implement [RFC5895] /or/ [UTS46] to facilitate
one's IDNA transition (as I understand it).
again, followups on this item and the above should probably be in the "Re:
[websec] wrt IDN processing-related security considerations for
draft-ietf-websec-strict-transport-sec" thread here on websec@.
> In Section 14.5: NTP needs an Informative Reference.
fixed in my -07 working copy.
> 15. IANA Considerations
>
> Below is the Internet Assigned Numbers Authority (IANA) Provisional
>
> I think here (and below) we should use "Permanent" registration for this
> header field.
>
> Message Header Field registration information per [RFC3864].
>
> Header field name: Strict-Transport-Security
> Applicable protocol: HTTP
> Status: provisional
> Author/Change controller: TBD
> Specification document(s): this one
fixed in my -07 working copy
thanks again,
=JeffH
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
