[TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PR #1361
Thanks, I have no further comments and support merging this change. Cheers, Andrei From: David Benjamin Sent: Friday, June 21, 2024 12:03 PM To: Andrei Popov Cc: Sean Turner ; TLS List Subject: Re: [TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PR #1361 Thanks, Andrei! I have updated the PR to address your comments. For some context, this came about because I noticed that the text in RFC 8446 around the X.509 Key Usage extension was inconsistently applied to only the server certificate half and not the client certificate half. As checking consistency between X.509 Key Usage and the actual use is an important part of avoiding cross-protocol attacks, that seemed important to fix. For example, X.509 Key Usage is how you distinguish an ECDSA key from an ECDH key in X.509. It's even, bizarrely, how you distinguish an end-entity key from a CA key. One would think that's Basic Constraints, but Basic Constraints actually only allows you to say "this is not a CA key". It doesn't let you say "this is not an end-entity key". For that you use the fact that Key Usage uses distinct bits for "sign an X.509 payload" and "sign a protocol-specific payload". X.509 is truly amazing. Anyway, poking from there revealed that, when we made the decision to unify the ClientHello -> Certificate and CertificateRequest -> Certificate extension flow in RFC 8446, we neglected to unify these two sections, so that PR fixes it. On Fri, Jun 21, 2024 at 1:46 PM Andrei Popov mailto:40microsoft@dmarc.ietf.org>> wrote: Added a couple of minor comments; overall this change seems OK. Cheers, Andrei -Original Message- From: Sean Turner mailto:s...@sn3rd.com>> Sent: Friday, June 21, 2024 10:15 AM To: TLS List mailto:tls@ietf.org>> Subject: [EXTERNAL] [TLS]Consensus Call: -rfc8446bis PR #1361 Hi! David Benjamin submitted the following PR to unify some prose related to certificate negotiation in TLS 1.3 (ClientHello/Certificate and CertificateRequest/Certificate are now nice and symmetric): https://github.com/tlswg/tls13-spec/pull/1361 As this has been suggested post WGLC, we need to ensure we have consensus to merge this PR, so please review the PR in its entirety and indicate whether you support merging this PR by 5 July 23:59 UTC. Cheers, spt ___ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org> ___ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org> ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PR #1361
Thanks, Andrei! I have updated the PR to address your comments. For some context, this came about because I noticed that the text in RFC 8446 around the X.509 Key Usage extension was inconsistently applied to only the server certificate half and not the client certificate half. As checking consistency between X.509 Key Usage and the actual use is an important part of avoiding cross-protocol attacks, that seemed important to fix. For example, X.509 Key Usage is how you distinguish an ECDSA key from an ECDH key in X.509. It's even, bizarrely, how you distinguish an end-entity key from a CA key. One would think that's Basic Constraints, but Basic Constraints actually only allows you to say "this is not a CA key". It doesn't let you say "this is not an end-entity key". For that you use the fact that Key Usage uses distinct bits for "sign an X.509 payload" and "sign a protocol-specific payload". X.509 is truly amazing. Anyway, poking from there revealed that, when we made the decision to unify the ClientHello -> Certificate and CertificateRequest -> Certificate extension flow in RFC 8446, we neglected to unify these two sections, so that PR fixes it. On Fri, Jun 21, 2024 at 1:46 PM Andrei Popov wrote: > Added a couple of minor comments; overall this change seems OK. > > Cheers, > > Andrei > > -Original Message- > From: Sean Turner > Sent: Friday, June 21, 2024 10:15 AM > To: TLS List > Subject: [EXTERNAL] [TLS]Consensus Call: -rfc8446bis PR #1361 > > Hi! David Benjamin submitted the following PR to unify some prose related > to certificate negotiation in TLS 1.3 (ClientHello/Certificate and > CertificateRequest/Certificate are now nice and symmetric): > https://github.com/tlswg/tls13-spec/pull/1361 > As this has been suggested post WGLC, we need to ensure we have consensus > to merge this PR, so please review the PR in its entirety and indicate > whether you support merging this PR by 5 July 23:59 UTC. > > Cheers, > spt > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PR #1361
Added a couple of minor comments; overall this change seems OK. Cheers, Andrei -Original Message- From: Sean Turner Sent: Friday, June 21, 2024 10:15 AM To: TLS List Subject: [EXTERNAL] [TLS]Consensus Call: -rfc8446bis PR #1361 Hi! David Benjamin submitted the following PR to unify some prose related to certificate negotiation in TLS 1.3 (ClientHello/Certificate and CertificateRequest/Certificate are now nice and symmetric): https://github.com/tlswg/tls13-spec/pull/1361 As this has been suggested post WGLC, we need to ensure we have consensus to merge this PR, so please review the PR in its entirety and indicate whether you support merging this PR by 5 July 23:59 UTC. Cheers, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
