Re: [Acme] acme subdomains open items

Ryan Sleevi <ryan-ietf@sleevi.com> Tue, 08 December 2020 22:15 UTC

Return-Path: <ryan.sleevi@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 BE88F3A123F for <acme@ietfa.amsl.com>; Tue, 8 Dec 2020 14:15:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 0Ck69XzeHT2D for <acme@ietfa.amsl.com>; Tue, 8 Dec 2020 14:15:51 -0800 (PST)
Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) (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 1E5873A1243 for <acme@ietf.org>; Tue, 8 Dec 2020 14:15:51 -0800 (PST)
Received: by mail-pf1-f176.google.com with SMTP id s21so15290986pfu.13 for <acme@ietf.org>; Tue, 08 Dec 2020 14:15:50 -0800 (PST)
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:from:date :message-id:subject:to:cc; bh=dVbEa0thA8r08dmWvLU6OXInddD2LmiZl5Ujr6bnZgI=; b=WXyI6TWtDaDHe/CIeSR2jqTbxvmh91SD9Pt9CqI41qyFBuoEt7ul8Qw3TCEUnRiwxT dhxn3V81rjyyRG51xxBOkc8tLjzDH3ZcFffCYSpwtpsIQY/ODkrZkD6E2Dn0KBkEib/g 4D4voYBFZfqx+RqF7FXb4rbq00TEjAeRT4gRXKH5Ex/3l9M4odT8UpYKSTurR9BjqI8a xIZuobBntzO9iAcSBlW7RBNQZvHiR1/IdB9FgqILmeRFLLXYQV7AlmCYuaU0wcKuffc1 8wk+xAW9C4wVVQppiOd3lAgAOdAiaSR7Br0GPgIRY0sxp0VHiZMTYjjPS5nnFpxk8WuF ayGQ==
X-Gm-Message-State: AOAM530GU2kiL4cSyyQTwJao3V+5dFlwtSPjxPGrY6eprbCDyXLuxTu7 uZckUxJxRrAepHjH3fXV5zYwkIQ9GZs=
X-Google-Smtp-Source: ABdhPJyB+dyFjLqz67oAMeGWkodJmU0r7NkGSkwh9GM7OKvjYHFQHptn3qKsVyABkhWPTLsJ36Vn9g==
X-Received: by 2002:a63:6f4c:: with SMTP id k73mr140800pgc.319.1607465750102; Tue, 08 Dec 2020 14:15:50 -0800 (PST)
Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com. [209.85.215.181]) by smtp.gmail.com with ESMTPSA id 22sm148225pfn.190.2020.12.08.14.15.49 for <acme@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Dec 2020 14:15:49 -0800 (PST)
Received: by mail-pg1-f181.google.com with SMTP id g18so13545575pgk.1 for <acme@ietf.org>; Tue, 08 Dec 2020 14:15:49 -0800 (PST)
X-Received: by 2002:a17:90b:1b52:: with SMTP id nv18mr6302981pjb.172.1607465749500; Tue, 08 Dec 2020 14:15:49 -0800 (PST)
MIME-Version: 1.0
References: <CY4PR11MB168504F6D4CF495E8AE8F729DBF10@CY4PR11MB1685.namprd11.prod.outlook.com> <CA7603D9-DFDA-4FA6-A76C-D4E0E638A956@felipegasper.com> <CY4PR11MB16851AD65ACF736CE6FD55A8DBF10@CY4PR11MB1685.namprd11.prod.outlook.com> <CAErg=HEON6756+_3Lfbe=r=3rxV9gAundvG5mBEEOzsKqL8x3w@mail.gmail.com> <CY4PR11MB168593FCC8F11DF836FD12EADBCE0@CY4PR11MB1685.namprd11.prod.outlook.com> <CAErg=HHxbhbZQAdf2SRjFVUezmkGcg+OdeZL_ey0AwubxkSVSA@mail.gmail.com> <16962.1607347826@localhost> <CAErg=HGM5bmm=oJ1ya8gC3EiW8KQJTq2N3fxisDsgSPYKd=DbQ@mail.gmail.com> <2310.1607463183@localhost>
In-Reply-To: <2310.1607463183@localhost>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Tue, 08 Dec 2020 17:15:38 -0500
X-Gmail-Original-Message-ID: <CAErg=HHOjdYAzCvx4vKkPAAMyEzJYqR_E-Ns=_a9pqeD8ny4eA@mail.gmail.com>
Message-ID: <CAErg=HHOjdYAzCvx4vKkPAAMyEzJYqR_E-Ns=_a9pqeD8ny4eA@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Ryan Sleevi <ryan-ietf@sleevi.com>, "Owen Friel (ofriel)" <ofriel@cisco.com>, Felipe Gasper <felipe@felipegasper.com>, "acme@ietf.org" <acme@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fcd9a305b5fb4813"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/oY9FfmGvoAdizEfYcfeDthVJwI4>
Subject: Re: [Acme] acme subdomains open items
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, 08 Dec 2020 22:15:53 -0000

On Tue, Dec 8, 2020 at 4:33 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
>     >> The client has control over lex.example, but and can prove it with
> dns-01
>     >> TXT
>     >> record placed at _acme-challenge.lex.example.  Why does it matter
> whether
>     >> it
>     >> is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example.
>     >> or an.other.comp.lex.example??
>
>
>     > The mistake you’ve made here is assuming the client has control over
>     > lex.example, and thus all subdomains. The point of all of this is
> that is
>     > an unrealistic assumption: the client may only have control over the
> DNS
>     > zone at so.me.comp.lex.example or they might have control at the
>     > me.comp.lex.example, but no control at comp.lex.example.
>
> I don't understand.
> If the client doesn't control lex.example, then why would it expect to get
> any kind of control of that?
> Same as without subdomains.
>

Alas, I'm equally at a loss to understand what you're asking here, as I
can't make much sense of your question?


>     > The existing approach with ACME assumes and expects that validation
> will be
>     > done at the FQDN (this is an oversimplification, but the nuance here
> isn’t
>     > as important).
>
> Yes, the FULLY-QUALIFIED.  Not the public name.
> dns-01 works just fine today for so.me.comp.lex.example.
>
> The client does not demonstrate control over lex.example using dns-01 when
> it
> asks for so.me.comp.lex.example.
>

Is that not literally what this draft is proposing (e.g.
https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.2 ) ?

In the pre-auth flow, the client affirmatively requests "lex.example" (In
the illustration here, "example.org"), in order to authorize
"so.me.comp.lex.example" (in the illustration here, "sub.example.org").
That is, the client explicitly declares their naming scope.

However, in the pre-auth flow, you have to know that the client will want
to be able to /newOrder for "sub.example.org" (as Step 2 in the
illustration), since you shouldn't return http-01 authorizations in Step 1
for this case.

For authorizations created in response to a request (i.e. the non-preauth
flow, which this draft explicitly states is allowed in 5.1), the CA has to
make a determination about what authorizations to issue, and the state to
track all of those pending authorizations created, which gets us back to
the discussion.

The significant majority of CAs, for the majority of certificates issued by
these CAs, totally rely upon authorizing "lex.example" in order to issue
certificates for "so.me.comp.lex.example" (whether using DNS-01, email, or
other). So I'm not sure what you mean by "does not demonstrate control".

Hopefully, this reply helps clarify, but if you still aren't sure, I'm
hoping you could be clearer on the uncertainty and I'll do my best to
rephrase.