Individual Submission M. Palmer Internet-Draft pwnedkeys.com Intended status: Experimental 15 June 2023 Expires: 17 December 2023 A Standard Format for Key Compromise Attestation draft-mpalmer-key-compromise-attestation-00 Abstract This document describes a profile for a PKCS#10 Certificate Signing Request (CSR) that attests with reasonable confidence that the key which signed the CSR has been compromised. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mpalmer-key-compromise- attestation/. Source for this draft and an issue tracker can be found at https://github.com/pwnedkeys/key-compromise-attestation-rfc. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 17 December 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Palmer Expires 17 December 2023 [Page 1] Internet-Draft Key Compromise Attestation June 2023 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 review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Purpose and Goals of a Key Compromise Attestation . . . . . . 3 4. Structure of a Key Compromise Attestation . . . . . . . . . . 3 4.1. CSR Subject . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. CSR Subject Public Key . . . . . . . . . . . . . . . . . 4 4.3. CSR Attributes . . . . . . . . . . . . . . . . . . . . . 4 4.4. CSR Signature . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5.1. Generating Key Compromise Attestations . . . . . . . . . 4 5.2. Processing Key Compromise Attestations . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction When a private key becomes compromised through disclosure or intrusion, it can be difficult to safely and conclusively demonstrate to third parties that the key is, in fact, compromised. Different parties have different standards of proof, and the tools available to them may differ. In many cases, the lowest-common-denominator approach, that of providing the actual compromised private key, is used, which increases the risk of further disclosure and the associated hazards. This document describes a specific profile for a PKCS#10 [RFC2986] Certificate Signing Request (CSR) which provides a reliable attestation that a private key has been compromised. The use of an existing format allows re-use of existing tools for generating and validating the CSR, whilst minimising the risk of inadvertent misuse of a CSR generated for another purpose. Palmer Expires 17 December 2023 [Page 2] Internet-Draft Key Compromise Attestation June 2023 2. Conventions and Definitions 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. Purpose and Goals of a Key Compromise Attestation An attestation of key compromise is a document which verifiably attests that a private key is no longer private. This destroys the utility of that key for cryptographic operations, as the fundamental assumption of the private key -- that it is private -- no longer holds. An attestation of key compromise should be useable by both first parties (the legitimate "owner" of the private key) as well as third parties (anyone who happens to come across a compromised private key and wishes to attest that it has been compromised). It must be durable and reliable, in that it must not expire or otherwise become significantly less trustworthy over time. It must also not require the real-time possession of the private key itself, to allow for attestation of compromise even in situations where the access to the key material has been lost or is not kept permanently online. Ideally, a key compromise attestation should be simple to generate and verify with existing tools, and not require extensive new code or infrastructure to be useful. 4. Structure of a Key Compromise Attestation The format of a key compromise attestation is a PKCS#10 [RFC2986] Certificate Signing Request (CSR), with a specified subject and extension to minimise the chances of it being mistaken for a legitimate CSR useful for some other purpose. The CSR format was chosen because it is already in wide use for ad hoc attestation of key compromise, and as such has wide existing support for verification and handling. A very constrained CSR profile is specified to enhance resistance to collision attacks against the hashes used in signatures. Palmer Expires 17 December 2023 [Page 3] Internet-Draft Key Compromise Attestation June 2023 4.1. CSR Subject The subject field of a key compromise attestation CSR MUST be a distinguished name which contains only a CN field, with the value "kca=v1 This Key Is Compromised" (without the quotes) as a UTF8String. Additional fields SHOULD NOT appear in the subject of the CSR, as they may be used to provide attacker-controlled prefix data. 4.2. CSR Subject Public Key The subjectPKInfo field of the key compromise attestation CSR MUST be the SubjectPublicKeyInfo of the key which is attested as having been compromised. 4.3. CSR Attributes A key compromise attestation CSR MUST contain an Attributes section with a single attribute, an extensionRequest [RFC2985]. The extensionRequest, in turn, MUST contain a single extension, a NoSecurityAfforded [RFC7169] extension, with a value of TRUE. Per [RFC7169], this extension MUST be marked critical. 4.4. CSR Signature The signature carried by the CSR MUST be made by the key which is attested as having been compromised. 5. Security Considerations As the consequences for erroneously generating, disseminating, or accepting a key compromise attestation can be significant (the complete loss of utility of a key or key-using artifact, such as a certificate), it is important that compromise attestations are securely generated and validated before use. 5.1. Generating Key Compromise Attestations An attestation of key compromise is a potent service denial tool in the wrong hands. As such, a key compromise attestation should never be generated for a key which is not (yet) compromised, unless the resulting attestation will be carefully secured against disclosure. While the improper disclosure of a compromise attestation is not as catastrophic as a key compromise, it can certainly have unwanted consequences. Palmer Expires 17 December 2023 [Page 4] Internet-Draft Key Compromise Attestation June 2023 Key compromise attestations do not introduce any new security issues for systems which are capable of signing arbitrary data, although the consequences of signing the wrong thing are somewhat different. If a miscreant is capable of coercing a system into signing a key compromise attestation, this could be used to deny further use of the key. However, the potential for mischief if a miscreant is capable of signing arbitrary data is already significant. 5.2. Processing Key Compromise Attestations The consequences of incorrectly accepting an invalid attestation of key compromise can be significant. As such, it is important that any attestation should be carefully examined to ensure its validity before it is relied upon. The first thing that MUST be checked on any attestation is the signature. This signature SHOULD be validated against the subjectPublicKeyInfo in the CSR. If the signature does not validate, then under no circumstances should the attestation be relied upon for any purpose. Given a valid signature, the subjectPKInfo in the CSR MUST be compared against the subjectPublicKey info of the key(s) which are to be checked for compromise. This MAY be done via direct comparison, or via comparison of a SHA256 (or equivalently robust) hash of the keys. However, it is important to bear in mind that some key formats, in particular elliptic curve keys [SEC1], have multiple valid representations. The subjectPublicKeyInfo data in both the CSR and the key(s) in use MUST be normalised to a common format before comparison, to avoid false negatives. The subject of the CSR should be checked to ensure it indicates that the CSR is a Key Compromise Attestation, and not a regular CSR. The prefix "kca=v1 " in the CN field indicates the version of the attestation, while the remainder of the field is a more human- readable indication that the key is compromised and should not be used. Ensuring the presence of the NoSecurityAfforded extension is of lesser importance, as its presence is primarily to prevent the accidental use of the compromise attestation CSR for other purposes. Any system which validates attributes in a CSR before use should fail to process the extension (as it MUST be marked critical), while any system which blindly copies attributes from the CSR to the eventual certificate will produce a certificate which, once again, will fail to validate. Systems which blindly copy attributes from a CSR to a certificate whilst resetting the critical flag are beyond help. Palmer Expires 17 December 2023 [Page 5] Internet-Draft Key Compromise Attestation June 2023 Because key compromise attestations do not expire, and do not need to be "refreshed" on a regular basis, it is possible that over time attestations may exist whose signatures use hash algorithms which are not considered particularly strong at the time of comparison. Processors of key compromise attestations SHOULD reject a key compromise attestation which uses a signature algorithm known to be weak to second pre-image attacks, and which also contains additional subject distinguished name fields and/or attributes and extensions. When a valid key compromise attestation is received, all use of the compromised key should cease as soon as possible. Further, the compromised key SHOULD be remembered as compromised, to prevent the inadvertent reuse of that key in the future. Whilst storage of a potentially unbounded list of banned keys is problematic, it is important to bear in mind that a compromised key is compromised forever. Debian weak keys [DWK] have been spotted being used in the wild over a decade after their existence was first revealed, and there is no reason to believe that other compromised keys may not have similar longevity. Systems which receive key compromise attestations from the public must bear in mind that generating many keys, and hence generating many attestations of compromise, is a trivial exercise. If the work required to process a key compromise attestation (such as examining all in-use accounts or certificates to see if they use an attested- compromised key) is significantly greater than the work required to generate a key compromise attestation, it is recommended that defences against Denial of Service attacks due to "flooding" attestations be implemented. Repeated submission of attestations for the same compromised key should not, in general, cause problems for a properly-implemented system. Once a valid attestation has been received, all use of that key should cease. Therefore, if another compromise attestation for the same key is received, it should be sufficient to verify that the key is already in the "banned keys" list, without going through the entire attestation handling chain again. 6. IANA Considerations This document has no IANA actions. 7. References 7.1. Normative References Palmer Expires 17 December 2023 [Page 6] Internet-Draft Key Compromise Attestation June 2023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, DOI 10.17487/RFC2985, November 2000, . [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, . [RFC7169] Turner, S., "The NSA (No Secrecy Afforded) Certificate Extension", RFC 7169, DOI 10.17487/RFC7169, April 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [DWK] The Debian Project, "DSA-1571-1 openssl -- predictable random number generator", May 2008, . [SEC1] Standards for Efficient Cryptography Group (SECG), "SEC 1: Elliptic Curve Cryptography", September 2000. Acknowledgments The author acknowledges the contributions of the many, many people who leave their private keys in public places, providing such a wealth of opportunity for handling and reporting their compromise to the appropriate parties. Author's Address Matt Palmer pwnedkeys.com Email: matt@pwnedkeys.com Palmer Expires 17 December 2023 [Page 7]