-- notes only; copied from www.iana.org 2018-08-07 only 2018-08-08

7.  TLS ExtensionType Values

Note

   Note:  The role of the designated expert is described in
    [RFC-ietf-tls-iana-registry-updates-05]. RFC 8447.
      The designated expert [RFC8126] ensures that the specification is
      publicly available.  An
    Internet Draft that  It is sufficient to have an Internet-Draft
      (that is posted and never published as an RFC) or a standard in document from
      another standards body, industry consortium, university site, etc.
    suffices.
      The expert may provide more in depth in-depth reviews, but their approval
      should not be taken as an endorsement of the extension.

Note

   Note:  As specified in [RFC8126], assignments made in the Private Use
      space are not generally useful for broad interoperability.  It is
      the responsibility of those making use of the Private Use range to
      ensure that no conflicts occur (within the intended scope of use).
      For widespread experiments, temporary reservations are available.

Note

   Note:  If an item is not marked as Recommended "Recommended", it does not
      necessarily mean that it is flawed; rather, it indicates that
    either the
      item either has not been through the IETF consensus process, has
      limited applicability, or is intended only for specific use cases.

Note

    The following extensions are only applicable to (D)TLS
    protocol versions prior to 1.3: trusted_ca_keys, truncated_hmac,
    user_mapping, cert_type, ec_point_formats, srp, status_request_v2,
    encrypt_then_mac, extended_master_secret, session_ticket,
    renegotiation_info, client_certificate_url, client_authz,
    server_authz, and cached_info.  These extensions are not
    applicable to (D)TLS 1.3.

8.  TLS Cipher Suites Registry

Note

   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.

Note

   Note:  Although TLS 1.3 uses the same cipher suite space as previous
      versions of TLS, TLS 1.3 cipher suites are defined differently,
      only specifying the symmetric ciphers, ciphers and hash function, and
      cannot be used for TLS 1.2.  Similarly, TLS 1.2 and lower cipher
      suite values cannot be used with TLS 1.3.

Note

   Note:  CCM_8 cipher suites are not marked as Recommended. "Recommended".  These
      cipher suites have a significantly truncated authentication tag
      that represents a security trade-off that may not be appropriate
      for general environments.

Note

   Note:  If an item is not marked as Recommended "Recommended", it does not
      necessarily mean that it is flawed; rather, it indicates that
    either the
      item either has not been through the IETF consensus process, has
      limited applicability, or is intended only for specific use cases.

Note

   Note:  The role of the designated expert is described in
    [RFC-ietf-tls-iana-registry-updates-05]. RFC 8447.
      The designated expert [RFC8126] ensures that the specification is
      publicly available.  An
    Internet Draft that  It is sufficient to have an Internet-Draft
      (that is posted and never published as an RFC) or a standard in document from
      another standards body, industry consortium, university site, etc.
    suffices.
      The expert may provide more in depth in-depth reviews, but their approval
      should not be taken as an endorsement of the cipher suite.

Note

   Note:  As specified in [RFC8126], assignments made in the Private Use
      space are not generally useful for broad interoperability.  It is
      the responsibility of those making use of the Private Use range to
      ensure that no conflicts occur (within the intended scope of use).
      For widespread experiments, temporary reservations are available.

9.  TLS Supported Groups

Note

    Renamed from "EC Named Curve Registry"

Note

   Note:  If an item is not marked as Recommended "Recommended", it does not
      necessarily mean that it is flawed; rather, it indicates that
    either the
      item either has not been through the IETF consensus process, has
      limited applicability, or is intended only for specific use cases.

Note

   Note:  The role of the designated expert is described in
    [RFC-ietf-tls-iana-registry-updates-05]. RFC 8447.
      The designated expert [RFC8126] ensures that the specification is
      publicly available.  An
    Internet Draft that  It is sufficient to have an Internet-Draft
      (that is posted and never published as an RFC) or a standard in document from
      another standards body, industry consortium, university site, etc.
    suffices.
      The expert may provide more in depth in-depth reviews, but their approval
      should not be taken as an endorsement of the supported group.

Note

   WARNING:  Cryptographic algorithms and parameters will be broken or
      weakened over time.  Blindly implementing cryptographic algorithms supported groups listed
      here is not advised.  Implementers and users need to check that
      the cryptographic algorithms listed continue to provide the
      expected level of security.

10.  TLS ClientCertificateType Identifiers

-- Currently there are zero notes on
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-2

12.  TLS Exporter Labels Registry

Note

    (1) These entries are reserved and MUST NOT be used for

   Note:  The role of the
    purpose designated expert is described in [RFC5705], in order RFC 8447.
      The designated expert [RFC8126] ensures that the specification is
      publicly available.  It is sufficient to avoid confusion
    with similar, have an Internet-Draft
      (that is posted and never published as an RFC) or a document from
      another standards body, industry consortium, university site, etc.
      The expert may provide more in-depth reviews, but distinct use their approval
      should not be taken as an endorsement of the identifier.

   Note:  As specified in [RFC5246].

Note [RFC8126], assignments made in the Private Use
      space are not generally useful for broad interoperability.  It is
      the responsibility of those making use of the Private Use range to
      ensure that no conflicts occur (within the intended scope of use).
      For widespread experiments, temporary reservations are available.

12.  TLS Exporter Labels Registry

   Note:  [RFC5705] defines keying material exporters for TLS in terms
      of the TLS PRF.  [RFC-ietf-tls-tls13-28]  [RFC8446] replaced the PRF with HKDF, thus
      requiring a new construction.  The exporter interface remains the same, however
      same; however, the value is computed differently.

