ACME Working Group                                                S. Seo
Internet-Draft                                               10 May 2022
Intended status: Standards Track
Expires: 11 November 2022


  Automated Certificate Management Environment (ACME) Onion Identifier
                          Validation Extension
                       draft-suchan-acme-onion-00

Abstract

   This document specifies identifiers and challenges required to enable
   the Automated Certificate Management Environment (ACME) to issue
   certificates for Tor Project's onion V3 addresses.

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 11 November 2022.

Copyright Notice

   Copyright (c) 2022 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.





Seo                     Expires 11 November 2022                [Page 1]


Internet-Draft                 ACME-ONION                       May 2022


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Onion Identifier  . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Validation Challenges for Onion address . . . . . . . . . . .   3
     4.1.  Identify Key Possession Challenge . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Identifier Types  . . . . . . . . . . . . . . . . . . . .   5
     5.2.  Challenge Types . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Appendix A.  Notes and Questions to reviews . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   While onion addresses [RFC7686] are in form of DNS address, they
   aren't in part of ICANN hierarchy, and onion name's self-verifying
   construction warrants different verification, duce different
   identifier type for them is worth consider.

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 Identifier

   [RFC8555] only defines the identifier type "dns", that assumes it's
   on public CA/B hierarchy, so to make clear Onion addresses are not
   using normal DNS verification methods, we assign a new identifier
   type for onion v3 addresses, "onion-v3".

   This document only handles V3 version of onion address as defined in
   [Toraddr], identified by 56 letters base domain name ends with d.

   This document doesn't handle about verification of version 2 of onion
   addresses, as they are retired already

   An identifier for the onion address
   aeceulkebl5...4zcuv5hk7fqwad.onion would be formatted like:

   {"type": "onion-v3", "value": "aeceulkebl5...4zcuv5hk7fqwad.onion"}




Seo                     Expires 11 November 2022                [Page 2]


Internet-Draft                 ACME-ONION                       May 2022


   Keep mind in CSR this address still treated as DNS.

4.  Validation Challenges for Onion address

   Onion-v3 identifiers MAY be used with the existing "http-01" and
   "tls-alpn-01" challenges from [RFC8555] Section 8.3 and [RFC8737]
   Section 3 respectively.  To use Onion identifiers with these
   challenges their initial DNS resolution step MUST be skipped and the
   appropriate Tor daemon that in control of CA MUST used to proxy such
   request.

   The existing "dns-01" challenge MUST NOT be used to validate onion
   addresses.

   In addition to challenges earlier RFC defined, This document create
   an additional challenge called "onion-v3-csr".  This challenge can be
   used for wildcard subdomain of Onion address.

4.1.  Identify Key Possession Challenge

   With onion-csr-01 validation, the client in an ACME transaction
   proves its control of an Onion address or subdomain of it by proving
   the possession of Onion hidden service's identity key.  The ACME
   server challenges the client to sign CSR that includes the nonce it
   gave as challenge.

   The onion-csr-01 ACME challenge object has the following format:

   type (required, string):  The string "onion-v3-csr"

   token (required, string):  A random value that uniquely identifies
      the challenge.  This value MUST have at least 128 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 self-signed CSR
   that MUST contain an cabf caSigningNonce Attribute and a
   subjectAlternativeName extension [RFC5280].  The
   subjectAlternativeName extension MUST contain a single dNSName entry
   where the value is the domain name being validated.  The cabf
   caSigningNonce Attribute MUST contain the token string as ascii
   encoded for the challenge.

   The cabf caSigningNonce Attribute is identified by the cabf-
   caSigningNonce object identifier (OID) in the cabf arc [RFC5280].
   consult [cabr] appendix B for how to construct CSR itself in detail.



Seo                     Expires 11 November 2022                [Page 3]


