Alexey Melnikov has entered the following ballot position for draft-ietf-tls-iana-registry-updates-04: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support the idea behind this document. I have a few minor issues which I would like to discuss before recommending its approval: 1) In several places: "IESG action is REQUIRED for a Yes->No transition." Firstly, this should be "IESG Approval", not "IESG action" (according to RFC 8126). Secondly, are you saying that this is the ONLY way to transition from Yes to No? Surely, Standards Action should also be allowed in case there is no rush? Besides IESG is likely to prefer a document explaining the transition anyway. 2) In Section 15: 15. TLS Certificate Types Experience has shown that the IETF Consensus registry policy for TLS Certificate Types is too strict. Based on WG consensus, the decision was taken to change registration policy to Specification Required [RFC8126] while reserving a small part of the code space for experimental and private use. Therefore, IANA [SHALL add/has added] a "Recommended" column to the registry. X.509 and Raw Public Key are "Yes". All others are "No". In order to register an extension with the value "Yes", a Standards Track document [RFC8126] is REQUIRED. The above sentence. Future Certificate Types MUST define the value of this column. A Standards Track document [RFC8126] is REQUIRED to register an entry with the value "Yes". And this is just repeating the above sentence in a different way. IESG action is REQUIRED for a Yes->No transition. 3) In Section 17: Despite the fact that the HashAlgorithm and SignatureAlgorithm registries are orphaned, it is still import to warn implementers of import --> important pre-TLS1.3 implementations about the dangers of blinding implementing blinding --> blindly cryptographic algorithms. And later in the same section: WARNING: Cryptographic algorithms and parameters will be broken or weakened over time. Blindly implementing cipher suites listed cipher suites --> hash functions/signatures? here is not advised. Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
