Hiya,
I'm the sponsoring AD for this. I had some non-blocking
comments that I'd like to be considered with other IETF
last call comments.
S.
- I still find the phrase "TLS feature extension" confusing
given section 1.2.
- section 2, 3rd last para: I think this SHOULD NOT is
broken, how (in general) can a CA check/know that it's true
and that it will continue to be true?
- 3.1, para 1 could do with a forward pointer to the
relevant bit of IANA considerations.
- 3.1, 2nd last para, last sentence: I'm not sure I get the
sentence's meaning - it has two MAY statements and a double
negative. I bet a re-phrase (as a positive statement) or
breaking into two boring sentences could be a lot simpler.
- 3.2.2: I wonder if this is really a good idea. (Still)
- 3.2.3: and elsewhere: What exactly does "reject the TLS
configuration" mean? I think you mean the cert and/or
handshake? (And those might differ e.g. with http opp-sec.)
If you need this term, why not define it at the top?
- 3.2.3.1: you could add a reference to RFC7435 at the end
there to justify the MUST NOT.
- 3.3.3: 1st para ends without a "."
- 3.3.3: I think the "treat as bad cert" model is ok, but I
do wonder if that's been fully thought through - would it
maybe be better to treat the bad case as a handshake
failure?
- 5.1: the section title isn't great, maybe "Bad
Certificates" would be better?
- 5.x: I think you could add a risk that we're adding a new
way to brick your site a bit, either via certificate update
or (less likely) s/w update (say if a server deprecates a
feature).