Re: [Acme] orders, authorizations, and identifiers (oh my)

Daniel McCarney <cpu@letsencrypt.org> Tue, 16 July 2019 13:28 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 EF4B0120458 for <acme@ietfa.amsl.com>; Tue, 16 Jul 2019 06:28:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 kJR6JhkYLHpz for <acme@ietfa.amsl.com>; Tue, 16 Jul 2019 06:28:38 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 97C9F120463 for <acme@ietf.org>; Tue, 16 Jul 2019 06:28:30 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id n9so21028016wru.0 for <acme@ietf.org>; Tue, 16 Jul 2019 06:28:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=ajmmcmm9Y8VlaUsCOT/gEeN5Yv1U6tXo2bAxVP6iVsU=; b=Rzhtv2gFM+TY2hZcxGZ7KO7xvWNAt8AxXMWQWyHXRVd0bxC5LgrIak3Qi/ma+CRBvD XLYK+vXogS4UkMY5XDT2EjPfHABTEWVyn2J8N/lug2l8EBf2fYq5hApLX5yz9vQNbZb4 iF4frFLyC8YeyR18OGlCOOP2yByT2rh3CK86U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=ajmmcmm9Y8VlaUsCOT/gEeN5Yv1U6tXo2bAxVP6iVsU=; b=tapG42j0SzxrnsO3BbI0cPGfmAMvrfzc+zpQUXLlUyMfTU+f/PPZslnabKI6w933Qq uxz/VjbJ6gm+gTicMu5NuFUdszu1awM6KmaJNExba0VMSC9r44A43K6zKcwkEPVW6F00 4Qo8kKLq2B6zhbqnAEEM53t72HcQrtjadnvIsuAoQfjWEFVWoVOBcmsObMPOOKtdPiJh 8ql1CUNS6MEB7bK62Uo23eRebpGPPzBt8BPwNMnxpMKkOAsEb6/H3+IuHrE6nF9G/gyd wx9+FnIehcPm/y+Kv3kAFUf68lfSlv0lslIbcQPmJchYz0om24bNZhfrMNn3AA4HL/0h lRrA==
X-Gm-Message-State: APjAAAXUvBrewcfPdw/yHkSJgqb6cOiGEgYM85rdcWaEXRAHVQwVkoi0 SErCRFttmMY0aamP+uhWZ2mmYnoViiqcIUMsd0w/Rp706SA=
X-Google-Smtp-Source: APXvYqwvosDszbL3SYvXj+pLmOeIHCD1icrGhUnpuRF3oYe7TVlCmWgeVjupVNWdPwtNkD9Me6o4KDvzqPzyZdNjlcY=
X-Received: by 2002:adf:f281:: with SMTP id k1mr188080wro.154.1563283709078; Tue, 16 Jul 2019 06:28:29 -0700 (PDT)
MIME-Version: 1.0
References: <21BBD7F5-8D80-4ACC-B51F-B362A39A5A93@felipegasper.com>
In-Reply-To: <21BBD7F5-8D80-4ACC-B51F-B362A39A5A93@felipegasper.com>
Reply-To: cpu@letsencrypt.org
From: Daniel McCarney <cpu@letsencrypt.org>
Date: Tue, 16 Jul 2019 09:28:18 -0400
Message-ID: <CAKnbcLiQ5+byqfTtf8WA7QPYLufc6TFb97dAFH0Tdc5XzJusZQ@mail.gmail.com>
To: Felipe Gasper <felipe@felipegasper.com>
Cc: IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000029cbef058dcc5a14"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/8N0DhiMAZ35ni2jEFnuqhpDrv6g>
Subject: Re: [Acme] orders, authorizations, and identifiers (oh my)
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: Tue, 16 Jul 2019 13:28:40 -0000

>
> So it would be reasonable for this order to contain a single authz … and
> would that authz’s identifier be just “example.com”, then? Thus that
> authz object would not reference “www”, even though it is that domain’s
> corresponding authz object? Or would a client be accountable for
> implementing a “best-match authz” lookup to determine which authz
> corresponds to a given domain?


Yes, I would expect the order's one authorization to have the identifier "
example.com".

I believe the confusion here is when you say "even though it is that
domain's corresponding authz object" and "Since the order requires
successful authz for both domains".

For the first part, as I understand there is no guaranteed correspondence
between any of the identifiers in the order request and the identifiers in
the returned authorizations. That's what the sentence you quoted on p26 is
meant to convey. The client shouldn't attempt to match authz's to requested
identifiers at all, it should just look at the identifiers in the
authorizations returned by the server and prove control of those
identifiers with the challenges available.

For the second part, the server decides what identifiers the client needs
to prove control of in order to authorize the overall order. It may not be
both identifiers in the requested order. It happens that Let's Encrypt
return orders with an authorization matching each requested identifier and
requires all to be validated but the returned authorizations and associated
challenges are entirely up to server policy.

Hope that helps,



On Mon, Jul 15, 2019 at 5:56 PM Felipe Gasper <felipe@felipegasper.com>
wrote:

> Hi all,
>
>         The new RFC (8555) states (on p26), for order objects, that a 1:1
> relationship may not exist between an order’s identifiers and its authzs.
>
>         Given that each authz object contains exactly 1 identifier, how
> would this play out for CAs that accept authz against a base domain as
> substitutive for authz on a subdomain?
>
>         Consider an order to the hypothetical “AwesomeSSL” CA for
> example.com and www.example.com. AwesomeSSL considers authz against “
> example.com” to implicitly demonstrate control over “www.example.com”.
> Since the order requires successful authz for both domains, and (for
> AwesomeSSL) authz for “example.com” suffices for both domains, having a
> separate authz against “www” is superfluous. So it would be reasonable for
> this order to contain a single authz … and would that authz’s identifier be
> just “example.com”, then? Thus that authz object would not reference
> “www”, even though it is that domain’s corresponding authz object? Or would
> a client be accountable for implementing a “best-match authz” lookup to
> determine which authz corresponds to a given domain?
>
>         Thank you!
>
> -Felipe Gasper
> Mississauga, Ontario
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>