[TLS] Re: Mohamed Boucadair's Discuss on draft-ietf-tls-tls13-pkcs1-06: (with DISCUSS and COMMENT)

[Paul Wouters <[e-mail]>]

On Mon, Nov 17, 2025 at 9:42 AM <[e-mail]> 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?
>

Extensions often do that. As long as the modification is only needed when
implementing that one extension, most people agree no Updates: clause (or
bis document of the base spec) are needed.

For another recent example of this, see .
https://datatracker.ietf.org/doc/html/draft-pwouters-ipsecme-child-pfs-info-02
which does not update RFC 7296 despite relaxing where KE payloads may
appear in the base 7296 spec.


> 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.
>

Then I do not understand what can clear your discuss. Please specify exact
modifications that you believe would clear your discuss, so we can have a
discussion.

Paul


>
> Cheers,
>
> Med
>
>
>
> *De :* Eric Rescorla <[e-mail]>
> *Envoyé :* lundi 17 novembre 2025 15:32
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> *Cc :* The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> *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 <[e-mail]> 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 <[e-mail]>
> *Envoyé :* lundi 17 novembre 2025 15:01
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> *Cc :* The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> *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 <
> [e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> ____________________________________________________________________________________________________________
>
> 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.
>
>