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

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's 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.

   Note:  token_binding is omitted from the above table; [TOKBIND]
      specifies the "Recommended" column for this extension.

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, 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's 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's 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
      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

   Note:  The role of the designated expert is described in RFC 8447.
      The designated expert [RFC8126] ensures that the specification is
      publicly available.  It's sufficient to have an Internet-Draft
      (that is posted and MUST NOT 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 their approval
      should not be used for taken as an endorsement of the
    purpose described identifier.

   Note:  As specified in [RFC5705], [RFC8126], assignments made in order 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 avoid confusion
    with similar, but distinct
      ensure that no conflicts occur (within the intended scope of use).
      For widespread experiments, temporary reservations are available.

   Note:  ClientCertificateType Identifiers marked as "Y" are those
      allocated via Standards Track RFCs.  ClientCertificateTypes marked
      as "N" are not.

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

Note
      cases.

12.  TLS Exporter Label 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's 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.  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's 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 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 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 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
      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's 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.