Internet-Draft                 ACME-ONION                       May 2022


   cabf OBJECT IDENTIFIER ::= 2.23.140
   {
     joint-iso-itu-t(2)
       internationalorganizations(23)
         a-browser-forum(140)
   }

   caSigningNonce ATTRIBUTE ::= {
   WITH SYNTAX OCTET STRING
   EQUALITY MATCHING RULE octetStringMatch
   SINGLE VALUE TRUE
   ID { cabf-caSigningNonce }
   }
   cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 }

   applicantSigningNonce ATTRIBUTE ::= {
   WITH SYNTAX OCTET STRING
   EQUALITY MATCHING RULE octetStringMatch
   SINGLE VALUE TRUE
   ID { cabf-applicantSigningNonce }
   }
   cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }

   A client fulfills this challenge by construct the challenge CSR from
   the "token" value provided in the challenge, then POST on challenge
   URL with crafted CSR as payload to request validated by the server.

   POST /acme/authz/1234/1
   Host: example.com
   Content-Type: application/jose+json

   {
     "protected": base64url({
       "alg": "ES256",
       "kid": "https://example.com/acme/acct/1",
       "nonce": "XaYcb5XoTUgRWbTWw_NwkcP",
       "url": "https://example.com/acme/authz/1234/1"
     }),
     "payload": base64url({
          "csr": "MIIBBzCBugIBADAAMCo...gRYTMAhRP8nIH",
        }),
     "signature": "0wSzBJBgNVHREEQ...gYJKoZIhvcNAQkOM"
   }

   On receiving this request from client, the server verifies client's
   control over the onion address by verify that CSR is crafted with
   expected properties:




Seo                     Expires 11 November 2022                [Page 4]


Internet-Draft                 ACME-ONION                       May 2022


   1.  CSR is signed with private part of identity key the requested
       onion address made from.

   2.  A caSigningNonce attribute that contains token Value that
       challenge object provided.

   3.  existence of applicantSigningNonce attribute.  This value SHOULD
       include random value from client side with at least 64bits of
       entropy, and CA MUST recommend to client do so, but servers are
       not expected verify such claim, as by nature it's impossible to
       verify such claim of randomness.

5.  IANA Considerations

5.1.  Identifier Types

   Adds a new type to the Identifier list in ACME Identifier Types with
   the label "onion-v3" and reference I-D.THISDOC.

5.2.  Challenge Types

   in the ACME Validation Methods list:

   Adds the raw "onion-v3-csr" to the Validation Methods.

   Adds the value "onion-v3" to the Identifier Type column for the
   "http-01", "onion-challenge-csr", and "tls-alpn-01" challenges. , and
   reference I-D.THISDOC each of them.

6.  Security Considerations

   As onion addresses are able to generated in massive quantity without
   financial cost, it bypasses the normal ratelimit CAs imposes.  CAs
   SHOULD adapt some measure to prevent DoS of CA by create hugh amount
   of request for onion address.  For example, imposing limit per ACME
   account or require order to have at least one non-onion domain.

7.  Normative References

   [cabr]     Forum, C., "CA/B forum baseline requirement", 26 April
              2022, <https://cabforum.org/wp-content/uploads/CA-Browser-
              Forum-BR-1.8.4.pdf>.

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




Seo                     Expires 11 November 2022                [Page 5]


Internet-Draft                 ACME-ONION                       May 2022


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

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

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

   [RFC7686]  Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
              Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
              2015, <https://www.rfc-editor.org/info/rfc7686>.

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

   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
              <https://www.rfc-editor.org/info/rfc8555>.

   [RFC8737]  Shoemaker, R.B., "Automated Certificate Management
              Environment (ACME) TLS Application-Layer Protocol
              Negotiation (ALPN) Challenge Extension", RFC 8737,
              DOI 10.17487/RFC8737, February 2020,
              <https://www.rfc-editor.org/info/rfc8737>.

   [Toraddr]  Mathewson, N., "Tor address spec", 24 August 2021,
              <https://github.com/torproject/torspec/blob/main/address-
              spec.txt>.

Appendix A.  Notes and Questions to reviews

   should this be about onion address, or all kind of alternative DNS
   systems? should identifier type and challenge type include or strip
   -v3 tag from its name? if we include that how about this doc name
   itself? http-01 and tls-alpn-01 over tor will work as well for like
   onion address V2 or V12, but csr challenge may not. but it's
   reasonable to ask same identifier type should give same set of
   challenges. should the as rigid as complying this will make comply
   CA/B Baseline requirement? while type onion domain name just full



Seo                     Expires 11 November 2022                [Page 6]


Internet-Draft                 ACME-ONION                       May 2022


   onion v3 name itself with example subdomain will exceed rfc line
   limit. but using ... doesn't right in context of domain name. any
   alternative to express truncated FQDN? would "example.onion" work
   while it wouldn't be valid onion name?

Author's Address

   Seo Suchan
   Email: tjtncks@gmail.com










































Seo                     Expires 11 November 2022                [Page 7]