RFC 9336

X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing

📅 published December 2022, from ietf

📜 RFC 9336: X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing 🎀

okay bestie, let's get into this one 💅 so this doc is an IETF Standards Track document, which means it's the real deal, not just a suggestion 😭 it's from December 2022 and it's authored by T. Ito (SECOM CO., LTD.), T. Okubo (DigiCert, Inc.), S. Turner, and sn3rd 🧚 (the ISSN is 2070-1721, in case you're collecting those) 💜

the main vibe: it defines a new general-purpose Document-Signing KeyPurposeId for the Extended Key Usage (EKU) extension in X.509 certs 🔐 and it's the sort of thing that makes Document-Signing apps super happy 🌸 it doesn't obsolete or update any other RFCs as far as this title block goes ✨

the official Status of This Memo says it's had public review and IESG approval, and you can find errata and feedback at https://www.rfc-editor.org/info/rfc9336 🦋

Abstract ✨

okay so [RFC5280] already lists a bunch of extended key purpose identifiers (KeyPurposeIds) for X.509 certificates 📜 this document adds a general-purpose Document-Signing KeyPurposeId to the Extended Key Usage (EKU) extension 🎀 and Document-Signing apps may require that the EKU extension be present and that this KeyPurposeId be indicated, or the certificate just isn't acceptable to them 🙅‍♀️

Status of This Memo ✨

this is an Internet Standards Track document 💅

it's a product of the IETF and represents the consensus of the IETF community 🫶 it got public review and was approved by the Internet Engineering Steering Group (IESG) 🔥 more info on Internet Standards is in Section 2 of RFC 7841, and you can check the current status, errata, and how to give feedback at https://www.rfc-editor.org/info/rfc9336 🦋

copyright (c) 2022 IETF Trust and the document authors, all rights reserved 💜 this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as of the publication date, so read those carefully because they spell out your rights 🧾 any Code Components pulled out of this doc must include Revised BSD License text (see Section 4.e of the Trust Legal Provisions) and come without warranty, as the Revised BSD License describes 💖

Table of Contents 🧚

1.  Introduction
2.  Conventions and Definitions
3.  Extended Key Purpose for Document Signing
  3.1.  Including the Extended Key Purpose for Document Signing in
        Certificates
4.  Using the Extended Key Purpose for Document Signing in a
        Certificate
5.  Implications for a Certification Authority
6.  Security Considerations
7.  IANA Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Appendix A.  ASN.1 Module
Acknowledgments
Authors' Addresses

1. Introduction 🌸

okay so [RFC5280] lays out several extended key purpose identifiers (KeyPurposeIds) for X.509 certs 📜 and the IANA repository "SMI Security for PKIX Extended Key Purpose" [RFC7299] has even more KeyPurposeIds 🗂️ here's the tea though: using anyExtendedKeyUsage is bad practice for publicly trusted certs 🙈 and there's no public, general KeyPurposeId explicitly assigned for Document Signing 😭 so right now people just grab id-kp-emailProtection, id-kp-codeSigning, or a vendor-defined KeyPurposeId for general Document-Signing stuff 🥲

it gets messy when code signing and S/MIME certs are also used for Document Signing 💀 because changes to the code signing or S/MIME ecosystem can cause unexpected behaviors or hurt cryptographic agility on the Document-Signing side (and vice versa) 🌀

vendor-defined KeyPurposeIds are totally fine when a vendor or group of vendors governs the PKI 🫶 but borrowing (or misborrowing, as the case may be) KeyPurposeIDs outside that vendor-controlled environment can cause problems, and the impact is hard to figure out 😵‍💫

so, it is not favorable to use a vendor-defined KeyPurposeId for signing a document that the vendor doesn't govern 🙅‍♀️ and this document defines an extended key purpose identifier for Document Signing 🎀

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 read as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💅

3. Extended Key Purpose for Document Signing 💜

this spec defines the KeyPurposeId id-kp-documentSigning ✨

as [RFC5280] says, "[i]f the [Extended Key Usage] extension is present, then the certificate MUST only be used for one of the purposes indicated." 🔒 [RFC5280] also notes that "[i]f multiple [key] purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present." 🧠

Document-Signing applications MAY require that the EKU extension be present and that the id-kp-documentSigning be indicated in order for the certificate to be acceptable to that Document-Signing application 🌈

by "Document Signing" in this doc, we mean digitally signing contents that are consumed by people 👀 more precisely, the contents are meant to be shown to a person in a printable or displayable form through services or software, rather than processed by machines 🖨️

3.1. Including the Extended Key Purpose for Document Signing in Certificates 🎀

[RFC5280] specifies the EKU X.509 certificate extension for use on the Internet 🌐 the extension says which purposes the certified public key is valid for 🔑 it can be used alongside the key usage extension, which tells you the set of basic cryptographic operations the certified key may be used for 🧩

here's the EKU syntax, repeated for convenience 💖

  ExtKeyUsageSyntax  ::=  SEQUENCE SIZE (1..MAX) OF KeyPurposeId

  KeyPurposeId  ::=  OBJECT IDENTIFIER

as [RFC5280] describes, the EKU extension may be either critical or non-critical, at the option of the certificate issuer 🎀

this spec defines the KeyPurposeId id-kp-documentSigning 🦋 including it in a certificate means the public key in that cert has been certified for cryptographic operations on contents that are consumed by people 🫶

  id-kp  OBJECT IDENTIFIER  ::=
      { iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) 3 }

  id-kp-documentSigning  OBJECT IDENTIFIER  ::=  { id-kp 36 }

4. Using the Extended Key Purpose for Document Signing in a Certificate 🧚

