The extension list cannot actually be empty because we also say: > The "signature_algorithms" extension > MUST be specified, and other extensions may optionally be included > if defined for this message.
That said, enforcing this by rejecting the empty list doesn't do much because the receiver will need to look for specifically the sigalgs extension anyway. So I'm on board with making this say either 0 or 4. Honestly, 2 is fine too... if you check for 2 instead of 4, you'll still have the exact same behavior. In fact I think the sigalgs rule implies the true minimum is 8. But let's not put 8 because it will confuse everyone. I think sometimes we spend a little more energy than is actually useful in figuring out these implied lower bounds. :-) In practice, the only decision we actually care about is whether 0 is allowed, and even then it's often irrelevant (like here). On Thu, Jan 18, 2024 at 3:47 PM Benjamin Kaduk <bkaduk= 40akamai....@dmarc.ietf.org> wrote: > I think if the errata report is moved back into the "reported" state by > the RFC Editor staff, the AD should be able to edit the report to reflect > the intent as opposed to having the diff appear. > > -Ben > > On Tue, Jan 16, 2024 at 07:07:19PM -0800, RFC Errata System wrote: > > The following errata report has been held for document update > > for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". > > > > -------------------------------------- > > You may review the report below and at: > > > https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid5682__;!!GjvTz_vk!T2x_YvOjybcaxb8hARC3CW6xdOhGeq2BD-cjxoPyutXUwQp_f3O3PfnITevFE1EaDkGlyknuPtDLnj4boiBQ1w$ > > > > -------------------------------------- > > Status: Held for Document Update > > Type: Technical > > > > Reported by: Richard Barnes <r...@ipv.sx> > > Date Reported: 2019-04-01 > > Held by: Paul Wouters (IESG) > > > > Section: 4.3.2, B.3.2 > > > > Original Text > > ------------- > > --- rfc8446.txt 2018-08-10 20:12:08.000000000 -0400 > > +++ rfc8446.erratum.txt 2019-04-01 15:44:54.000000000 -0400 > > @@ -3341,7 +3341,7 @@ > > > > struct { > > opaque certificate_request_context<0..2^8-1>; > > - Extension extensions<2..2^16-1>; > > + Extension extensions<0..2^16-1>; > > } CertificateRequest; > > > > > > @@ -7309,7 +7309,7 @@ > > > > struct { > > opaque certificate_request_context<0..2^8-1>; > > - Extension extensions<2..2^16-1>; > > + Extension extensions<0..2^16-1>; > > } CertificateRequest; > > > > > > > > > > Corrected Text > > -------------- > > --- rfc8446.txt 2018-08-10 20:12:08.000000000 -0400 > > +++ rfc8446.erratum.txt 2019-04-01 15:44:54.000000000 -0400 > > @@ -3341,7 +3341,7 @@ > > > > struct { > > opaque certificate_request_context<0..2^8-1>; > > - Extension extensions<2..2^16-1>; > > + Extension extensions<0..2^16-1>; > > } CertificateRequest; > > > > > > @@ -7309,7 +7309,7 @@ > > > > struct { > > opaque certificate_request_context<0..2^8-1>; > > - Extension extensions<2..2^16-1>; > > + Extension extensions<0..2^16-1>; > > } CertificateRequest; > > > > > > > > > > Notes > > ----- > > The length of this vector can never 2. It is either 0, if the vector is > empty, or >=4, if the vector has at least one extension. Nothing elsewhere > in the spec requires a non-zero number of extensions here, so this syntax > should allow a zero-length vector. > > > > Paul Wouters (AD): Richard meant the diff to be the fix, not the > original/corrected text. The diff is not in the RFC itself. There are two > places in the mentioned sections that need this one liner fix. > > > > -------------------------------------- > > RFC8446 (draft-ietf-tls-tls13-28) > > -------------------------------------- > > Title : The Transport Layer Security (TLS) Protocol > Version 1.3 > > Publication Date : August 2018 > > Author(s) : E. Rescorla > > Category : PROPOSED STANDARD > > Source : Transport Layer Security > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!T2x_YvOjybcaxb8hARC3CW6xdOhGeq2BD-cjxoPyutXUwQp_f3O3PfnITevFE1EaDkGlyknuPtDLnj70kj7-uw$ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
