RFC 9847
IANA Registry Updates for TLS and DTLS
Title Block 🎀
RFC: 9847, IANA Registry Updates for TLS and DTLS Stream: Internet Engineering Task Force (IETF) Category: Standards Track (ISSN 2070-1721) Date: December 2025 Authors: J. Salowey (CyberArk) and S. Turner (sn3rd) 👑 Updates: RFC 8447 🔁
Okay bestie, this is the main thing to know. This RFC is a follow-up to RFC 8447 and it updates that one. It's a Standards Track doc, so it's official and implementers are supposed to follow it. 🫶
Abstract ✨
So this doc is a glow-up for the TLS and DTLS IANA registries 💅. RFC 8447 made some changes to them, and this one comes in to update those changes. It adds a new value, "D" for discouraged, to the "Recommended" column of the selected TLS registries. It also adds a "Comment" column to every active registry that doesn't already have one. Last but not least, it updates the registration request instructions. 🌸
This document updates RFC 8447.
Status of This Memo 🦋
This is an Internet Standards Track document.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 📚.
For the current status of this document, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc9847 ✨.
Copyright Notice 💜
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. 🧚
Table of Contents 🍓
1. Introduction
2. Terminology
3. Updating "Recommended" Column's Values
3.1. Recommended Note
4. TLS ExtensionType Values Registry
5. TLS Cipher Suites Registry
6. TLS Supported Groups Registry
7. TLS Exporter Labels Registry
8. TLS Certificate Types Registry
9. TLS HashAlgorithm Registry
10. TLS SignatureAlgorithm Registry
11. TLS ClientCertificateType Identifiers Registry
12. TLS PskKeyExchangeMode Registry
13. TLS SignatureScheme Registry
14. Adding "Comment" Column
15. Expert Review of Current and Potential IETF and IRTF Documents
16. Registration Requests
17. Security Considerations
18. IANA Considerations
19. Normative References
Authors' Addresses1. Introduction 🌷
This document tells IANA to make changes to a bunch of registries related to Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 🔥. These changes update the ones made in [RFC8447].
This specification adds a new value, "D" for discouraged, to the "Recommended" column of the selected TLS registries. It also adds a "Comment" column to all active registries that don't already have one 💅.
It also updates the registration request instructions. 🫶
2. Terminology 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🎀
3. Updating "Recommended" Column's Values 💖
This is the main event ✨. The instructions here update the "Recommended" column, which RFC 8447 originally added, so it gets a third value: "D", meaning the item is discouraged. The permitted values of the "Recommended" column are:
Y: The IETF has consensus that the item is RECOMMENDED. That only means the mechanism is fit for the purpose it was defined for. You still have to read the mechanism's docs carefully to understand where it applies. The IETF could recommend mechanisms with limited applicability, but it will also write applicability statements that explain any limits or constraints on using them 🧐.N: The IETF hasn't evaluated the item and hasn't said anything about whether the mechanism is suitable. That doesn't automatically mean it's broken, just that there's no consensus yet 🤷♀️. The IETF might have consensus to leave an item markedNbecause it has limited applicability or usage constraints.D: The item is discouraged 🚫. This marking can flag mechanisms that might cause problems if someone uses them, like a weak cryptographic algorithm or a mechanism that could cause interoperability issues when deployed. When you mark a registry entry asD, either the "Reference" or the "Comment" column MUST include enough information to work out why the marking was applied. Implementers and users SHOULD check the linked references for the item to figure out the conditions where it SHOULD NOT or MUST NOT be used 😭.
Setting a value to Y or D, or moving a value away from Y or D in the "Recommended" column, requires IETF Standards Action with Expert Review or IESG Approval [RFC8126]. Not every item defined in a Standards Track RFC has to be set to Y or D. Any item that isn't otherwise specified is set to N. The column is blank for values that are unassigned or reserved, unless they've been specifically set 🌈.
3.1. Recommended Note 🦢
Existing registries already have a note explaining the "Recommended" column. For the registries covered in the next sections, that note gets updated with a sentence describing the D value, like this:
| Note: If the "Recommended" column is set to "N", it does not
| necessarily mean that it is flawed; rather, it indicates that the
| item has not been through the IETF consensus process, has limited
| applicability, or is intended only for specific use cases. If the
| "Recommended" column is set to "D", the item is discouraged and
| SHOULD NOT or MUST NOT be used, depending upon the situation;
| consult the item's references for clarity.Part 1 of 4 is done 💜. Section 4 and everything after it comes in part 2, so stay tuned 🔥✨.
5. TLS Cipher Suites Registry ✨
okay so this section is about cipher suites that are discouraged for general use, and they get marked with a "D" 💀. Let's go category by category.
NULL encryption cipher suites don't give you the confidentiality TLS is supposed to give you 😭. Lots of protocols and apps are built on the assumption that nobody can read the traffic, so these cipher suites MUST NOT be used in those cases. Not even a little bit, bestie 🙅♀️.
EXPORT-marked cipher suites use weak ciphers, and they were deprecated in TLS 1.1 [RFC4346] 🥀.
Then there are the anon ones. They don't do any authentication at all, so they're open to on-path attacks, and they were also deprecated in TLS 1.1 [RFC4346]. Very not it 🙈.
RC4 is a weak cipher, and it's deprecated in [RFC7465] 🧃.
DES and IDEA aren't considered secure for general use, and they were deprecated in [RFC5469]. MD5 and SHA-1 aren't secure for general use either, and they were deprecated in [RFC9155] 💅.
Now for the registry glow-up 💖. To reflect the changes to the "Recommended" column, IANA updated the "TLS Cipher Suites" registry like this:
- Adjusted the registration procedure for setting the "Recommended" column:
Setting a value to "Y" or "D" or transitioning the value from "Y" or "D" in the "Recommended" column requires IETF Standards Action with Expert Review or IESG Approval [RFC8126].
- Added a reference to this document under the reference heading ✨.
- Updated the "Recommended" column with the changes in Table 2 below. Everything else keeps its existing "Y" and "N" values. IANA added a reference to this document for those entries. This document doesn't touch the "DTLS-OK" column at all 🫶.
- Updated the note on the "Recommended" column with the text in Section 3.1 🎀.
+===========+=====================================+=============+
| Value | Description | Recommended |
+===========+=====================================+=============+
| 0x00,0x1E | TLS_KRB5_WITH_DES_CBC_SHA | D |
+-----------+-------------------------------------+-------------+
| 0x00,0x20 | TLS_KRB5_WITH_RC4_128_SHA | D |
+-----------+-------------------------------------+-------------+
| 0x00,0x21 | TLS_KRB5_WITH_IDEA_CBC_SHA | D |
+-----------+-------------------------------------+-------------+
| 0x00,0x22 | TLS_KRB5_WITH_DES_CBC_MD5 | D |
+-----------+-------------------------------------+-------------+
| 0x00,0x24 | TLS_KRB5_WITH_RC4_128_MD5 | D |
+-----------+-------------------------------------+-------------+
| 0x00,0x25 | TLS_KRB5_WITH_IDEA_CBC_MD5 | D |
+-----------+-------------------------------------+-------------+
| 0x00,0x26 | TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA | D |
+-----------+-------------------------------------+-------------+
| 0x00,0x27 | TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA | D |
+-----------+-------------------------------------+-------------+
| 0x00,0x28 | TLS_KRB5_EXPORT_WITH_RC4_40_SHA | D |
+-----------+-------------------------------------+-------------+
| 0x00,0x29 | TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 | D |
+-----------+-------------------------------------+-------------+
| 0x00,0x2A | TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 | D |
+-----------+-------------------------------------+-------------+
| 0x00,0x2B | TLS_KRB5_EXPORT_WITH_RC4_40_MD5 | D |
+-----------+-------------------------------------+-------------+
| 0x00,0x2C | TLS_PSK_WITH_NULL_SHA | D |
+-----------+-------------------------------------+-------------+
| 0x00,0x8A | TLS_PSK_WITH_RC4_128_SHA | D |
+-----------+-------------------------------------+-------------+
| 0x00,0xB0 | TLS_PSK_WITH_NULL_SHA256 | D |
+-----------+-------------------------------------+-------------+
| 0x00,0xB1 | TLS_PSK_WITH_NULL_SHA384 | D |
+-----------+-------------------------------------+-------------+
| 0xC0,0x06 | TLS_ECDHE_ECDSA_WITH_NULL_SHA | D |
+-----------+-------------------------------------+-------------+
| 0xC0,0x07 | TLS_ECDHE_ECDSA_WITH_RC4_128_SHA | D |
+-----------+-------------------------------------+-------------+
| 0xC0,0x10 | TLS_ECDHE_RSA_WITH_NULL_SHA | D |
+-----------+-------------------------------------+-------------+
| 0xC0,0x11 | TLS_ECDHE_RSA_WITH_RC4_128_SHA | D |
+-----------+-------------------------------------+-------------+
| 0xC0,0x33 | TLS_ECDHE_PSK_WITH_RC4_128_SHA | D |
+-----------+-------------------------------------+-------------+
| 0xC0,0x39 | TLS_ECDHE_PSK_WITH_NULL_SHA | D |
+-----------+-------------------------------------+-------------+
| 0xC0,0x3A | TLS_ECDHE_PSK_WITH_NULL_SHA256 | D |
+-----------+-------------------------------------+-------------+
| 0xC0,0x3B | TLS_ECDHE_PSK_WITH_NULL_SHA384 | D |
+-----------+-------------------------------------+-------------+
| 0xC0,0xB4 | TLS_SHA256_SHA256 | D |
+-----------+-------------------------------------+-------------+
| 0xC0,0xB5 | TLS_SHA384_SHA384 | D |
+-----------+-------------------------------------+-------------+Table 2
6. TLS Supported Groups Registry 🌈
Same vibe here! To reflect the "Recommended" column changes, IANA updated the "TLS Supported Groups" registry like so:
- Updated the registration policy to include:
Setting a value to "Y" or "D" or transitioning the value from "Y" or "D" in the "Recommended" column requires IETF Standards Action with Expert Review or IESG Approval [RFC8126].
- Added a reference to this document under the reference heading.
- Updated the "Recommended" column with the changes in Table 3 below. Everything else keeps its existing "Y" and "N" values. IANA added a reference to this document for those entries.
+=======+=============+=============+
| Value | Description | Recommended |
+=======+=============+=============+
| 1 | sect163k1 | D |
+-------+-------------+-------------+
| 2 | sect163r1 | D |
+-------+-------------+-------------+
| 3 | sect163r2 | D |
+-------+-------------+-------------+
| 4 | sect193r1 | D |
+-------+-------------+-------------+
| 5 | sect193r2 | D |
+-------+-------------+-------------+
| 6 | sect233k1 | D |
+-------+-------------+-------------+
| 7 | sect233r1 | D |
+-------+-------------+-------------+
| 8 | sect239k1 | D |
+-------+-------------+-------------+
| 15 | secp160k1 | D |
+-------+-------------+-------------+
| 16 | secp160r1 | D |
+-------+-------------+-------------+
| 17 | secp160r2 | D |
+-------+-------------+-------------+
| 18 | secp192k1 | D |
+-------+-------------+-------------+
| 19 | secp192r1 | D |
+-------+-------------+-------------+
| 20 | secp224k1 | D |
+-------+-------------+-------------+
| 21 | secp224r1 | D |
+-------+-------------+-------------+Table 3
- Updated the note on the "Recommended" column with the text in Section 3.1.
- Removed the "Elliptic curve groups" note from the registration procedures table 🗑️.
- For each entry above, added the following link to the "Comment" column:
https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-rfc8447bis-00
7. TLS Exporter Labels Registry 🦋
This document updates the registration procedure for the "TLS Exporter Labels" registry and also updates the "Recommended" column allocation. IANA updated the "TLS Exporter Labels" registry like this:
- Changed the registration procedure from Specification Required to Expert Review, and updated it to include:
Setting a value to "Y" or "D" or transitioning the value from "Y" or "D" in the "Recommended" column requires IETF Standards Action with Expert Review or IESG Approval [RFC8126].
- Added a reference to this document under the reference heading.
- Entries kept their existing "Recommended" column "Y" and "N" values.
- Updated the note on the "Recommended" column with the text in Section 3.1.
- Updated the note on the role of the expert reviewer as follows 🧐:
Note: The role of the designated expert is described in Section 17
of [RFC8447]. Even though this registry does not require a
specification, the designated expert [RFC8126] will strongly
encourage registrants to provide a link to a publicly available
specification. An Internet-Draft (that is posted and never
published as an RFC) or a document from another standards body,
industry consortium, university site, etc. is suitable for these
purposes. The expert may provide more in-depth reviews, but their
approval should not be taken as an endorsement of the 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.- Renamed the "Note" column to "Comment" ✨.
8. TLS Certificate Types Registry 🎀
Last one in this part! IANA updated the "TLS Certificate Types" registry to reflect the "Recommended" column changes:
- Adjusted the registration procedure for setting the "Recommended" column:
Setting a value to "Y" or "D" or transitioning the value from "Y" or "D" in the "Recommended" column requires IETF Standards Action with Expert Review or IESG Approval [RFC8126].
- Added a reference to this document under the reference heading.
- Entries kept their existing "Recommended" column "Y" and "N" values.
- Updated the note on the "Recommended" column with the text in Section 3.1.
9. TLS HashAlgorithm Registry ✨
Okay so TLS 1.0 and TLS 1.1 got deprecated [RFC8996] 💀, and TLS 1.2 is gonna be around for a while 🫶. To reflect the changes in the "Recommended" column, IANA updated the "TLS HashAlgorithm" registry like this:
- Updated the registration procedure to include:
Setting a value to "Y" or "D" or transitioning the value from "Y" or "D" in the "Recommended" column requires IETF Standards Action with Expert Review or IESG Approval [RFC8126].
- Added a reference to this document under the reference heading.
- Updated the "TLS HashAlgorithm" registry to add a "Recommended" column, like so:
+=======+=============+=============+
| Value | Description | Recommended |
+=======+=============+=============+
| 0 | none | Y |
+-------+-------------+-------------+
| 1 | md5 | D |
+-------+-------------+-------------+
| 2 | sha1 | D |
+-------+-------------+-------------+
| 3 | sha224 | D |
+-------+-------------+-------------+
| 4 | sha256 | Y |
+-------+-------------+-------------+
| 5 | sha384 | Y |
+-------+-------------+-------------+
| 6 | sha512 | Y |
+-------+-------------+-------------+
| 8 | Intrinsic | Y |
+-------+-------------+-------------+Table 4
- Added a note on the "Recommended" column with text in Section 3.1.
10. TLS SignatureAlgorithm Registry 🦋
TLS 1.0 and TLS 1.1 were deprecated [RFC8996], TLS 1.2 will be in use for some time 🌸. So to reflect the "Recommended" column changes, IANA updated the "TLS SignatureAlgorithm" registry as follows:
- Updated the registration procedure to include:
Setting a value to "Y" or "D" or transitioning the value from "Y" or "D" in the "Recommended" column requires IETF Standards Action with Expert Review or IESG Approval [RFC8126].
- Added a reference to this document under the reference heading.
- Updated the "TLS SignatureAlgorithm" registry to add a "Recommended" column, like so:
+=======+===================+=============+
| Value | Description | Recommended |
+=======+===================+=============+
| 0 | anonymous | N |
+-------+-------------------+-------------+
| 1 | rsa | Y |
+-------+-------------------+-------------+
| 2 | dsa | N |
+-------+-------------------+-------------+
| 3 | ecdsa | Y |
+-------+-------------------+-------------+
| 7 | ed25519 | Y |
+-------+-------------------+-------------+
| 8 | ed448 | Y |
+-------+-------------------+-------------+
| 64 | gostr34102012_256 | N |
+-------+-------------------+-------------+
| 65 | gostr34102012_512 | N |
+-------+-------------------+-------------+Table 5
- Added a note on the "Recommended" column with text in Section 3.1.
11. TLS ClientCertificateType Identifiers Registry 💅
TLS 1.0 and TLS 1.1 were deprecated [RFC8996], TLS 1.2 will be in use for some time 🎀. Same energy as before: to reflect the "Recommended" column changes, IANA updated the "TLS ClientCertificateType Identifiers" registry as follows:
- Updated the registration procedure to include:
Setting a value to "Y" or "D" or transitioning the value from "Y" or "D" in the "Recommended" column requires IETF Standards Action with Expert Review or IESG Approval [RFC8126].
- Added a reference to this document under the reference heading.
- Updated the "TLS ClientCertificateType Identifiers" registry to add a "Recommended" column, like so:
+=======+===========================+=============+
| Value | Description | Recommended |
+=======+===========================+=============+
| 1 | rsa_sign | Y |
+-------+---------------------------+-------------+
| 2 | dss_sign | N |
+-------+---------------------------+-------------+
| 3 | rsa_fixed_dh | N |
+-------+---------------------------+-------------+
| 4 | dss_fixed_dh | N |
+-------+---------------------------+-------------+
| 5 | rsa_ephemeral_dh_RESERVED | D |
+-------+---------------------------+-------------+
| 6 | dss_ephemeral_dh_RESERVED | D |
+-------+---------------------------+-------------+
| 20 | fortezza_dms_RESERVED | D |
+-------+---------------------------+-------------+
| 64 | ecdsa_sign | Y |
+-------+---------------------------+-------------+
| 65 | rsa_fixed_ecdh | N |
+-------+---------------------------+-------------+
| 66 | ecdsa_fixed_ecdh | N |
+-------+---------------------------+-------------+
| 67 | gost_sign256 | N |
+-------+---------------------------+-------------+
| 68 | gost_sign512 | N |
+-------+---------------------------+-------------+Table 6
- Added a note on the "Recommended" column with text in Section 3.1.
12. TLS PskKeyExchangeMode Registry 🌈
To reflect the changes in the "Recommended" column, IANA updated the "TLS PskKeyExchangeMode" registry as follows:
- Updated the registration procedure to include:
Setting a value to "Y" or "D" or transitioning the value from "Y" or "D" in the "Recommended" column requires IETF Standards Action with Expert Review or IESG Approval [RFC8126].
- Added a reference to this document under the reference heading.
- Entries kept their existing "Recommended" column "Y" and "N" entries.
- Updated note on the "Recommended" column with text in Section 3.1.
13. TLS SignatureScheme Registry ⭐
To reflect the changes in the "Recommended" column, IANA updated the "TLS SignatureScheme" registry as follows:
- Updated the registration procedure to include:
Setting a value to "Y" or "D" or transitioning the value from "Y" or "D" in the "Recommended" column requires IETF Standards Action with Expert Review or IESG Approval [RFC8126].
- Added a reference to this document under the reference heading.
- Entries kept their existing "Recommended" column "Y" and "N" entries.
- Updated note on the "Recommended" column with text in Section 3.1.
14. Adding "Comment" Column 🧚
IANA added a "Comment" column to the following registries, and honestly the list is giving main character energy 👑:
- TLS ExtensionType Values
- TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs
- TLS CachedInformationType Values
- TLS Certificate Compression Algorithm IDs
- TLS ClientCertificateType Identifiers
- TLS Cipher Suites
- TLS ContentType
- TLS EC Point Formats
- TLS EC Curve Types
- TLS Supplemental Data Formats (SupplementalDataType)
- TLS UserMappingType Values
- TLS SignatureAlgorithm
- TLS HashAlgorithm
- TLS Authorization Data Formats
- TLS Heartbeat Message Types
- TLS Heartbeat Modes
- TLS SignatureScheme
- TLS PskKeyExchangeMode
- TLS KDF Identifiers
- TLS SSLKEYLOGFILE Labels
This list covers every registry that doesn't already have a "Comment" or "Note" column, or that wasn't orphaned by TLS 1.3 🙈.
15. Expert Review of Current and Potential IETF and IRTF Documents 🔥
Okay, so the point of the Specification Required choice for TLS codepoints is to make registration easy for codepoints tied to protocols and algorithms that nobody is actively building inside the IETF or IRTF 🌸. When TLS-based tech is being developed inside the IETF or IRTF, it should be done in coordination with the TLS WG so it gets proper review 🫶. That's why, unless the TLS WG Chairs say otherwise over email, designated experts should decline codepoint registrations for documents already adopted, or being proposed for adoption, by IETF working groups or IRTF research groups 💅.
16. Registration Requests 💌
Registration requests MUST be submitted in one of two ways:
- By sending email to
iana@iana.org. This email SHOULD use an appropriate subject (e.g., "Request to register value in TLS bar registry"). - Using the online form at
https://www.iana.org/form/protocol-assignment.
Specification Required [RFC8126] registry requests get registered after a three-week review period, based on the advice of one or more designated experts. However, so values can be allocated before publication, the designated experts may approve a registration once they're satisfied that the specification will be published 🦋.
17. Security Considerations 💀
Heads up, bestie, this part is serious 😭.
Recommended algorithms are regarded as secure for general use at the time of registration. BUT cryptographic algorithms and parameters will get broken or weakened over time 💔. It's 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 🔐.
Designated experts ensure the specification is publicly available. They may provide more in-depth reviews. Their review should not be taken as an endorsement of the cipher suite, extension, supported group, etc. ✨
18. IANA Considerations 🌈
This document is entirely about changes to TLS-related IANA registries 🎀.
19. Normative References ✨
okay bestie, this is the reading list 📚 every doc that this RFC leans on for its bones, with the full details so you can go find them yourself 🫶
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. 💜 - [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006,
<https://www.rfc-editor.org/info/rfc4346>. 🌸 - [RFC5469] Eronen, P., Ed., "DES and IDEA Cipher Suites for Transport Layer Security (TLS)", RFC 5469, DOI 10.17487/RFC5469, February 2009,
<https://www.rfc-editor.org/info/rfc5469>. 🦋 - [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 10.17487/RFC7465, February 2015,
<https://www.rfc-editor.org/info/rfc7465>. 🍓 - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. 🎀 - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>. 💅 - [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>. 🧚 - [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>. 👑 - [RFC9155] Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2", RFC 9155, DOI 10.17487/RFC9155, December 2021,
<https://www.rfc-editor.org/info/rfc9155>. ⭐
Authors' Addresses 🦋
Joe Salowey CyberArk Email: joe@salowey.net
Sean Turner sn3rd Email: sean@sn3rd.com
and that's the whole spec, bestie!! 🌈💖 the authors who made it, the references it stands on, all the way to the last email 😭🫶
📦 where this page comes from
- ietf: rfc9847 2025-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms