I would also remove the spurious paren instead -- having a MUST NOT inside a paren seems suboptimal to me.
/Simon fre 2018-08-17 klockan 14:09 +1000 skrev Martin Thomson: > Looks good. I would remove the trailing paren instead though. > On Fri, Aug 17, 2018 at 12:08 PM RFC Errata System > <rfc-edi...@rfc-editor.org> wrote: > > > > The following errata report has been submitted for RFC8422, > > "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport > > Layer Security (TLS) Versions 1.2 and Earlier". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5466 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Masato Gosui <mgo...@yahoo-corp.jp> > > > > Section: 5.3 > > > > Original Text > > ------------- > > Actions of the sender: > > > > The server constructs an appropriate certificate chain and > > conveys it > > to the client in the Certificate message. If the client has > > used a > > Supported Elliptic Curves Extension, the public key in the > > server's > > certificate MUST respect the client's choice of elliptic > > curves. A > > server that cannot satisfy this requirement MUST NOT choose an > > ECC > > cipher suite in its ServerHello message.) > > > > Corrected Text > > -------------- > > Actions of the sender: > > > > The server constructs an appropriate certificate chain and > > conveys it > > to the client in the Certificate message. If the client has > > used a > > Supported Elliptic Curves Extension, the public key in the > > server's > > certificate MUST respect the client's choice of elliptic > > curves. (A > > server that cannot satisfy this requirement MUST NOT choose an > > ECC > > cipher suite in its ServerHello message.) > > > > Notes > > ----- > > This adds the missing opening parenthesis of the last sentence of > > the "Actions of the sender" paragraph. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, > > please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8422 (draft-ietf-tls-rfc4492bis-17) > > -------------------------------------- > > Title : Elliptic Curve Cryptography (ECC) Cipher > > Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier > > Publication Date : August 2018 > > Author(s) : Y. Nir, S. Josefsson, M. Pegourie-Gonnard > > Category : PROPOSED STANDARD > > Source : Transport Layer Security > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls
signature.asc
Description: This is a digitally signed message part
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
