Re: [Acme] Onion address validation extension

Sebastian Nielsen <sebastian@sebbe.eu> Thu, 09 July 2020 15:51 UTC

Return-Path: <sebastian@sebbe.eu>
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 7BBF03A0CED for <acme@ietfa.amsl.com>; Thu, 9 Jul 2020 08:51:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=sebbe.eu
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 HV5YhY7EVWGa for <acme@ietfa.amsl.com>; Thu, 9 Jul 2020 08:51:39 -0700 (PDT)
Received: from dns2.sebbe.eu (dns2.sebbe.eu [IPv6:2001:470:dff1:1:10::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6DE3A0CEC for <acme@ietf.org>; Thu, 9 Jul 2020 08:51:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sebbe.eu; s=root; h=Date:To:From:cc; bh=Me5f2XrCdnyImWzcvXAa37Fe0BmtQ6SfN/J7gpInLXI=; b=Ut6YC4zhMmjKDO4k9Op1j1uxZcQa7ZibsmsX4q9YsgH1jCqAtrIyf3lF4g4y6ubXf3m97BE6Ks zOxjbmlWcy2wIedXg7iXzEwVnSOHxL3d+YZ2MmY1t5QdoxNlCc3TvYpLtGK0fLc8LwFxWAiHW/KbN X6Q0A1SfxE5xBhZo/uD0=;
Received: from localhost ([127.0.0.1] helo=sebastian-desktop) by sebbe.eu with esmtp (Exim 4_94_RC0-31-83e8da8c0-XX) (envelope-from <sebastian@sebbe.eu>) id 1jtYph-000x5O-CF for acme@ietf.org; Thu, 09 Jul 2020 17:51:33 +0200
Received: from [192.168.4.100] (helo=DESKTOPVB5MBIV) by sebbe.eu with esmtpa (Exim 4_94_RC0-31-83e8da8c0-XX) (envelope-from <sebastian@sebbe.eu>) id 1jtYph-000x5L-0W for acme@ietf.org; Thu, 09 Jul 2020 17:51:33 +0200
From: "Sebastian Nielsen" <sebastian@sebbe.eu>
To: "'Mailing List'" <acme@ietf.org>
Message-ID: <006301d65608$d22956e0$767c04a0$@sebbe.eu>
In-Reply-To: <20200709123015.GA214719@LK-Perkele-VII>
References: <CAF1ySfGWY3e=mdn0seJjy5M6jBmtZBMzkm1knvF-BF+hmxCBTA@mail.gmail.com> <002001d65552$1cd504d0$567f0e70$@sebbe.eu> <20200709123015.GA214719@LK-Perkele-VII>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_87_10739910.1594309893343"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIoBxNeWfZA9U1giAhjseBuptMn1wLXznxiAhI0qPGoNLAx8A==
X-Encryption-Target: external
Date: Thu, 09 Jul 2020 17:51:33 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/4iXMFQ5PwWKWu6Xx41FzvSHG2hQ>
Subject: Re: [Acme] =?utf-8?q?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: Thu, 09 Jul 2020 15:51:43 -0000

>>ACME protocol is not meant to proceed to CSR sending until after all
  names are validated. Breaking that would cause implementation
  problems.

Thats why there should be 2 validation types, so a client who support the new "skip ahead" validation type would know that it only needs to request onion-2 validation type, then it would immidiately skip ahead to CSR sending without checking if validation passed - since validation then occurs at CSR stage.

The reason validation is required inside ACME is because ACME (usually) needs to contact external resources to confirm your validations, which incurs a delay. If you can prove the ownership of the domain inside the actual validation response (ergo a self-validating response that can be verified "offline") theres no need to use the full blown ACME infrastructure, then you could just submit the response inside the final CSR.

Of course this wouldn't work for multiple domains, why the normal procedure with checking for validationa (onion-1) would be required.

>>The CSRs are assumed to be self-signed, which is a problem here:

Thats not a problem.
What I proposed, is that you create a CSR over the normal TLS certificate (with its signature belongning the TLS certificate's key) BUT you put your onion signature (a signature of the nonce made with the onion private key) inside the CSR field called "CSR Challenge Password".
 
So basically, you create a TOR signature with the TOR key, insert it in your final TLS CSR (as CSR Challenge Password), and then sign the TLS CSR with the TLS key.

Meaning, that the CSR *are* self-signed, and that they CONTAIN the TOR signature made with the TOR private key, making the CSR being dual-use - both validating the onion name AND also becomes the grounds for your certificate generation.