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
>