Re: [Acme] Onion address validation extension

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 08 July 2020 20:57 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4383A07CE for <acme@ietfa.amsl.com>; Wed, 8 Jul 2020 13:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level:
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFcJx_mBywMC for <acme@ietfa.amsl.com>; Wed, 8 Jul 2020 13:57:26 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3b.welho.com [83.102.41.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3843A07CB for <acme@ietf.org>; Wed, 8 Jul 2020 13:57:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 12F2713DF2; Wed, 8 Jul 2020 23:57:24 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id GOGSq6W1ZroX; Wed, 8 Jul 2020 23:57:23 +0300 (EEST)
Received: from LK-Perkele-VII (84-253-234-84.bb.dnainternet.fi [84.253.234.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id C9A6972; Wed, 8 Jul 2020 23:57:21 +0300 (EEST)
Date: Wed, 8 Jul 2020 23:57:19 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Roland Shoemaker <roland@letsencrypt.org>
Cc: IETF ACME <acme@ietf.org>
Message-ID: <20200708205719.GA209609@LK-Perkele-VII>
References: <CAF1ySfGWY3e=mdn0seJjy5M6jBmtZBMzkm1knvF-BF+hmxCBTA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAF1ySfGWY3e=mdn0seJjy5M6jBmtZBMzkm1knvF-BF+hmxCBTA@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/elRvSSP-O3_UuHeOZL8cBcOYZrU>
Subject: Re: [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 20:57:28 -0000

On Wed, Jul 08, 2020 at 10:46:49AM -0700, Roland Shoemaker wrote:
> 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.
> 
> Thoughts?
> 
> https://www.ietf.org/id/draft-shoemaker-acme-onion-02.html

Some comments from very quick reading:

- What is the OID prefix for CABF? I do not find it anywhere in the
  document, nor anywhere in the BR(!). Based on some searching, I guess
  it is 2.23.140 (thus cabf-caSigningNonce would be 2.23.140.41, and
  cabf-applicantSigningNonce would be 2.23.140.42).

- One should definitely have example of validation CSR. There are plenty
  of developers that do not have access to ASN.1 compilers (for many
  different reasons), but instead reverse-engineer real-world and test
  samples of various stuff when writing either ASN.1 parsing or
  serialization code. The alternative is them trying to read the ASN.1
  syntax (and likely getting it wrong, as CSR attributes are not
  trivial). No, they will not use ASN.1 compilers.



-Ilari