Internet DRAFT - draft-shoemaker-acme-onion
draft-shoemaker-acme-onion
ACME Working Group R.B. Shoemaker
Internet-Draft ISRG
Intended status: Standards Track 8 July 2020
Expires: 9 January 2021
Automatic Certificate Management Environment (ACME) Onion v3 Identifier
Validation Extension
draft-shoemaker-acme-onion-02
Abstract
This document specifies identifiers and challenges required to enable
the Automatic Certificate Management Environment (ACME) to issue
certificates for Onion Addresses as specified in Tor Rendezvous
Specification - Version 3.
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 9 January 2021.
Copyright Notice
Copyright (c) 2020 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 (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. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Shoemaker Expires 9 January 2021 [Page 1]
Internet-DraAutomatic Certificate Management Environment (ACM July 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Onion Address Identifier . . . . . . . . . . . . . . . . . . 2
4. Onion CSR Challenge . . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5.1. Identifier Types . . . . . . . . . . . . . . . . . . . . 4
5.2. Challenge Types . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . 5
9. Informative References . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Currently the Automatic Certificate Management Environment (ACME)
[RFC8555] only specifies how DNS identifiers and IP address
identifiers [RFC8738] may be validated for inclusion in x.509
certificates [RFC5280]. This document extends the protocol to
include a validation mechanism for Tor version 3 Onion Addresses
[TOR-REND-V3].
2. Terminology
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. Onion Address Identifier
Version 3 Onion address identifier objects MUST use the type "onion-
v3". The value field of the identifier MUST contain the textual
encoding of the address as defined as onion_address in [TOR-REND-V3]
section 6. ACME servers MUST verify that the value field contains a
properly encoded address by checking that it contains only two
labels, that first label contains a valid checksum, and that the last
byte of the first label is \x03. [TODO: this could probably be
specified better?]
An identifier for the version 3 Onion address address for the
following Ed25519 public key would be formatted like so:
Shoemaker Expires 9 January 2021 [Page 2]
Internet-DraAutomatic Certificate Management Environment (ACM July 2020
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAAJhLnbvXNWu8WXre3Y0HU+1FErU13zcbO7pEqkI38+Q=
-----END PUBLIC KEY-----
{"type": "onion-v3", "value": "acmexhn3242wxpczplpn3dihkpwukevvgxptogz3xjckuqrx6pscepad.onion"}
4. Onion CSR Challenge
This document specifies a single new challenge type that can be used
for validation of onion-v3 identifiers. This challenge demonstrates
control of the private key associated with the public key contained
within the Onion address by signing a CSR containing special
attributes. The challenge object contains the following fields:
type (required, string): The string "onion-v3-csr"
nonce (required, string): A random value that uniquely identifies
the challenge. This value MUST have at least 64 bits of entropy.
It MUST NOT contain any characters outside the base64url alphabet
as described in [RFC4648] Section 5. Trailing '=' padding
characters MUST be stripped. See [RFC4086] for additional
information on randomness requirements.
The client prepares for validation by constructing a Certificate
Signing Request (CSR) [RFC2986]. This CSR MUST contain two
attributes, a caSigningNonce attribute containing the nonce provided
in the challenge object, and a applicantSigningNonce attribute
containing a random value picked by the client. This random value
MUST have at least 64 bits of entropy. The CSR MUST be signed by the
private key associated with the public key contained within the Onion
address.
The caSigningNonce and applicantSigningNonce attributes are defined
as follows in [CABF-BR] Appendix C
Shoemaker Expires 9 January 2021 [Page 3]
Internet-DraAutomatic Certificate Management Environment (ACM July 2020
cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 }
caSigningNonce ATTRIBUTE ::= {
WITH SYNTAX OCTET STRING
EQUALITY MATCHING RULE octetStringMatch
SINGLE VALUE TRUE
ID { cabf-caSigningNonce }
}
cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }
applicantSigningNonce ATTRIBUTE ::= {
WITH SYNTAX OCTET STRING
EQUALITY MATCHING RULE octetStringMatch
SINGLE VALUE TRUE
ID { cabf-applicantSigningNonce }
}
The client completes the challenge process by POSTing a JSON object
containing the signed CSR they generated to the challenge URL. The
base64url encoding of the protected headers and payload is described
in Section 6.1 of [RFC8555]. The JSON object contains the following
fields:
csr (required, string): The base64url-encoded DER encoding of the
signed CSR.
On receiving this request from a client the ACME server verifies the
CSR by checking that it contains the caSigningNonce attribute, and
that it's value matches the nonce in the challenge object it created,
the applicantSigningNonce, and that the value contains a random value
with at least 64 bits of entropy, and that the signature can be
verified using the public key encoded in the Onion address that is
being validated. If all of these checks succeed, then the validation
is successful. Otherwise, it is a failure.
5. IANA Considerations
5.1. Identifier Types
Adds a new type to the "ACME Identifier Types" registry defined in
Section 9.7.7 of [RFC8555] with Label "onion-v3" and Reference "I-
D.shoemaker-acme-onion".
5.2. Challenge Types
Adds one new entry to the "ACME Validation Methods" registry defined
in Section 9.7.8 of [RFC8555] as defined below.
Shoemaker Expires 9 January 2021 [Page 4]
Internet-DraAutomatic Certificate Management Environment (ACM July 2020
+--------------+-----------------+------+--------------------------+
| Label | Identifier Type | ACME | Reference |
+==============+=================+======+==========================+
| onion-v3-csr | onion-v3 | Y | I-D.shoemaker-acme-onion |
+--------------+-----------------+------+--------------------------+
Table 1
6. Security Considerations
[NOTE: Probably should consider _something_ here (may want to
reference [TOR-REND-V3] Section 2.2.7?).]
7. Acknowledgments
The author would like to thank those who offered editorial and
technical input on the document. Special thanks to the participants
in the CA/Browser who specified the initial validation mechanisms and
controls for Onion Addresses.
8. Normative References
[CABF-BR] CA/Browser Forum, "Baseline Requirements for the Issuance
and Management of Publicly-Trusted Certificates, Version
1.6.9", 2020, <https://cabforum.org/wp-content/uploads/CA-
Browser-Forum-BR-1.6.9.pdf>.
[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, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[TOR-REND-V3]
Tor Project, "Tor Rendezvous Specification - Version 3",
2020, <https://spec.torproject.org/rend-spec-v3>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
Shoemaker Expires 9 January 2021 [Page 5]
Internet-DraAutomatic Certificate Management Environment (ACM July 2020
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[RFC8738] Shoemaker, R.B., "Automated Certificate Management
Environment (ACME) IP Identifier Validation Extension",
RFC 8738, DOI 10.17487/RFC8738, February 2020,
<https://www.rfc-editor.org/info/rfc8738>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9. Informative References
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
Author's Address
Roland Bracewell Shoemaker
Internet Security Research Group
Email: roland@letsencrypt.org
Shoemaker Expires 9 January 2021 [Page 6]
