RFC 7169

RFC 7169: The NSA (No Secrecy Afforded) Certificate Extension 🕵️‍♀️✨

okay bestie, here's the deal 💅 RFC 7169 is an Informational doc from Sean Turner at IECA, Inc. It was published on 1 April 2014 as an Independent Submission (ISSN 2070-1721). The title block doesn't list anything it obsoletes or updates. It's giving April Fools, but it's a real document 🫶

---

Abstract 🧾

okay so this doc defines the NSA (No Secrecy Afforded) certificate extension for certain PKIX (X.509 Pubic Key Certificates) digital certificates 🔐 Back in the day, clients and servers tried super hard to keep their keys private 😭 But sometimes the secrecy of a private key just can't be guaranteed. A client or server might feel like they'll be pressured to hand their keys over to a third party later 👀 And some have already been pressured and want to tell relying parties at certificate renewal that their keys really were shared 💖

Status of This Memo 📝

this doc is not an Internet Standards Track spec. It's published for info purposes only 🌸

this is a contribution to the RFC Series, separate from any other RFC stream 🎀 The RFC Editor picked to publish it at their discretion and makes no statement about its value for implementation or deployment. Docs approved by the RFC Editor aren't a candidate for any level of Internet Standard (see Section 2 of RFC 5741) 💅

for the current status, errata, and how to send feedback, check:

http://www.rfc-editor.org/info/rfc7169

Copyright Notice ©️

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 🦋

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 🧚

---

1. Introduction 🌈

ngl, it's a little chaotic out here. Insecurity abounds when clients and servers can't keep their private keys private 💀 Still, there are situations where clients and servers have shared their private keys with a third party. One example of over-sharing is lawful intercept 🙈

Just because a private key has been shared doesn't mean the holder wants to hide that fact 🫣 Being open about it, saying the key may be or has been shared with a third party, is the best way to tell relying parties that sharing happened. Knowledge is power, after all 👑 Extensions for certificates [RFC5280] are an excellent way to signal that an entity's keys have been shared, and this doc specifies one such certificate extension for entities that have shared their private key: the NSA (No Secrecy Afforded) certificate extension ✨

2. The NSA Certificate Extension 🔥

so, to let entities that have shared their keys with a third party say so, the NSA certificate extension is defined here. The ASN.1 [X.680] for the extension is:

ext-KeyUsage EXTENSION ::= { SYNTAX
      BOOLEAN  IDENTIFIED BY id-pe-nsa }

id-pe-nsa OBJECT IDENTIFIER ::=  { id-pe 23 }

the way it works: setting the boolean to TRUE means the key has been shared with a third party 🎀 Setting the extension to FALSE means the key may have been shared with a third party, but the signer doesn't want to overtly say so 🙊 This extension is always marked critical 💜

3. Security Considerations 🚨

this section is serious, bestie 😭 Having to disclose keys is sometimes unavoidable. Explicitly saying the keys have been shared is one way to reduce the risk that a relying party is unaware of this over-share 🫶 Whatever the reason for sharing, the certificate signer needs to carefully consider whether to include this extension 🧐

Any key with this extension must be trusted with care. Lengthy deliberation about whether to trust the keys is necessary. Rushing a security analysis is never a good thing 🙅‍♀️ Ultimately, the keys need not be trusted. Secrecy is hard. 💔

4. 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.

[X.680]: ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 2002.

Author's Address 🧚‍♀️

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

EMail: turners@ieca.com
XMPP:  sean.turner@jabber.psg.com