Re: [Acme] Final thoughts on draft-ietf-acme-acme-05

Alan Doherty <ietf@alandoherty.net> Sun, 12 March 2017 22:03 UTC

Return-Path: <ietf@alandoherty.net>
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 185E0129468 for <acme@ietfa.amsl.com>; Sun, 12 Mar 2017 15:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, SPF_HELO_PASS=-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 Gw4Ot9wWO61S for <acme@ietfa.amsl.com>; Sun, 12 Mar 2017 15:03:14 -0700 (PDT)
Received: from bigsvr.orionnetworks.ie (hosting.orionnetworks.ie [195.2.202.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4222812945F for <acme@ietf.org>; Sun, 12 Mar 2017 15:03:14 -0700 (PDT)
Received: from host249.freudenhaus.alandoherty.net ([193.120.128.249]:4193 helo=alans-p4.alandoherty.net) by bigsvr.orionnetworks.ie with esmtpsa(TLSv1:DHE-RSA-AES256-SHA:256) (auth-as tel1) (nexus 1.3.4.80.1) (envelope-from <ietf@alandoherty.net>) id 1cnBZz-0007x3-Vo ; Sun, 12 Mar 2017 22:03:09 +0000
X-AD-RPFS-HEAD: for info on below codes http://www.alandoherty.net/mailsystem/mail-tagging/
X-AD-RPFS-GOOD-0: AV-SCAN-PASS SA-SCORE--1.6 SA-BAR-(-)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sun, 12 Mar 2017 22:03:05 +0000
To: Jacob Hoffman-Andrews <jsha@eff.org>,Hugo Landau <hlandau@devever.net>, acme@ietf.org
From: Alan Doherty <ietf@alandoherty.net>
In-Reply-To: <d7330bf3-aaec-10e7-79ef-4785f1e4a99b@eff.org>
References: <20170208051557.GA1383@andover.lhh.devever.net> <d7330bf3-aaec-10e7-79ef-4785f1e4a99b@eff.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <E1cnBZz-0007x3-Vo@bigsvr.orionnetworks.ie>
X-VIRUS: NONE {no virus found, This is no guarentee}
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/w-auFlOcZbepiQ0TVzTXW_Nz9AA>
Subject: Re: [Acme] Final thoughts on draft-ietf-acme-acme-05
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 12 Mar 2017 22:03:16 -0000

i think to issue wildcards (with minimal issues for validation, but direct owner allow/dissalow)

some well-known-subdomain could be used

example

acme-wildcard-auth.parent.tld  must exist for *.parent.tld to be applied for 
or
acme-wildcard-CAuniquestring-auth.parent.tld

if you want to make it possible to pre allow 1 or more acme-CA(s) only

the ip it points to can then be used in http/tls-sni 
and dns-based auth obviously can use same (but requires no ip)

thus domains without this sub-domain cant (as by not creating it they do not wish to use acme to register wildcards)

as the domain would then require the admin of domain.tld to set it up in advance (but once)
for the use by an acme-client thats using http auth for example

(as this would match both real wildcards in dns, and those like myself wanting to use wildcards to cut down on oversize san certs where 90 sites are from 1 parent domain and the others are all unique (as it cuts the names in the san by 89 leaving room for more unique sites)


At 19:11 12/03/2017  Sunday, Jacob Hoffman-Andrews wrote:
>Thanks for the feedback, Hugo! And sorry I've taken so long to reply. I
>think most of your comments have been addressed in merged or active PRs.
>
>On 02/07/2017 09:15 PM, Hugo Landau wrote:
>> Finally, I may as well mention wildcard domains again. I don't really
>> get the aversion to standardizing this. I previously proposed that these
>> be validated by n verification requests from a server to
>> randomly-generated, unguessable labels substituting for a wildcard. This
>> adequately proves that a wildcard is actually configured and that the
>> service located by it is under account control. These would be blind;
>> the hostnames used for the requests wouldn't be shown in the
>> authorization or challenge objects, so the client wouldn't know what
>> names would be used until the verification request comes in. Arguably,
>> though, even this is overkill, and just creating authorization objects
>> for unblinded, randomly generated names substituting for the wildcard
>> would suffice. (In fact, as far as I can tell, nothing in the current
>> spec actually prohibits doing this.)
>>
>> There are real applications for wildcard domains. For example, the
>> ability to create unlimited numbers of secure origins has real value to
>> some classes of web application.
>Yep, I also think it would be nice to standardize wildcard issuance!
>Richard's introduction of the "new-order" flow was intended to make
>wildcard issuance at least possible, but there's still a big question
>mark about what authorizations a server *should* create. To some extent
>that is up to server policy, but I think it's worthwhile to recommend on
>option.
>
>Note that the CA/Browser Forum Ballot 169 validation rules indicated
>that validating the base domain is sufficient to issue a wildcard
>certificate, so we could just echo that. But my feeling of the group is
>that folks would like to define a standard way of validating wildcards
>that is better than that baseline.
>
>Also: I think wildcards are a big enough topic that it probably doesn't
>make sense to try and land any significant changes before the spec is
>finalized, but they would be a good follow-on spec.
>
>_______________________________________________
>Acme mailing list
>Acme@ietf.org
>https://www.ietf.org/mailman/listinfo/acme