Hiya, I've had a read of this and asked for IETF LC to start.
My comments below can be handled with any other IETF LC comments. Thanks, S. - Bits of this are fairly complex reading, given that ECC isn't trivial and nor are the changes nor how they were done to keep some things more or less backwards compatible. It'd help I think if we could say something more about implementation status in the shepherd write-up. - abstract: doesn't this need to say that this obsoletes RFC4492 in the abstract text. (Yes, PITA formalities, I know:-) - 5.1.1: "Note that other specifications have since added other values to this enumeration." Could/should we reference those others? I don't care, but someone will ask and it'd be good to have the answer in the archive if it's "no, and here's why..." - 5.1.1: Is this text still correct: "secp256r1, etc: Indicates support of the corresponding named curve or class of explicitly defined curves." Do we need to say there that we're ditching explicitly defined curves? - 5.2: Is this still right, given the deprecation of compressed points earlier? " Note that the server may include items that were not found in the client's list (e.g., the server may prefer to receive points in compressed format even when a client cannot parse this format: the same client may nevertheless be capable of outputting points in compressed format)." - 5.3: Doesn't this need a change: "...unless the client has indicated support for explicit curves of the appropriate type"? Maybe more change is needed in that para as well? - section 6: Do we still need the *_NULL_* suites? - Just checking, I assume this is down to editing history but what happened to TBD1 and TBD2?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
