Re: [Acme] Optional "Wildcard" authorization field
Daniel McCarney <cpu@letsencrypt.org> Fri, 02 March 2018 21:58 UTC
Return-Path: <dmccarney@letsencrypt.org>
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 B9F49124239 for <acme@ietfa.amsl.com>; Fri, 2 Mar 2018 13:58:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aygCMmWtDlmI for <acme@ietfa.amsl.com>; Fri, 2 Mar 2018 13:58:19 -0800 (PST)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 6E88712025C for <acme@ietf.org>; Fri, 2 Mar 2018 13:58:19 -0800 (PST)
Received: by mail-io0-x22f.google.com with SMTP id 30so12136996iog.2 for <acme@ietf.org>; Fri, 02 Mar 2018 13:58:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yuqOgn9TddWhQX/yQNVAvjwk+S6dOHrcU/ovBBB3qrw=; b=SiSud2duOtAynIcaNtcF16vUNcKz4ItYuNMpR+Ad/ebGdeAi7Pi/J6P3LMccXrgHV4 qUEEiu0g0fijAIHmthgeRdGtHbhSV7MaNdz0wxhKqa9c5Od51xUfAlxGGdYcMj2Vq7Xx CD1PKH0USrlrwec4rQwpLnL6aF1uQAUf0ogx8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=yuqOgn9TddWhQX/yQNVAvjwk+S6dOHrcU/ovBBB3qrw=; b=lIjZmdT4WHa8Zm1wysq3P6hd1DXV/c/3hE3IOezETdWLrymV+RuKkD4zJOOvewgxVq VccTXG4yi9m4pL38rReu2WrzDDdGBneokJxsdEPisVT4fCT515iPLoTMUUlkBf0jCu/l MO8pn6noDq+qhosfZmTM/qwfI7F95oilIgqglaP9Cm08LxxiOF4Y7UC095R6T/4cetlQ EWCFHSh9epURLHWlZHotKneM3ubdAmBDCeX3YgjxBVA4T7Yv/b8FAu8OM5eoiYbBxlQ/ 158a7OwrlPiivmA/ryzOl7cWAyxyVMlK2EsgJpPbGlaVIUBJKVnFX/m64QQIs/N5jHCK xriQ==
X-Gm-Message-State: APf1xPDrSAUYsbZOq+OofkFims0jx0PdN5RnJ5sxWJYO04EP8p07JMUm +uSOjq0BD32Ye9MiUoDMAWheiOadq7WJeOgsp4g8ig==
X-Google-Smtp-Source: AG47ELs0ULVmVyTlbENmD2+v/lstaNJe5iwtO8blu/yeO0yARMstw58lDM+4R7Z+neyRORpGNwIA6n5R5jFwIvxykag=
X-Received: by 10.107.137.142 with SMTP id t14mr8232375ioi.230.1520027898728; Fri, 02 Mar 2018 13:58:18 -0800 (PST)
MIME-Version: 1.0
Reply-To: cpu@letsencrypt.org
Received: by 10.107.21.2 with HTTP; Fri, 2 Mar 2018 13:58:17 -0800 (PST)
In-Reply-To: <09d9ab58-2b1b-5515-8313-128705e86437@hemio.de>
References: <CAKnbcLjuVPZa5P2FZa_cKAGmk1dP6ezrv3AgWSp9KK5HCzxPbg@mail.gmail.com> <CAL02cgQwZzKXvPsWr=tAbB-bi2s-gw3+TtJwkawHoEEb=6MiFw@mail.gmail.com> <CAKnbcLiQdjaPN32j8WOo5vhvfoTvHPYZj5pictb47ZTWvmJXYA@mail.gmail.com> <09d9ab58-2b1b-5515-8313-128705e86437@hemio.de>
From: Daniel McCarney <cpu@letsencrypt.org>
Date: Fri, 02 Mar 2018 16:58:17 -0500
Message-ID: <CAKnbcLgbviD_-2bsXUuZfsg+2gQCtieXkj0wHRFk8ovUNGEBtw@mail.gmail.com>
To: Sophie Herold <sophie_herold@hemio.de>
Cc: IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f8f2cf3e9510566751263"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/Ewvl0KuopKZfBEs2HVM_UpWwZRk>
Subject: Re: [Acme] Optional "Wildcard" authorization field
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 02 Mar 2018 21:58:22 -0000
> > This sounds like you want to provide the order identifiers that > triggered this authorization within the authorization object? Generally speaking yes. In principle, several order identifiers could lead to a single > authorization I guess? > I think in principle that's true. ACME doesn't prescribe that there be a single authorization per-identifier. Perhaps Wildcards are just the most immediate case of there being a disconnect between the order identifiers and the authorizations. I was thinking only of identifier value but you're right that there may be a disconnect in the quantity of order authorizations compared to requested identifiers. It would be helpful if a CA with intentions to implement an issuance policy that differs from "n order identifiers, n authorizations" would speak up. I'm partial to the optional bool field because its very simple. Your proposal is more robust but also a bigger change and I'd like to know someone in the real world will benefit from the work involved :-) - Daniel / cpu On Fri, Mar 2, 2018 at 3:46 PM, Sophie Herold <sophie_herold@hemio.de> wrote: > On 02/03/18 18:32, Daniel McCarney wrote: > > Richard: That's up to the client and the situation. In the linked Certbot > > issues there were questions about error output/UX. In this case if the > > client saw an error attached to an authorization with the identifier `{ > > "type": "dns", "value": "example.com"}` and the authorization had > > `wildcard: true` the client could say "Failed to authorize *.example.com > : > > blah blah blah" or otherwise use the knowledge to inform their actions > > (whatever they may be). > > This sounds like you want to provide the order identifiers that > triggered this authorization within the authorization object? > > I think, in general it is just a guess that exmaple.com + wildcard means > that the order contains *.example.com. This depends on which > authorizations are created for which order identifiers, which is not > specified by acme. > > In principle, several order identifiers could lead to a single > authorization I guess? For example, if sub1.example.org and > sub2.example.org lead to just an example.org authorization. Therefore > "orderIdentifiers", as I call it here, needs to be a list: > > { > "status": "valid", > "expires": "2015-03-01T14:09:00Z", > > "identifier": { > "type": "dns", > "value": "example.org" > }, > > "orderIdentifiers": [ > { > "type": "dns", > "value": "*.example.org" > } > ], > > "challenges": [ > … > > Best, > Sophie > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
- [Acme] Optional "Wildcard" authorization field Daniel McCarney
- Re: [Acme] Optional "Wildcard" authorization field Richard Barnes
- Re: [Acme] Optional "Wildcard" authorization field Daniel McCarney
- Re: [Acme] Optional "Wildcard" authorization field Felipe Gasper
- Re: [Acme] Optional "Wildcard" authorization field Richard Körber
- Re: [Acme] Optional "Wildcard" authorization field Richard Körber
- Re: [Acme] Optional "Wildcard" authorization field Brad Warren
- Re: [Acme] Optional "Wildcard" authorization field Sophie Herold
- Re: [Acme] Optional "Wildcard" authorization field Daniel McCarney
- Re: [Acme] Optional "Wildcard" authorization field Richard Barnes
- Re: [Acme] Optional "Wildcard" authorization field Daniel McCarney