Note

   Note:  The role of the designated expert is described in
    [RFC-ietf-tls-iana-registry-updates-05]. RFC 8447.
      The designated expert [RFC8126] ensures that the specification is
      publicly available.  An
    Internet Draft that  It is sufficient to have an Internet-Draft
      (that is posted and never published as an RFC) or a standard in document from
      another standards body, industry consortium, university site, etc.
    suffices.
      The expert may provide more in depth in-depth reviews, but their approval
      should not be taken as an endorsement of the exporter. exporter label.  The
      expert also verifies that the label is a string consisting of
      printable ASCII characters beginning with "EXPORTER".  IANA MUST
      also verify that one label is not a prefix of any other label.
      For example, labels "key" or "master secretary" are forbidden.

Note

   Note:  If an item is not marked as Recommended "Recommended", it does not
      necessarily mean that it is flawed; rather, it indicates that
    either the
      item either has not been through the IETF consensus process, has
      limited applicability, or is intended only for specific use cases.

14.  TLS Certificate Types

Note

   Note:  The role of the designated expert is described in
    [RFC-ietf-tls-iana-registry-updates-05]. RFC 8447.
      The designated expert [RFC8126] ensures that the specification is
      publicly available.  An
    Internet Draft that  It is sufficient to have an Internet-Draft
      (that is posted and never published as an RFC) or a standard in document from
      another standards body, industry consortium, university site, etc.
    suffices.
      The expert may provide more in depth in-depth reviews, but their approval
      should not be taken as an endorsement of the certificate type.

Note

   Note:  If an item is not marked as Recommended "Recommended", it does not
      necessarily mean that it is flawed; rather, it indicates that
    either the
      item either has not been through the IETF consensus process, has
      limited applicability, or is intended only for specific use cases.

15.  Orphaned Extensions

-- TLS ExtensionType Values registry:

Note

   Note:  The following extensions are only applicable to (D)TLS
      protocol versions prior to 1.3: trusted_ca_keys, truncated_hmac,
      user_mapping, cert_type, ec_point_formats, srp, status_request_v2,
      encrypt_then_mac, extended_master_secret, session_ticket,
      renegotiation_info, client_certificate_url, client_authz,
      server_authz, and cached_info.  These extensions are not
      applicable to (D)TLS 1.3.

16.  Orphaned Registries

--  TLS Compression Method Identifiers registry [RFC3749]:

Note

   Note:  Value 0 (NULL) is the only value in this registry applicable
      to (D)TLS protocol version 1.3 or later.

-- TLS HashAlgorithm [RFC5246]

Note

   Note:  The values in this registry are only applicable to (D)TLS
      protocol versions prior to 1.3.  (D)TLS 1.3 and later versions'
      values are registered in the TLS SignatureScheme registry.

-- and the same on in TLS SignatureAlgorithm registries [RFC5246]:

Note

   Note:  The values in this registry are only applicable to (D)TLS
      protocol versions prior to 1.3.  (D)TLS 1.3 and later versions'
      values are registered in the TLS SignatureScheme registry.

-- TLS ClientCertificateType Identifiers registry [RFC5246]:

-- Currently there are zero notes on

   Note:  The values in this registry. registry are only applicable to (D)TLS
      protocol versions prior to 1.3.

--  the TLS HashAlgorithm

Note

   WARNING:  Cryptographic algorithms and parameters will be broken or
      weakened over time.  Blindly implementing the cryptographic
      algorithms listed here is not advised.  Implementers and users
      need to check that the cryptographic algorithms listed continue to
      provide the expected level of security.

-- and the same on in TLS SignatureAlgorithm

Note

   WARNING:  Cryptographic algorithms and parameters will be broken or
      weakened over time.  Blindly implementing the cryptographic
      algorithms listed here is not advised.  Implementers and users
      need to check that the cryptographic algorithms listed continue to
      provide the expected level of security.

17.  Additional Notes

-- TLS SignatureScheme registry:

Note

   WARNING:  Cryptographic algorithms and parameters will be broken or
      weakened over time.  Blindly implementing cryptographic algorithms signature schemes listed
      here is not advised.  Implementers and users need to check that
      the cryptographic algorithms listed continue to provide the
      expected level of security.

Note

   Note:  As specified in [RFC8126], assignments made in the Private Use
      space are not generally useful for broad interoperability.  It is
      the responsibility of those making use of the Private Use range to
      ensure that no conflicts occur (within the intended scope of use).
      For widespread experiments, temporary reservations are available.

-- TLS PskKeyExchangeMode registry:

Note

   Note:  If an item is not marked as Recommended "Recommended", it does not
      necessarily mean that it is flawed; rather, it indicates that
    either the
      item either has not been through the IETF consensus process, has
      limited applicability, or is intended only for specific use cases.

Note

   Note:  The role of the designated expert is described in
    [RFC-ietf-tls-iana-registry-updates-05]. RFC 8447.
      The designated expert [RFC8126] ensures that the specification is
      publicly available.  An
    Internet Draft that  It is sufficient to have an Internet-Draft
      (that is posted and never published as an RFC) or a standard in document from
      another standards body, industry consortium, university site, etc.
    suffices.
      The expert may provide more in depth reviews, but their approval
      should not be taken as an endorsement of the key exchange mode.