Draft: draft-ietf-tls-iana-registry-updates

Commentary: Looks Good
Add a "Recommended" column with the contents as listed below.
This table has been generated by marking Standards Track RFCs as
"Yes" and all others as "No".  Future extensions MUST define the
value of the Recommended column.  A Standards Track document
RFC8126 is REQUIRED to register an extension with the value "Yes".
IESG action is REQUIRED for a Yes->No transition.
Add a "Recommended" column with the contents as listed below.
This table has been generated by marking Standards Track RFCs as
"Yes" and all others as "No".  Future extensions MUST define the
value of the Recommended column.  In order to register an
extension with the value "Yes", a Standards Track document RFC8126
is REQUIRED.  IESG action is REQUIRED for a Yes->No transition.
Add a "Recommended" column to the TLS Cipher Suite registry.  The
cipher suites that follow in the two tables are marked as "Yes".
All other cipher suites are marked as "No".  Future cipher suites
MUST define the value of the Recommended column.  A Standards
Track document RFC8126 is REQUIRED to register a cipher suite with
the value "Yes".  IESG action is REQUIRED for a Yes->No
transition.
Add a "Recommended" column to the TLS Cipher Suite registry.  The
cipher suites that follow in the two tables are marked as "Yes".
All other cipher suites are marked as "No".  Future cipher suites
MUST define the value of the Recommended column.  In order to
register an extension with the value "Yes, a Standards Track
document RFC8126 is REQUIRED.  IESG action is REQUIRED for a
Yes->No transition.
Similar to cipher suites, supported groups have proliferated over
time and some use the registry to measure implementations.
Therefore, IANA [SHALL add/has added] a "Recommended" column with a
"Yes" for secp256r1, secp384r1, x25519, and x448 while all others are
"No".  These "Yes" groups are taken from Standards Track RFCs.  Not
all groups from I-D.ietf-tls-rfc4492bis, which is standards track,
are marked as "Yes"; these groups apply to TLS 1.3 I-D.ietf-tls-tls13
and previous versions of TLS.  Future supported groups MUST define
the value of this column.  A Standards Track document RFC8126 is
REQUIRED to register an entry with the value "Yes".  IESG action is
REQUIRED for a Yes->No transition.
Similar to cipher suites, supported groups have proliferated over
time and some use the registry to measure implementations.
Therefore, IANA [SHALL add/has added] a "Recommended" column with a
"Yes" for secp256r1, secp384r1, x25519, and x448 while all others are
"No".  These "Yes" groups are taken from Standards Track RFCs.  Not
all groups from I-D.ietf-tls-rfc4492bis, which is standards track,
are marked as "Yes"; these groups apply to TLS 1.3 I-D.ietf-tls-tls13
and previous versions of TLS.  Future supported groups MUST define
the value of this column.  In order to register an extension with the
value "Yes", a Standards Track document RFC8126 is REQUIRED.  IESG
action is REQUIRED for a Yes->No transition.
A "Recommended" column to the TLS Exporter Label registry.  The
table that follows has been generated by marking Standards Track
RFCs as "Yes" and all others as "No".  Future exporters MUST
define the value of this column.  A Standards Track document
RFC8126 is REQUIRED to register an extension with the value "Yes".
IESG action is REQUIRED for a Yes->No transition.
A "Recommended" column to the TLS Exporter Label registry.  The
table that follows has been generated by marking Standards Track
RFCs as "Yes" and all others as "No".  Future exporters MUST
define the value of this column.  In order to register an
extension with the value "Yes", a Standards Track document RFC8126
is REQUIRED.  IESG action is REQUIRED for a Yes->No transition.
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".  A Standards Track document RFC8126 is
required to register a certificate type with the value "Yes".  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".  IESG action is REQUIRED for a Yes->No transition.
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.
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".  IESG action is REQUIRED for a Yes->No
transition.
Specification Required RFC8126 registry requests are registered after
a three-week review period on the (tbd but maybe tls-reg-
review@ietf.org) mailing list, on the advice of one or more
Designated Experts.  However, to allow for the allocation of values
prior to publication, the Designated Experts may approve registration
once they are satisfied that such a specification will be published.
Specification Required RFC8126 registry requests are registered after
a three-week review period on the tls-reg-review@ietf.org mailing
list, on the advice of one or more Designated Experts.  However, to
allow for the allocation of values prior to publication, the
Designated Experts may approve registration once they are satisfied
that such a specification will be published.
Recommended algorithms regarded as secure for general use at the time
of registration, however, cryptographic algorithms and parameters
will be broken or weakened over time.  It is possible that the
recommended status in the registry lags behind the most recent
advances in cryptanalysis.  Implementers and users need to check that
the cryptographic algorithms listed continue to provide the expected
level of security.
Recommended algorithms are regarded as secure for general use at the
time of registration, however, cryptographic algorithms and
parameters will be broken or weakened over time.  It is possible that
the recommended status in the registry lags behind the most recent
advances in cryptanalysis.  Implementers and users need to check that
the cryptographic algorithms listed continue to provide the expected
level of security.