Re: [Acme] draft-misell-acme-onion
Seo Suchan <tjtncks@gmail.com> Mon, 17 April 2023 13:26 UTC
Return-Path: <tjtncks@gmail.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 89311C14EB17 for <acme@ietfa.amsl.com>; Mon, 17 Apr 2023 06:26:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.595
X-Spam-Level:
X-Spam-Status: No, score=-5.595 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JopMTe14LBuP for <acme@ietfa.amsl.com>; Mon, 17 Apr 2023 06:26:55 -0700 (PDT)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A871C15171E for <acme@ietf.org>; Mon, 17 Apr 2023 06:26:55 -0700 (PDT)
Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-517c0b93cedso1523878a12.3 for <acme@ietf.org>; Mon, 17 Apr 2023 06:26:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681738014; x=1684330014; h=in-reply-to:subject:from:references:cc:to:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=uHfRLMcXvNWVe5yYOBF7bXbomzQyfMDFZh1RHFS7b/E=; b=RvR6RC0j8ypxZS0HdZQak3ecSKtWuW7kRm74Xy/7Y8uBffojXB0RWoGlWkkuhGBGV4 oliamRZt3Glh7hQsoVqNmQOq7OGJjlGjejtkhzuD+pTRhEmWf8H4z860FKEXU9qnNCJN SQlq5PxhcIy1wN6VyjuzJCfC1ic1fyiruePTzIH9wZAFZA6R0ddCTFFF/2xL9/0bmvvv 3KOohnz03Kj4b2VXP1rzhcmKTUgRS77RJGkX5GZ4wa/CyTULAF9xdVVJ0JcaOCWj0Q9N tUCbnisw+tkHJuJf196EXi48WmJ4SXFrtuwjK2gVP99AlHoIfqEe4m5qpgHFP/KI/p9R YHcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681738014; x=1684330014; h=in-reply-to:subject:from:references:cc:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=uHfRLMcXvNWVe5yYOBF7bXbomzQyfMDFZh1RHFS7b/E=; b=Zrj+PYXzIZgMIf7f6ozqyJNrjdYmSVUuonN5xz54mUwFvT4jt16srJsI70B0gx/LXb 5ZSiQjvDgHiFSOyIZlygBOd/Iw0hhF2F5I5C8Ij+65tZU/5gZjFJ+yNzcrjpHjLOBk+G IavGgK7MWP9UHyQckPgu5aCyuDsLuXJiEv1bB0bxUWjOSLHn5DUq+dqCgaQwyIAT41ZO 3EMKCOpPdeSFNjjeBSBNnz42kksmGA8t+fzA5TQ/8ftKdX9UsvDwXDIwUCKnXXWhSzGL WLKXAtJRpDtKNKwlNha6y2ZiuI6qEUqfASo4axYWUy4CYbHvrGYMwMRnrybK6Rd4OEFE mMeg==
X-Gm-Message-State: AAQBX9eWaquZCE6DjOUvUzDCH9O3vU5nreO+taIGXmE3k1cz9W2JqKWv OZHChe3cSgUYcL3xsLfaQEOk6mSxqDXdhw==
X-Google-Smtp-Source: AKy350Y7WsLiNMFGBlSHTPb1di+uFxI7kjQWMcFikkd1MbgmgbgAJ6xsSjkjNaKsuezqoQhB2j/T3w==
X-Received: by 2002:a05:6a00:99f:b0:63c:1be4:5086 with SMTP id u31-20020a056a00099f00b0063c1be45086mr5159422pfg.6.1681738014343; Mon, 17 Apr 2023 06:26:54 -0700 (PDT)
Received: from [192.168.1.30] ([59.5.237.171]) by smtp.gmail.com with ESMTPSA id p16-20020a62ab10000000b0063b6e3e5a39sm5423777pff.52.2023.04.17.06.26.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Apr 2023 06:26:53 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------hqq0NsOB21yLvwZVKKwGc0qP"
Message-ID: <cde7c775-ba48-daa9-67a1-154ed76946be@gmail.com>
Date: Mon, 17 Apr 2023 22:26:51 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: Q Misell <q@as207960.net>
Cc: acme@ietf.org
References: <CAMEWqGuuRsYF-EoFs44DSZ0X0z5iOuKa8iMC38Yuh24F0fWYXQ@mail.gmail.com> <214b80c1-b234-07ae-e33c-bda3d6c1f542@gmail.com> <CAMEWqGuTDGyEQ+ZsiMqo5q9XiYHLr4Uxrp0gUOi3vRFFPV6dKg@mail.gmail.com> <0b2bf652-2e47-b3a0-dade-52ec0257de96@gmail.com> <CAMEWqGvqM8zxw0x739-ZcOn55niJJT9gdv7w9RNwRYoYK78uzg@mail.gmail.com>
From: Seo Suchan <tjtncks@gmail.com>
In-Reply-To: <CAMEWqGvqM8zxw0x739-ZcOn55niJJT9gdv7w9RNwRYoYK78uzg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/UynPLYHXFsT1UjXzod7lulhlMY8>
Subject: Re: [Acme] draft-misell-acme-onion
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 17 Apr 2023 13:26:59 -0000
Does tor itself allows including random things in their hidden service descriptor? tor-addr-spec-v3 2.5.1.2 says for first level plaintext field "Here are all the supported fields" and does not say client to ignore any additional field, so I don't think we can add descriptor field in 5.3 without amending breaking change to tor add spec first - which make . second level plaintext format still lists all formats they have: although for this they do make clients to ignore unrecognized lines. but just for compatibility with future revisions over tor spec. I think we need to call tor people to include CAA into descriptor: looks like they are open to modifying tor spec quite fast, 4-5 commit per month in rend-spce-v3 file alone https://gitlab.torproject.org/tpo/core/torspec/ 2023-04-17 오후 8:29에 Q Misell 이(가) 쓴 글: > Point taken, I think you're right. > > Might I suggest then two CSRs, one signed with the onion key to be > submitted as a challenge response, and one submitted to finalize the > order. > > On Sun, 16 Apr 2023 at 22:08, Seo Suchan <tjtncks@gmail.com> wrote: > > I think this section implies CSR has to be signed by what subjectPublickeyinfo be used for verify it: > > rfc2986 section 3 note 2. > > Note 2 - The signature on the certification request prevents an > entity from requesting a certificate with another party's public key. > Such an attack would give the entity the minor ability to pretend to > be the originator of any message signed by the other party. This > attack is significant only if the entity does not know the message > being signed and the signed part of the message does not identify the > signer. The entity would still not be able to decrypt messages > intended for the other party, of course. > > subject public key and subject entity's private key not being matching pair feels stretching the rule as written. > and even if csr is allowed I don't think merging finalization and challenge verify is a good idea here: > 1. Pre-authorization (rfc8555 7.4.1) makes challenge may not have parent order. > 2. a order capable of finalize in pending state makes ready state check useless, in boulder that's only place actually checks for order's validity before calling CA to sign the certificate > 3. most acme CA moved to async order finalization, so it will move to processing if it wants or not. > > 2023-04-17 오전 12:58에 Q Misell 이(가) 쓴 글: >> Hi, >> >> Thanks for the comments. I'll fix the typos. >> >> With regard to running a Tor client or not I don't think it is >> too much of a ask from CAs to run a Tor client (it needn't even >> be that feature complete to simply fetch a HS descriptor), for >> the added benefit of CAA enforcement. >> >> Regarding your comment about CSRs I think you've misunderstood >> how the CSR is used. RFC2986 section 3 states that the >> CertificationRequestInfo contains the public key to be included >> in the final certificate (subjectPKInfo), whilst the entire >> CertificationRequest can be signed with a different key entirely, >> and this is what the CA/BF rules permit, and indeed what they >> were designed to achieve and how HARICA implements this. >> >> Thanks, >> Q >> >> On Sun, 16 Apr 2023 at 03:44, Seo Suchan <tjtncks@gmail.com> wrote: >> >> 5.2 has few typos CAA when it should mean CA: (CAA can't read >> any descriptor, it's a text) >> >> For running CAA in general, I think appendix B of CA/B BR >> method b made in a way that CA doesn't have to run Tor client >> at all. And it actually allows signing a cert for not yet >> hosted onion domain, given they control right private key to >> induce that domain name. In that case making CA required to >> run Tor client to read CAA conflicts this goal. >> >> And challenge 3.2, it doesn't work for public CA: in acme >> context, CSR's pubkey sent in finalization is what CA will >> sign, but for challange perspective key there need to be >> ed25519 key (because it's onion v3 private key,) but CA/B >> does not allow signing ed25519 key in TLS certificate, you >> can't reuse CSR for both purpose. >> >> >> 2023-04-16 오전 1:22에 Q Misell 이(가) 쓴 글: >> >>> Hi all, >>> >>> >>> Hope you've all recovered from IETF116, it was lovely seeing >>> you all there. Thanks to those who already gave me feedback >>> on my draft. >>> >>> As promised in my brief presentation at the WG meeting, >>> here's my post introducing my draft draft >>> <https://datatracker.ietf.org/doc/draft-misell-acme-onion/>-misell-acme-onion >>> <https://datatracker.ietf.org/doc/draft-misell-acme-onion/> to >>> ease issuance of certificates to Tor hidden services. >>> >>> DigiCert and HARICA already issue X.509 certificates to Tor >>> hidden services but there is no automation whatsoever on >>> this. From my discussions with the Tor community this is >>> something that bothers them so I've taken to writing this >>> draft to hopefully address that. >>> >>> The draft defines three ways of validation: >>> - http-01 over Tor >>> - tls-alpn-01 over Tor >>> - A new method onion-csr-01, where the CSR is signed by the >>> key of the onion service >>> >>> An explicit non goal is to define validation methods not >>> already approved by the CA/BF, however if someone can make a >>> compelling argument for an entirely novel method I wouldn't >>> be entirely opposed to it. >>> >>> Looking forward to your feedback, and some indication that >>> this would be worth adopting as a WG draft. >>> >>> Thanks, >>> Q Misell >>> >>> _______________________________________________ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >>
- [Acme] draft-misell-acme-onion Q Misell
- Re: [Acme] draft-misell-acme-onion Seo Suchan
- Re: [Acme] draft-misell-acme-onion Q Misell
- Re: [Acme] draft-misell-acme-onion Seo Suchan
- Re: [Acme] draft-misell-acme-onion Q Misell
- Re: [Acme] draft-misell-acme-onion Corey Bonnell
- Re: [Acme] draft-misell-acme-onion Seo Suchan
- Re: [Acme] draft-misell-acme-onion Q Misell