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. Please find some points for DISCUSSion: # PS for a non-recommended scheme? CURRENT: The "Recommended" column should be set to "N" I understand this is addressing a specific deployment case. I also understand that some interoperability is needed here to follow the guidance in the document. Still, this is about non-recommended scheme. Any reason why are we publishing this as PS? # draft-ietf-tls-rfc8447bis says the following: N: Indicates that the item has not been evaluated by the IETF and that the IETF has made no statement about the suitability of the associated mechanism. This does not necessarily mean that the mechanism is flawed, only that no consensus exists. The IETF might have consensus to leave an items marked as "N" on the basis of its having limited applicability or usage constraints. D: Indicates that the item is discouraged. This marking could be used to identify mechanisms that might result in problems if they are used, such as a weak cryptographic algorithm or a mechanism that might cause interoperability problems in deployment. When marking a registry entry as “D”, either the References or the Comments Column MUST include sufficient information to determine why the marking has been applied. Implementers and users SHOULD consult the linked references associated with the item to determine the conditions under which the item SHOULD NOT or MUST NOT be used. Given there was a design choice to remove support in 8446/8446 bis and reading of the above definitions, it seems that we are more on the D side than the N side. # Clear applicability Scope I think that a clear/dedicated section to LOUDLY describe the applicability scope is needed here. # Update RFC8446/RFC8446bis The provisions in this draft relax what used to be disallowed in 8446/8446bis. This reads like an update. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # FIPS 186-4 ## Please add a reference ## s/with FIPS 186-4/with US FIPS 186-4 # Default CURRENT: TLS implementations SHOULD disable these code points by default. See Section 4. ## Wouldn’t MUST be appropriate here? ## Which part of Section 4 is relevant to this point? I failed to see the logic for that reference. # 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 _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
