Re: [Acme] scope in dns-account-01 and dns-02 challenge
Amir Omidi <amir@aaomidi.com> Thu, 21 March 2024 00:57 UTC
Return-Path: <amir@aaomidi.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 76EA4C1519B2 for <acme@ietfa.amsl.com>; Wed, 20 Mar 2024 17:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=aaomidi.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 PgnXOn_ATDqR for <acme@ietfa.amsl.com>; Wed, 20 Mar 2024 17:57:44 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 2C3CDC15793B for <acme@ietf.org>; Wed, 20 Mar 2024 17:57:27 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-56b9e5ed074so482405a12.3 for <acme@ietf.org>; Wed, 20 Mar 2024 17:57:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aaomidi.com; s=google; t=1710982643; x=1711587443; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NcCCsNAwR8Dc7lzDCsU4frbON1Nxj0gXvdgfk6i+yq0=; b=YUnmy41y3jInsSoymwLPcnMNYzidrpFFisqIGwsIyAduq8nB/KaGd6WhJS1CGNXV+G +So3Uia5z901wnMZhC5SZYKM6z8OwGZW5e7AQ+oxbHzKth8rU0kelhMo5RaWPfXImjQ2 fXC/gnnUT8nsNMQHKWLX1p5Gj/NQWDLNP4J0QAXpke5QZCGGJbPEy1HzjnjhQMf3fGFg 9fSTLBcYsVA1QznEBVDyE7pKuWOrJO53qNZnW/hxfeIrgMaDB2uqqCDVox/C64ajlI1n 50Yah2q0nCAz9rzaSul+1xrvfKXKoISomkz79T93tX/QkGN13umm1TvITmLVMAvBrTib dq/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710982643; x=1711587443; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NcCCsNAwR8Dc7lzDCsU4frbON1Nxj0gXvdgfk6i+yq0=; b=pkSNLq65IJoQ83MqCxE4bjhQipmr+yWmsgENEPdcwzCcnTZAHjMdgFKAXpWWVf1Lcm OBleN0mcYt9h9roBiVSdx9OfZCAgghhAcwXbsMycU0iTslgdXD+iC6yADnbUyZ6BvAZy zhLMerL5kVtCq14vu/hcMLXUQWLLmHf66EpvmcoKZ+pl150SsoovNj1gcBjGRMxSFovR uy6CFt71p5Kh+axtaFW7wOxGy97s65LXgMJBLS1L7IVxG1ESQcEs3W043CmzLIR6IFfA j5XM5jLEkwxPYGIc6cCk646c6U0IK1rlEO2ymSknpseupVwP3jE8KeHWy80zo19PoMtj b9Yg==
X-Forwarded-Encrypted: i=1; AJvYcCVFCawySGgu/o1zUPz/Wdyed1VTzCxrCaatDFAMmHXirwFwFqLiwT+fBdgqyyQrINFqP9UvoM7KzqfqsUb6
X-Gm-Message-State: AOJu0YwILpdZdRDOKZJSYjKYjX1dmFZYcy2sFQ79tVJLfU6R5jzgZf9k Qp8IGtdkzLAibuWKAVHbb+jNU7PolodS3gkJe7HmTXEccgrBx9WAZh7HPDgMuUF5S0UusYQKtKr in1RlblUH+Ig6b7Z9Z/Og1T37cEy2FlbrD6ktXQ==
X-Google-Smtp-Source: AGHT+IElNuDxzre/D8h5xXhJIaZuV+GVA1XA5Es6h+13lSKK/qinBBh+1WozwKE0PS/pltFbyXIjDm/ZNFl6pvIufh0=
X-Received: by 2002:a05:6402:388b:b0:568:a727:8867 with SMTP id fd11-20020a056402388b00b00568a7278867mr2460996edb.12.1710982643145; Wed, 20 Mar 2024 17:57:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAN3x4QkK6dFnoo0wfyCBf9_beuQf+Og9+EhoeYvMUbFaoGw8zw@mail.gmail.com> <7EB59D53-7CC4-4AD3-9652-56EA622D25EE@gmail.com> <CAN3x4QkrPT69=HMqB0cRVb6kocCQ3W0C+L1fXT1zN9dCPtaMUg@mail.gmail.com>
In-Reply-To: <CAN3x4QkrPT69=HMqB0cRVb6kocCQ3W0C+L1fXT1zN9dCPtaMUg@mail.gmail.com>
From: Amir Omidi <amir@aaomidi.com>
Date: Wed, 20 Mar 2024 20:57:11 -0400
Message-ID: <CAOG=JUJ9HGAOPVed1i09gsoPc+8qqk4T3sJVD7n_ZLP28deErA@mail.gmail.com>
To: Jacob Hoffman-Andrews <jsha=40letsencrypt.org@dmarc.ietf.org>
Cc: Seo Suchan <tjtncks@gmail.com>, acme@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a97ffb0614213078"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/YpzHlNilM_9SR1eKBA-pEHuF0Qw>
Subject: Re: [Acme] scope in dns-account-01 and dns-02 challenge
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: Thu, 21 Mar 2024 00:57:48 -0000
I do think that this draft can do a better job describing the scope. I think we should make it more explicit for the client to understand which one will be used. I feel like splitting this challenge into three (and potentially more, as extra scopes may or may not be added into the future) might be a little too noisy. What do you think about a `scope` field in the authorization resource the server sends creates/communicates with the client? Clients opting into dns02, or dns-account-01 will use this to know exactly what scope the server is expecting from them for their ACME order. { "status": "valid", "expires": "2015-03-01T14:09:07.99Z", "identifier": { "type": "dns", "value": "www.example.org" }, "challenges": [ { "url": "https://example.com/acme/chall/prV_B7yEyA4", "type": "http-01", "status": "valid", "token": "DGyRejmCefe7v4NfDGDKfA", "validated": "2014-12-01T12:05:58.16Z" } ], "scope": "host" // Or "wildcard", or "host" } This wouldn't remove the existing wildcard or subdomainAuthAllowed fields. On Tue, Mar 19, 2024 at 7:36 PM Jacob Hoffman-Andrews <jsha= 40letsencrypt.org@dmarc.ietf.org> wrote: > Seo Suchan said: > > Would it be illegal to server probe both scope and pass if there is > intended token? > > This is a possibility, but it's inefficient and I think it's likely to > lead to implementation bugs. Better to be clear and explicit on both sides. > > Amir Omidi said: > > My intention that I should probably clarify in the draft is that the > server picks based on the Authorization object > > Yep, I figured the intention was something like this. We could call this > "Server and client follow the same algorithm to arrive at the same scope." > Also a valid approach! But I think we get benefits from not having that > algorithm, even as simple as it is. For instance, the BRs say of some > methods: > > > Once the FQDN has been validated using this method, the CA MAY also > issue Certificates for other FQDNs that end with all the Domain Labels of > the validated FQDN. This method is suitable for validating Wildcard Domain > Names. > > If host-scoped, wildcard-scoped, and domain-scoped challenges were > separate types, it would be straightforward to adapt this language to the > new challenge types. > > Ilaria Ilusvaara said: > > The client also needs to know the acceptable domains, and needs to > select the domain to use. > > The domain to use is part of the authorization object: the identifier > value (https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.4). It > is chosen by the server. > > I think what you're getting at is that the client might feel like "I > requested a new-order for www.example.com, and the server created an > authorization object with an identifier value of www.example.com. But I > really wish the server would have created an authorization object with an > identifier value of example.com, and I would complete domain-scoped DNS > challenge." This would allow the full expressiveness permitted by BRs > 3.2.2.4.7 DNS Change, which has the "MAY also issue Certificates for other > FQDNs that end with all the Domain Labels of the validated FQDN" language. > > I'd actually like to go the other direction: What if we only specify > host-scoped and wildcard-scoped validations? Domain-scoped validations make > sense when validations are very manual and time consuming, and you are > trying to strictly minimize them. But ACME tries to make validations easy > and quick, so it doesn't matter if you have to do more of them. There are > still important use case for wildcard certificates, but I think there is > less need for domain-scoped validations in ACME. > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
- Re: [Acme] scope in dns-account-01 and dns-02 cha… Seo Suchan
- [Acme] scope in dns-account-01 and dns-02 challen… Jacob Hoffman-Andrews
- Re: [Acme] scope in dns-account-01 and dns-02 cha… Amir Omidi
- Re: [Acme] scope in dns-account-01 and dns-02 cha… Ilari Liusvaara
- Re: [Acme] scope in dns-account-01 and dns-02 cha… Jacob Hoffman-Andrews
- Re: [Acme] scope in dns-account-01 and dns-02 cha… Amir Omidi
- Re: [Acme] scope in dns-account-01 and dns-02 cha… Ilari Liusvaara
- Re: [Acme] scope in dns-account-01 and dns-02 cha… Jacob Hoffman-Andrews
- Re: [Acme] scope in dns-account-01 and dns-02 cha… Amir Omidi
- Re: [Acme] scope in dns-account-01 and dns-02 cha… Jacob Hoffman-Andrews
- Re: [Acme] scope in dns-account-01 and dns-02 cha… Ilari Liusvaara