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

Commentary: Fixing some typos
This document instructs IANA to make changes to a number of (D)TLS-
related IANA registries.  These changes were almost entirely
motiviated by the development of TLS1.3 I-D.ietf-tls-tls13.
The changes introduced by this document range from simple, e.g.,
adding notes, to commplex, e.g., changing a registry's registration
policy.  Intsead of listing the changes and their rationale in this,
the introducotry, section each section provides rationale for the
proposed change(s).
This document instructs IANA to make changes to a number of (D)TLS-
related IANA registries.  These changes were almost entirely
motivated by the development of TLS1.3 I-D.ietf-tls-tls13.
The changes introduced by this document range from simple, e.g.,
adding notes, to complex, e.g., changing a registry's registration
policy.  Instead of listing the changes and their rationale in this,
the introductory, section each section provides rationale for the
proposed change(s).
IANA [SHALL update/has updated] the reference for these four
registires to also refer to this document.  The remainder of this
document will use the registry names with the "TLS" prefix.
IANA [SHALL update/has updated] the reference for these four
registries to also refer to this document.  The remainder of this
document will use the registry names with the "TLS" prefix.
The instructions in this document add a recommended column to many of
the TLS registries to indicate parameters that are generally
recommended for implementations to support.  Adding a recommended
parameter to a registry or updating a parameter to recommended status
requires standards action.
Not all parameters defined in standards track documents need to be
marked as recommended.
If an item is marked as not recommended it does not necessarily mean
that it is flawed, rather, it indicates that either the item has not
been through the IETF consensus process or the item has limited
applicability to specific cases.
IANA [SHALL uppdate/has updated] the reference for this registry to
also refer to this document.
IANA [SHALL update/has updated] the reference for this registry to
also refer to this document.
The designated expert RFC8126 only ensures that the specification
is publicly available.
ClientCertificateType Identifers marked as "Yes" are those
allocated via Standards Track RFCs.  ClientCertificateTypes marked
as "No" are not.
ClientCertificateType Identifiers marked as "Yes" are those
allocated via Standards Track RFCs.  ClientCertificateTypes marked
as "No" are not.
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 prviate 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".
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".
The following extensions are only applicable to (D)TLS protocol
vesions prior to 1.3: trusted_ca_keys, truncated_hmac,
ec_point_formats, srp, status_request_v2, encrypt_then_mac,
extended_master_secret, session_ticket, and renegotiation_info.
These extensions are not applicable to (D)TLS 1.3.
The following extensions are only applicable to (D)TLS protocol
versions prior to 1.3: trusted_ca_keys, truncated_hmac,
ec_point_formats, srp, status_request_v2, encrypt_then_mac,
extended_master_secret, session_ticket, and renegotiation_info.
These extensions are not applicable to (D)TLS 1.3.
WARNING: Cryptographic algorithms and parameters will be broken or
weakened over time.  Blindly implementing cipher suites listed here
is not advised.  Implementers and users need to check that the
cryptographic algorithms listed continue to provide the expected
level of security.
The authors are fairly certain that there are no security
considerations for this document.
The change to Specification Required from IETF Review lowers the
amount of review provided by the WG for cipher suites and supported
groups.  This change reflects reality in that the WG essentially
provided no cryptographic review of the cipher suites or supported
groups.  This was especially true of national cipher suites.