RFC 8813

Clarifications for Elliptic Curve Cryptography Subject Public Key Information

📅 published August 2020, from ietf

RFC 8813 ✨ Clarifications for Elliptic Curve Cryptography Subject Public Key Information

okay bestie, let's get into this one 🎀 RFC 8813 is titled Clarifications for Elliptic Curve Cryptography Subject Public Key Information 💖 It's a Standards Track document from August 2020, published by the IETF 🌸 The authors are Tadahiko Ito (SECOM CO., LTD.) and Sean Turner (sn3rd) 🫶 It updates RFC 5480 and doesn't obsolete anything 🦋

Abstract ✨

okay so this doc is a tiny patch to RFC 5480 💅 It spells out what the keyEncipherment and dataEncipherment key usage bits are supposed to mean in certificates that use Elliptic Curve Cryptography 🔥

Status of This Memo 💜

this one is an Internet Standards Track document 🌈 It's an IETF product, which means it has IETF community consensus and got public review, and the IESG approved it for publication 👑 If you want more info on Internet Standards, check Section 2 of RFC 7841 🧚 Errata and feedback live at https://www.rfc-editor.org/info/rfc8813 🍓

the IETF Trust and the authors own the copyright (2020, all rights reserved) 💅 This doc is under BCP 78 and the Trust's Legal Provisions, which are in effect on the publication date 🦋 Read those carefully, because they spell out your rights 🙈 If you pull code components out of this doc, they have to include the Simplified BSD License text (per Section 4.e of the Trust Legal Provisions) and come without warranty 🫶

Table of Contents 🌸

  • 1. Introduction
  • 2. Terminology
  • 3. Updates to Section 3
  • 4. Security Considerations
  • 5. IANA Considerations
  • 6. Normative References
  • Authors' Addresses

1. Introduction 💖

okay so [RFC5480] defines the syntax and semantics of the Subject Public Key Information field in certificates that use Elliptic Curve Cryptography 🦋 Part of those semantics is which combos of key usage extension [RFC5280] values are allowed ✨ [RFC5480] covers 7 of the 9 values, but it says NOTHING about keyEncipherment or dataEncipherment 💀 This doc fixes that gap by updating Section 3 of [RFC5480] so that neither keyEncipherment nor dataEncipherment is set for the key agreement algorithms it defines 🔥 The new text goes at the very end of Section 3 of [RFC5480] 💅

2. Terminology 🧚

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are read as described in BCP 14 [RFC2119] [RFC8174] 🎀 but only when they're in ALL CAPS, like shown here 💜

3. Updates to Section 3 🌈

the key bit here: if a certificate has the keyUsage extension and lists id-ecPublicKey in SubjectPublicKeyInfo, then these values MUST NOT be present ✨

keyEncipherment; and
dataEncipherment.

and if the certificate has the keyUsage extension and lists id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then these values also MUST NOT be present 🔥

keyEncipherment; and
dataEncipherment.

4. Security Considerations 🙈

no cap, this doc adds NO new security considerations beyond the ones in [RFC5480] 💀 Read that one for the full picture 🫶

5. IANA Considerations 🌸

this doc has no IANA actions 🍓

6. Normative References 👑

Authors' Addresses 🎀

  • Tadahiko Ito, SECOM CO., LTD., Email: tadahiko.ito.public@gmail.com 🧚
  • Sean Turner, sn3rd, Email: sean@sn3rd.com 💅
📦 where this page comes from