[TLS] Alexey Melnikov's No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT)

[Alexey Melnikov <[e-mail]>]

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.