-- notes only; copied from www.iana.org 2018-08-07 7. TLS ExtensionType Values Note The role of the designated expert is described in [RFC-ietf-tls-iana-registry-updates-05]. The designated expert [RFC8126] ensures that the specification is publicly available. An Internet Draft that is posted and never published or a standard in 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 extension. 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 If an item is not marked as 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, 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 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 CCM_8 cipher suites are not marked as 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 If an item is not marked as 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, has limited applicability, or is intended only for specific use cases. Note The role of the designated expert is described in [RFC-ietf-tls-iana-registry-updates-05]. The designated expert [RFC8126] ensures that the specification is publicly available. An Internet Draft that is posted and never published or a standard in 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 cipher suite. 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 If an item is not marked as 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, has limited applicability, or is intended only for specific use cases. Note The role of the designated expert is described in [RFC-ietf-tls-iana-registry-updates-05]. The designated expert [RFC8126] ensures that the specification is publicly available. An Internet Draft that is posted and never published or a standard in 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 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 and MUST NOT be used for the purpose described in [RFC5705], in order to avoid confusion with similar, but distinct use in [RFC5246]. Note [RFC5705] defines keying material exporters for TLS in terms of the TLS PRF. [RFC-ietf-tls-tls13-28] replaced the PRF with HKDF, thus requiring a new construction. The exporter interface remains the same, however the value is computed differently. Note The role of the designated expert is described in [RFC-ietf-tls-iana-registry-updates-05]. The designated expert [RFC8126] ensures that the specification is publicly available. An Internet Draft that is posted and never published or a standard in 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 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 If an item is not marked as 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, has limited applicability, or is intended only for specific use cases. 14. TLS Certificate Types Note The role of the designated expert is described in [RFC-ietf-tls-iana-registry-updates-05]. The designated expert [RFC8126] ensures that the specification is publicly available. An Internet Draft that is posted and never published or a standard in 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 certificate type. Note If an item is not marked as 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, has limited applicability, or is intended only for specific use cases. 15. Orphaned Extensions -- TLS ExtensionType Values registry: 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 Value 0 (NULL) is the only value in this registry applicable to (D)TLS protocol version 1.3 or later. -- TLS HashAlgorithm [RFC5246] 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 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 this registry. -- 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 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 If an item is not marked as 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, has limited applicability, or is intended only for specific use cases. Note The role of the designated expert is described in [RFC-ietf-tls-iana-registry-updates-05]. The designated expert [RFC8126] ensures that the specification is publicly available. An Internet Draft that is posted and never published or a standard in 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.