On Mon, Nov 17, 2025 at 6:42 AM <[email protected]> wrote:
> Re-, > > > > I think there is a disconnect here. > > > > My DISCUSS point is clear: how can you make use of > draft-ietf-tls-tls13-pkcs without relaxing what is the base spec? > And this document does so, regardless of whether 8446 is updated. It permits servers to advertise support and clients to negotiate it. That overrides the text in 8446. > Great to hear that you “can clarify this point there in AUTH48”, but > that’s not sufficient to clear my DISCUSS. I would appreciate if you can > share the proposed change so that we can move on. Thanks. > https://github.com/tlswg/tls13-spec/pull/1399/files Please clear your DISCUSS. -Ekr > > > Cheers, > > Med > > > > *De :* Eric Rescorla <[email protected]> > *Envoyé :* lundi 17 novembre 2025 15:32 > *À :* BOUCADAIR Mohamed INNOV/NET <[email protected]> > *Cc :* The IESG <[email protected]>; [email protected]; > [email protected]; [email protected] > *Objet :* Re: [TLS] Mohamed Boucadair's Discuss on > draft-ietf-tls-tls13-pkcs1-06: (with DISCUSS and COMMENT) > > > > > > > > > > On Mon, Nov 17, 2025 at 6:13 AM <[email protected]> wrote: > > Eric, > > > > Hmm. > > > > As you ask, this falls under technical/implementation issue as it relates > to how the intended feature can provided given the restriction in the bis. > > > > I do not agree with this statement. The document is unambiguous on > what itallows, and adding an "Updates" field will not make it > anymore clear. Moreover, as we've discussed 8446bis is already *ahead* > of this document in the queue,and we can clarify this point there in > AUTH48. > > I appreciate that you would prefer a different resolution, but this > seems tome to fall rather under the following non-criteria: > > "Disagreement with informed WG decisions that do not exhibit problems > outlined in Section 3.1 (DISCUSS Criteria). In other words, > disagreement in preferences among technically sound approaches." > > as well as: > > "Pedantic corrections to non-normative text. Oftentimes, poor phrasing > or misunderstandings in descriptive text are corrected during IESG > review. However, if these corrections are not essential to the > implementation of the specification, these should not be blocking > comments." > > Accordingly, I would ask you to remove your discuss and allow this > > document to proceed. > > > -Ekr > > > > Cheers, > > Med > > > > *De :* Eric Rescorla <[email protected]> > *Envoyé :* lundi 17 novembre 2025 15:01 > *À :* BOUCADAIR Mohamed INNOV/NET <[email protected]> > *Cc :* The IESG <[email protected]>; [email protected]; > [email protected]; [email protected] > *Objet :* Re: [TLS] Mohamed Boucadair's Discuss on > draft-ietf-tls-tls13-pkcs1-06: (with DISCUSS and COMMENT) > > > > > > > > > > On Mon, Nov 17, 2025 at 1:02 AM Mohamed Boucadair via Datatracker < > [email protected]> wrote: > > Mohamed Boucadair has entered the following ballot position for > draft-ietf-tls-tls13-pkcs1-06: Discuss > > 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/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Hi David and Andrei, > > Thank you for the effort put into this specification. > > Updated the ballot [1] to take into account the feedback received so far > (including off-list clarification from Paul; Thanks). > > The only pending point is: > > # Update RFC8446/RFC8446bis > > The provisions in this draft relax what used to be disallowed in > 8446/8446bis. > This reads like an update. > > Specifically, this part from RFC8446bis: > > and > > In addition, the signature algorithm MUST be compatible with the key > in the sender's end-entity certificate. RSA signatures MUST use an > RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5 > algorithms appear in "signature_algorithms". > > > > Can you please identify which DISCUSS criteria item you believe this > > DISCUSS corresponds to? > > > > -Ekr > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # FIPS 186-4 > > ## Please add a reference > > ## s/with FIPS 186-4/with US FIPS 186-4 > > # TLS Registries > > CURRENT: > IANA is requested to create the following entries in the TLS > SignatureScheme registry, defined in [RFC8446]. > > Isn’t draft-ietf-tls-rfc8447bis authoritative here for registry matters? I > would replace the 8446 citation with draft-ietf-tls-rfc8447bis. > > Cheers, > Med > > [1] https://mailarchive.ietf.org/arch/msg/tls/dimNOvXqeIaYflBK7s51J43p80U/ > > > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > ____________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > > Thank you. > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
