Re: Last Call: <draft-hallambaker-tlsfeature-09.txt> (X.509v3 TLS Feature Extension) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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).





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]