idnits 2.17.1 draft-shoemaker-acme-onion-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 26 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 July 2020) is 1382 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'TOR-REND-V3' ** Downref: Normative reference to an Informational RFC: RFC 2986 -- Possible downref: Non-RFC (?) normative reference: ref. 'CABF-BR' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACME Working Group R.B. Shoemaker 3 Internet-Draft ISRG 4 Intended status: Standards Track 7 July 2020 5 Expires: 8 January 2021 7 Automatic Certificate Management Environment (ACME) Onion v3 Identifier 8 Validation Extension 9 draft-shoemaker-acme-onion-01 11 Abstract 13 This document specifies identifiers and challenges required to enable 14 the Automatic Certificate Management Environment (ACME) to issue 15 certificates for Onion Addresses as specified in Tor Rendezvous 16 Specification - Version 3. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 8 January 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Onion Address Identifier . . . . . . . . . . . . . . . . . . 2 54 4. Onion CSR Challenge . . . . . . . . . . . . . . . . . . . . . 3 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 5.1. Identifier Types . . . . . . . . . . . . . . . . . . . . 4 57 5.2. Challenge Types . . . . . . . . . . . . . . . . . . . . . 4 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 60 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 61 9. Informative References . . . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 Currently the Automatic Certificate Management Environment (ACME) 67 [RFC8555] only specifies how DNS identifiers and IP address 68 identifiers [RFC8738] may be validated for inclusion in x.509 69 certificates [RFC5280]. This document extends the protocol to 70 include a validation mechanism for Tor version 3 Onion Addresses 71 [TOR-REND-V3]. 73 2. Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 77 "OPTIONAL" in this document are to be interpreted as described in BCP 78 14 [RFC2119] [RFC8174] when, and only when, they appear in all 79 capitals, as shown here. 81 3. Onion Address Identifier 83 Version 3 Onion address identifier objects MUST use the type "onion- 84 v3". The value field of the identifier MUST contain the textual 85 encoding of the address as defined as onion_address in [TOR-REND-V3] 86 section 6. ACME servers MUST verify that the value field contains a 87 properly encoded address by checking that it contains only two 88 labels, that first label contains a valid checksum, and that the last 89 byte of the first label is \x03. [TODO: this could probably be 90 specified better?] 92 An identifier for the version 3 Onion address address for the 93 following Ed25519 public key would be formatted like so: 95 -----BEGIN PUBLIC KEY----- 96 MCowBQYDK2VwAyEAAJhLnbvXNWu8WXre3Y0HU+1FErU13zcbO7pEqkI38+Q= 97 -----END PUBLIC KEY----- 99 {"type": "onion-v3", "value": "acmexhn3242wxpczplpn3dihkpwukevvgxptogz3xjckuqrx6pscepad.onion"} 101 4. Onion CSR Challenge 103 This document specifies a single new challenge type that can be used 104 for validation of onion-v3 identifiers. This challenge demonstrates 105 control of the private key associated with the public key contained 106 within the Onion address by signing a CSR containing special 107 attributes. The challenge object contains the following fields: 109 type (required, string): The string "onion-v3-csr" 111 nonce (required, string): A random value that uniquely identifies 112 the challenge. This value MUST have at least 64 bits of entropy. 113 It MUST NOT contain any characters outside the base64url alphabet 114 as described in [RFC4648] Section 5. Trailing '=' padding 115 characters MUST be stripped. See [RFC4086] for additional 116 information on randomness requirements. 118 The client prepares for validation by constructing a Certificate 119 Signing Request (CSR) [RFC2986]. This CSR MUST contain two 120 attributes, a caSigningNonce attribute containing the nonce provided 121 in the challenge object, and a applicantSigningNonce attribute 122 containing a random value picked by the client. This random value 123 MUST have at least 64 bits of entropy. The CSR MUST be signed by the 124 private key associated with the public key contained within the Onion 125 address. 127 The caSigningNonce and applicantSigningNonce attributes are defined 128 as follows in [CABF-BR] Appendix F 129 cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } 131 caSigningNonce ATTRIBUTE ::= { 132 WITH SYNTAX OCTET STRING 133 EQUALITY MATCHING RULE octetStringMatch 134 SINGLE VALUE TRUE 135 ID { cabf-caSigningNonce } 136 } 138 cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } 140 applicantSigningNonce ATTRIBUTE ::= { 141 WITH SYNTAX OCTET STRING 142 EQUALITY MATCHING RULE octetStringMatch 143 SINGLE VALUE TRUE 144 ID { cabf-applicantSigningNonce } 145 } 147 The client completes the challenge process by POSTing a JSON object 148 containing the signed CSR they generated to the challenge URL. The 149 base64url encoding of the protected headers and payload is described 150 in Section 6.1 of [RFC8555]. The JSON object contains the following 151 fields: 153 csr (required, string): The base64url-encoded DER encoding of the 154 signed CSR. 156 On receiving this request from a client the ACME server verifies the 157 CSR by checking that it contains the caSigningNonce attribute, and 158 that it's value matches the nonce in the challenge object it created, 159 the applicantSigningNonce, and that the value contains a random value 160 with at least 64 bits of entropy, and that the signature can be 161 verified using the public key encoded in the Onion address that is 162 being validated. If all of these checks succeed, then the validation 163 is successful. Otherwise, it is a failure. 165 5. IANA Considerations 167 5.1. Identifier Types 169 Adds a new type to the "ACME Identifier Types" registry defined in 170 Section 9.7.7 of [RFC8555] with Label "onion-v3" and Reference "I- 171 D.shoemaker-acme-onion". 173 5.2. Challenge Types 175 Adds one new entry to the "ACME Validation Methods" registry defined 176 in Section 9.7.8 of [RFC8555] as defined below. 178 +--------------+-----------------+------+--------------------------+ 179 | Label | Identifier Type | ACME | Reference | 180 +==============+=================+======+==========================+ 181 | onion-v3-csr | onion-v3 | Y | I-D.shoemaker-acme-onion | 182 +--------------+-----------------+------+--------------------------+ 184 Table 1 186 6. Security Considerations 188 [NOTE: Probably should consider _something_ here (may want to 189 reference [TOR-REND-V3] Section 2.2.7?).] 191 7. Acknowledgments 193 The author would like to thank those who offered editorial and 194 technical input on the document. Special thanks to the participants 195 in the CA/Browser who specified the initial validation mechanisms and 196 controls for Onion Addresses. 198 8. Normative References 200 [TOR-REND-V3] 201 Tor Project, "Tor Rendezvous Specification - Version 3", 202 2020, . 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, 206 DOI 10.17487/RFC2119, March 1997, 207 . 209 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 210 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 211 . 213 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 214 Request Syntax Specification Version 1.7", RFC 2986, 215 DOI 10.17487/RFC2986, November 2000, 216 . 218 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 219 Kasten, "Automatic Certificate Management Environment 220 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 221 . 223 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 224 Housley, R., and W. Polk, "Internet X.509 Public Key 225 Infrastructure Certificate and Certificate Revocation List 226 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 227 . 229 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 230 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 231 May 2017, . 233 [CABF-BR] CA/Browser Forum, "Baseline Requirements for the Issuance 234 and Management of Publicly-Trusted Certificates, Version 235 1.6.8", 2020, . 238 [RFC8738] Shoemaker, R.B., "Automated Certificate Management 239 Environment (ACME) IP Identifier Validation Extension", 240 RFC 8738, DOI 10.17487/RFC8738, February 2020, 241 . 243 9. Informative References 245 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 246 "Randomness Requirements for Security", BCP 106, RFC 4086, 247 DOI 10.17487/RFC4086, June 2005, 248 . 250 Author's Address 252 Roland Bracewell Shoemaker 253 Internet Security Research Group 255 Email: roland@letsencrypt.org