Automated Certificate Management Environment (ACME) Onion Identifier Validation Extension

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

Table of Contents

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"}

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

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 }

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"
}

5. IANA Considerations

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

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