On Wed, Oct 22, 2025 at 4:32 PM Eric Rescorla <[email protected]> wrote:
> On Wed, Oct 22, 2025 at 1:24 PM David Benjamin <davidben= > [email protected]> wrote: > >> Ah, nice catch! That's unfortunate.... do we need to mark the document >> as updating 8446 with an update to just disregard that sentence? >> > > 8446bis is ahead of 8446 in the pipeline so maybe we just remove the line > in 8446bis. > > -Ekr > Works for me. :-) For completeness, this is the text which makes that sentence redundant: > These values refer solely to signatures which appear in certificates (see Section 4.4.2.2) and are not defined for use in signed TLS handshake messages, although they MAY appear in "signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2. https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-14.html#section-4.2.3-7.2.1 That text is perfectly compatible with draft-ietf-tls-tls13-pkcs1 because they're only talking about those codepoints, and make no statement about other codepoints the WG may define later. David > On Tue, Oct 21, 2025 at 5:08 PM Mike Bishop via Datatracker < >> [email protected]> wrote: >> >>> Mike Bishop has entered the following ballot position for >>> draft-ietf-tls-tls13-pkcs1-06: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >>> for more information about how to handle DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I've previously reviewed this document, and the changes are minor. It >>> looks >>> like a solid solution for these devices. I believe "N" is an appropriate >>> value >>> since that indicates the value "either has not been through the IETF >>> consensus >>> process, has limited applicability, or is intended only for specific use >>> cases" >>> -- this document clearly describes why, despite having IETF consensus, >>> it falls >>> into the latter two buckets. >>> >>> However, it does seem clear that this document modifies restrictions in >>> RFC8446(bis). While it defines new codepoints with differing behavior >>> for the >>> SignatureScheme enum and thus isn't changing the definition of those >>> codepoints, it is modifying the requirement in CertificateVerify >>> handling that >>> `RSA signatures MUST use an RSASSA-PSS algorithm, regardless of whether >>> RSASSA-PKCS1-v1_5 algorithms appear in "signature_algorithms".` >>> >>> >>> >>> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
