Blame to go around. I looked at your PR: https://github.com/tlswg/tls13-spec/pull/1449 And thought well 9846 is obsoleting 8446 so implementers shouldn’t even look at 8446 so the references in that list ought to be to 9846: https://github.com/tlswg/tls13-spec/pull/1451 I’ll try to synch up with ekr soonest to get this done.
spt > On Jun 23, 2026, at 06:26, Deb Cooley <[email protected]> wrote: > > It is indeed 8446bis.... If you want to lean on him, do it. Sean may know > better where that draft sits (who is holding the pen). > > I would think that a small change, like you propose would be fine (and I'm > sort of surprised it wasn't flagged earlier). > > Deb > > On Tue, Jun 23, 2026 at 3:32 AM Hannes Tschofenig <[email protected] > <mailto:[email protected]>> wrote: >> I do not think it is me holding this up. I have given my approval a while >> ago already. I believe the publication is blocked by the completion of >> draft-ietf-tls-rfc8446bis. >> >> >> >> Am 23.06.2026 um 07:36 schrieb Martin Thomson: >>> Hi everyone, >>> >>> This has taken far, far too long. What is the hold up? >>> >>> If the answer is Ekr, as I suspect it is, I might be able to help with >>> that. Five months is totally unacceptable. >>> >>> Cheers, >>> Martin >>> >>> p.s., I have a small patch to this that I would like to request. As the >>> patient is open... >>> (In short, one of the lines of hex has one character too many on one line. >>> Moving that to the next line makes it neater.) >>> >>> ~~~ >>> diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md >>> index 922388c..836f4fe 100644 >>> --- a/draft-ietf-tls-keylogfile.md >>> +++ b/draft-ietf-tls-keylogfile.md >>> @@ -467,22 +467,22 @@ CLIENT_RANDOM \ >>> >>> The following shows a log entry for a TLS 1.3 connection that successfully >>> negotiated ECH. >>> >>> ~~~ application/sslkeylogfile >>> ECH_SECRET \ >>> 0ba587ee6b65ce21a726630efb881206a7cd995611095b5f4c244bb2b23f1ee1 \ >>> e8828ec09909cc9363179dc13b62498550c8637129345263011a1678370ca52a >>> ECH_CONFIG \ >>> 0ba587ee6b65ce21a726630efb881206a7cd995611095b5f4c244bb2b23f1ee1 \ >>> - fe0d003c5500200020d5260ae4cdda08bcbdc37bd0dc53c29aea5f0fdd2b2d594\ >>> - e4235e99b134ac904000400010001000d636f7665722e6465666f2e69650000 >>> + fe0d003c5500200020d5260ae4cdda08bcbdc37bd0dc53c29aea5f0fdd2b2d59 \ >>> + 4e4235e99b134ac904000400010001000d636f7665722e6465666f2e69650000 >>> CLIENT_HANDSHAKE_TRAFFIC_SECRET \ >>> 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ >>> a195b63ec4270609692a204c08e63e74d9ae58e377d11a383bfe641a63c01140 >>> SERVER_HANDSHAKE_TRAFFIC_SECRET \ >>> 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ >>> 022d1cb827a90f27dadde0c99110c2b7d0f362fdfe420a04818aa223e5f2c14c >>> CLIENT_TRAFFIC_SECRET_0 \ >>> 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ >>> c2310f7db71109de88bab6f2f433fdc1704aecc0d57349cbf9113e5033178172 >>> SERVER_TRAFFIC_SECRET_0 \ >>> ~~~ >>> >>> >>> On Tue, Jan 6, 2026, at 11:28, Alanna Paloma wrote: >>>> All, >>>> >>>> IANA has finished updating its registry accordingly and we now consider >>>> AUTH48 complete: >>>> https://www.rfc-editor.org/auth48/rfc9850 >>>> >>>> As this document is part of Cluster C430, you may track the progress of >>>> all documents in this cluster through AUTH48 at: >>>> https://www.rfc-editor.org/auth48/C430 >>>> >>>> We will move this document forward in the publication process once the >>>> other necessary documents in the cluster complete AUTH48 as well. >>>> >>>> Please let us know if you have any questions. >>>> >>>> Thank you, >>>> Alanna Paloma >>>> RFC Production Center
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
