RFC 7093

RFC 7093: Additional Methods for Generating Key Identifiers Values 🔑✨

okay bestie, here's the vibe check on this one 💅 It's an Independent Submission (so it came in from outside the usual IETF working groups), and it's Informational, so it's not a Standards Track thing. Published December 2013, ISSN 2070-1721. The authors are:

• Sean Turner (IECA) 🎀
• Stephen Kent (BBN) 🌸
• James Manger (Telstra) 🦋

The title block doesn't list anything it obsoletes or updates, so this one is just a standalone add-on to RFC 5280 🌈

Abstract ✨

okay so the whole point is giving you more example methods for generating Key Identifier values 🔑 These are for the AKI (Authority Key Identifier) and SKI (Subject Key Identifier) certificate extensions. main character energy, fr fr 💖

---

Status of This Memo 📝

not gonna lie, this part is a little boring, but it matters 🙈 This document is not an Internet Standards Track spec. It's published just for info 💜

It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor picked to publish it at their discretion, and they make zero promises about whether it's good for implementing or deploying 💀 Docs the RFC Editor approves aren't candidates for any level of Internet Standard, see Section 2 of RFC 5741.

For the current status, errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7093 🧚

Copyright Notice 🌈

Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) as they were on the publication date. Please read these carefully, bestie, because they spell out your rights and restrictions for this doc 🫶

---

1. Introduction 🦋

okay so [RFC5280] defines the AKI and SKI certificate extensions 📜 It also describes two example mechanisms for making AKI and SKI values: a 160-bit SHA-1 (Secure Hash Algorithm) hash of the public key, and a four-bit type field with the value 0100 followed by the least significant 60 bits of the SHA-1 hash. Both of those were designed to not be critical to security 🔐

This document adds three more mechanisms for making Key Identifier values using SHA-256, SHA-384, and SHA-512 [SHS]. They're similar to the examples in [RFC5280]. It also adds one based on hashing the certificate's Subject Public Key Info field ✨

2. Additional Methods for Generating Key Identifiers 🔑

[RFC5280] has two examples for making key identifiers from public keys. Here are four more, no cap 💅

1. The keyIdentifier is the leftmost 160 bits of the SHA-256 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits).
2. The keyIdentifier is the leftmost 160 bits of the SHA-384 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits).
3. The keyIdentifier is the leftmost 160 bits of the SHA-512 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits).
4. The keyIdentifier is the hash of the DER encoding of the SubjectPublicKeyInfo value.

3. Examples 🧁

okay now the fun part 🎀 Keys and SKIs are shown in hexadecimal, two hex digits per byte.

We're starting with this DER-encoded SubjectPublicKeyInfo value holding a P-256 ECDSA (Elliptic Curve Digital Signature Algorithm) key 🌸

  30 59
     30 13
        06 07 2A8648CE3D0201    -- id-ecPublicKey
        06 08 2A8648CE3D030107  -- secp256r1
     03 42 00
           04 7F7F35A79794C950060B8029FC8F363A
              28F11159692D9D34E6AC948190434735
              F833B1A66652DC514337AFF7F5C9C75D
              670C019D95A5D639B72744C64A9128BB

The SHA-256 hash of the 65 bytes 047F7F...BB is:

  BF37B3E5808FD46D54B28E846311BCCE1CAD2E1A62AA9092EF3EFB3F11451F44

The SHA-1 hash of these 65 bytes is:

  6FEF9162C0A3F2E7608956D41C37DA0C8E87F0AE

The SHA-256 hash of the 91 bytes 305930...BB is:

  6D20896AB8BD833B6B66554BD59B20225D8A75A296088148399D7BF763D57405

Using method 1 from Section 2, the subjectKeyIdentifier would be:

  30 1D
     06 03 551D0E -- id-ce-subjectKeyIdentifier
     04 16
        04 14 BF37B3E5808FD46D54B28E846311BCCE1CAD2E1A

Using method 4 from Section 2 with SHA-256 and no truncation, the subjectKeyIdentifier extensions would be:

  30 29
     06 03 551D0E -- id-ce-subjectKeyIdentifier
     04 22
        04 20 6D20896AB8BD833B6B66554BD59B2022
              5D8A75A296088148399D7BF763D57405

4. Security Considerations 🔒

bestie, this is important 😭 The security considerations of [RFC5280] apply to certificates. The security considerations of [RFC5758] apply to the hash algorithms.

While hash algorithms give you preimage resistance, second-preimage resistance, and collision resistance, none of those properties are needed for key identifiers. so you don't have to panic about it 💀

5. Acknowledgements 🫶

The authors thank Santosh Chokhani, Stephen Farrell, Tom Gindin, Peter Gutmann, Henry Holtz, David Kemp, Timothy Miller, Michael StJohns, Stefan Santesson, Jim Schaad, Rene Struik, Koichi Sugimoto, and Carl Wallace for joining the discussions about this document 💜 Those chats led to a bunch of editorial and technical changes, iykyk ✨

6. Normative References 📚

• [RFC5280]: Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
• [RFC5758]: Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. Polk, "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", RFC 5758, January 2010.
• [SHS]: National Institute of Standards and Technology (NIST), FIPS Publication 180-3: Secure Hash Standard, October 2008.

---

Authors' Addresses 💌

Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA

EMail: turners@ieca.com

Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA

EMail: kent@bbn.com

James Manger Telstra 6 / 150 Lonsdale Street Melbourne, Victoria 3000 Australia

EMail: james.h.manger@team.telstra.com 🦋