okay so the intended use case is people consuming the contents of signed documents 📄 again, that means the contents are shown to a person in a printable or displayable form, not processed by machines 🖨️ the digital signature tells the recipient that the content hasn't changed since the identity in the cert's subject signed it 🔏 to validate that signature on people-facing content, implementations MAY perform the steps below during certificate validation 💅

the following procedure looks at the KeyPurposeId(s) in the EKU extension 🔍 restrictions on EKU are derived and implemented from (or configured with) the policy the implementation conforms to 📋

  • if there are no restrictions set for the relying party and relying party software, the certificate is acceptable ✨
  • if there are restrictions set for the relying party and relying party software, then process the KeyPurposeId(s) as described below 🎀

this procedure is meant to permit or prohibit a certain KeyPurposeId, or the complete absence of KeyPurposeIds 🙌 it's outside this document's scope, but the relying party can permit or prohibit combinations of KeyPurposeIds instead of a single one 🧩 there's a consideration on prohibiting combinations in the Security Considerations section 👀 and if both Excluded and Permitted KeyPurposeIds exist, the relying party or its software processes each Excluded restriction first, then each Permitted restriction 🔁

Excluded KeyPurposeId procedure: an Excluded KeyPurposeId is one the relying party or its software prohibits 🚫 examples include anyExtendedKeyUsage, or the complete absence of the EKU extension in a cert 🙈 if a KeyPurposeId in the cert meets the conditions of an Excluded restriction, the relying party or its software rejects the certificate 💀

Permitted KeyPurposeId procedure: a Permitted KeyPurposeId is one the relying party or its software accepts ✅ examples include this general-purpose Document-Signing KeyPurposeId and/or the protocol-specific KeyPurposeIds relevant to Document Signing 🫶 if a KeyPurposeId in the cert meets the condition of a Permitted restriction, the certificate is acceptable 🎉 otherwise, the relying party or its software rejects the certificate 🙅‍♀️

when a single app can handle various data formats, the software may make the excluded and permitted decisions separately for each format it's handling (for example, TEXT and PDF) 📑

5. Implications for a Certification Authority 👑

the procedures and practices a certification authority employs MUST ensure that the correct EKU extension values go into each cert that gets issued 🔐 unless certs are governed by a vendor-specific PKI, certs that indicate usage for Document Signing MAY include the id-kp-documentSigning KeyPurposeId 🎀 including id-kp-documentSigning does not rule out including other KeyPurposeIds 🌈

(part 1 of 2 — more to come, bestie, so stay tuned!) 🫶✨

6. Security Considerations 🔐

Okay bestie, security time, and it's giving serious energy 💅. The id-kp-documentSigning KeyPurposeId is an alternative for two situations: people using id-kp-emailProtection for non-email purposes, and people using id-kp-codeSigning to sign objects other than binary code 🙈. This extended key purpose does not introduce new security risks. It actually reduces existing ones 🛡️, because it gives us a way to separate the other extended key purposes used for communication protocols, which include TLS (id-kp-clientAuth) and S/MIME (id-kp-emailProtection), so we can minimize the risk of cross-protocol attacks.

To reduce the risk of specific cross-protocol attacks, the relying party or the relying party software may additionally prohibit use of specific combinations of KeyPurposeIds. Lowkey a smart move 🧠.

While a specific protocol or signing scheme may choose to come up with their own KeyPurposeIds, some may not have significant motive or resources to set up and manage their own. This general-purpose Document-Signing KeyPurposeId may be used as a stop-gap for those that intend to define their own Document-Signing KeyPurposeId, or for those who do not intend to set up a KeyPurposeId but still would like to distinguish Document Signing from other usages 🌸.

Introduction of this id-kp-documentSigning KeyPurposeId does not introduce any new security or privacy concerns. ✨

7. IANA Considerations 📋

IANA has registered the following OID in the "SMI Security for PKIX Extended Key Purpose" registry (1.3.6.1.5.5.7.3). This OID is defined in Section 3.1. 🎀

             +=========+=======================+============+
             | Decimal | Description           | References |
             +=========+=======================+============+
             | 36      | id-kp-documentSigning | RFC 9336   |
             +---------+-----------------------+------------+

                                 Table 1

IANA has also registered the following ASN.1 [X.680] module OID in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). This OID is defined in Appendix A. 🦋

               +=========+====================+============+
               | Decimal | Description        | References |
               +=========+====================+============+
               | 104     | id-mod-docsign-eku | RFC 9336   |
               +---------+--------------------+------------+

                                  Table 2

8. References 📚

8.1. Normative References

8.2. Informative References

Appendix A. ASN.1 Module 📜

The following ASN.1 [X.680] module provides the complete definition of the Document-Signing KeyPurposeId. 💜

     DocSignEKU { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-docsign-eku(104) }

     DEFINITIONS EXPLICIT TAGS ::=

     BEGIN

     -- EXPORTS ALL --

     -- IMPORTS NOTHING --

     -- OID Arc --

     id-kp  OBJECT IDENTIFIER  ::= {
       iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) kp(3) }

     -- Document-Signing Extended Key Usage --

     id-kp-documentSigning OBJECT IDENTIFIER ::= { id-kp 36 }

     END

Acknowledgments 🫶

We would like to thank Russ Housley for verifying the ASN.1 module. Additionally, we would like to thank Corey Bonnell, Wendy Brown, Russ Housley, Prachi Jain, and Stefan Santesson for their comments. Big thank-yous to the whole squad 🌈.

Authors' Addresses 💌

Tadahiko Ito SECOM CO., LTD. Email: tadahiko.ito.public@gmail.com

Tomofumi Okubo DigiCert, Inc. Email: tomofumi.okubo+ietf@gmail.com

Sean Turner sn3rd Email: sean@sn3rd.com

📦 where this page comes from