[Acme] Onion address validation extension

Roland Shoemaker <roland@letsencrypt.org> Wed, 08 July 2020 17:47 UTC

Return-Path: <roland@letsencrypt.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EA1063A03F3 for <acme@ietfa.amsl.com>; Wed, 8 Jul 2020 10:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jdmcjijc6AKD for <acme@ietfa.amsl.com>; Wed, 8 Jul 2020 10:47:02 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44CC33A03F2 for <acme@ietf.org>; Wed, 8 Jul 2020 10:47:02 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id a6so49906706wrm.4 for <acme@ietf.org>; Wed, 08 Jul 2020 10:47:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=/RIkj/XRay2ahcKRWJLZUHtsSO6y6OyyJJmi4yvTrZA=; b=cLM6/+1ADg2uXD3vUZCk2/FmJ1MqDnGz6WPQ3acQgY30nJPazGxK1jgmk9XyL055bR mKb46wQxLWoEZYzGrm7lfTyUkwp7lpYcFSsJprC1tHYZ8ZAJESfNnKepnGdS86f25Khy pl1Jr8OBRthItBRBtDQS9WQKUEojO7UkgC5+4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/RIkj/XRay2ahcKRWJLZUHtsSO6y6OyyJJmi4yvTrZA=; b=V4DvL7fr9ontwMSTT+9goubL9Wl7QOFU6lRdDnK+CJ+Ad3T60CvW7Nc+FeOvQ0oOBG EMCme+u/EEwwJp5Y07SKfYhcTqYL9tgyprtD4jUhVNaABueARR3vHvSZA0eCtt3e7AEB ReBjqqd0YPTd6oLYkdxboDChEpisf7IQO1ncloXr+3zhc0tzj3xDqWpSUD8qmaGOxmPo ADr0kTjbRbrLaTGjIjXj/m6So+UPI2+p3LeqJuYsvJfIX4LkSO9aBq6Kl5D+ipVSL3aU 56gyT4gRSmGqD5OZJcFgITrayaEvNz3VpszgS0jMk2HLpw/xhsyLmyd4s64mkvOOlVFi ILxQ==
X-Gm-Message-State: AOAM531qstpcugve2CMsmE0mJkPXaYADHUoD60p4rTkFykdCQW94GqJk 1YPfjWdmwuNyYYDKMzA+69L1LaySvnTkEUTzhoBHg+QD8w8bo5dv
X-Google-Smtp-Source: ABdhPJzwWLeSiWxrvudYiowZs5XjiV2RSSX9QVJ9hpRrGGjZ3wGpTIyuTPoyaDAjthB1Frm4EvFdXILHKwz1jrI0/VU=
X-Received: by 2002:adf:ef8a:: with SMTP id d10mr57912219wro.126.1594230420501; Wed, 08 Jul 2020 10:47:00 -0700 (PDT)
MIME-Version: 1.0
From: Roland Shoemaker <roland@letsencrypt.org>
Date: Wed, 08 Jul 2020 10:46:49 -0700
Message-ID: <CAF1ySfGWY3e=mdn0seJjy5M6jBmtZBMzkm1knvF-BF+hmxCBTA@mail.gmail.com>
To: IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e78f3a05a9f1b1dd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/dhidiMhRV6dGBSK5dIbhzT_y3uA>
Subject: [Acme] Onion address validation extension
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2020 17:47:04 -0000

With the recent passage of SC27 at the CA/Browser Forum there are now
acceptable mechanisms for validating v3 Onion addresses for inclusion in DV
certificates. As such it would be good to extend ACME to be able to make
use of these methods. I've written a short draft that covers what is likely
to be the most interesting validation mechanism to CAs (i.e. the one that
doesn't require actually using Tor directly) and would be interested in
thoughts from the WG.

The defined ACME challenge is basically just an adapted version of the
method defined in Appendix C 2.a of version 1.6.9 of the CABF BRs. I think
in general the usage of a CSR as the transport mechanism for the nonces and
key signature are a bit burdensome, and likely to cause some confusion for
implementers (since it introduces yet another place a CSR is
transferred between the client and server, with another non-standard use).
That said I think the first priority in this document is to get out
something that works with current CABF rules. There could be value though
in defining our own validation mechanism that is a bit more
straightforward alongside the existing CABF method and if/when this
document is standardized we could lobby for it's inclusion as a blessed
CABF validation method.