[Acme] Optional "Wildcard" authorization field

Daniel McCarney <cpu@letsencrypt.org> Fri, 02 March 2018 17:22 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 C80DC12DA03 for <acme@ietfa.amsl.com>; Fri, 2 Mar 2018 09:22:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level:
X-Spam-Status: No, score=-2.44 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, 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 rt587h9CJlua for <acme@ietfa.amsl.com>; Fri, 2 Mar 2018 09:22:09 -0800 (PST)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 7692D12D940 for <acme@ietf.org>; Fri, 2 Mar 2018 09:22:09 -0800 (PST)
Received: by mail-io0-x22d.google.com with SMTP id u84so11335152iod.9 for <acme@ietf.org>; Fri, 02 Mar 2018 09:22:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:from:date:message-id:subject:to; bh=JWxmhImWaGdqFoJA5Tg7DSsZF/8SRBf/seS6hkgJRLs=; b=byJLFyQuVWPzKnRXVIroBY4XcMOK59LinkyVu8/I0vO+B2/FE33DDvXP9UCH6K2Ij+ ov8SOk+JJCNkHiE/Ll4T0HGl1IWqL4vJ0cBvocnaua+t2hDwpZupBhM4WomBmGv98PYx quSySxYRptIeo2zPReIO/LA9Ha9av4ABti738=
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:from:date:message-id :subject:to; bh=JWxmhImWaGdqFoJA5Tg7DSsZF/8SRBf/seS6hkgJRLs=; b=Ns8YBXLP+jXzZma1yqs0X4RQg682vFXlAwoMr4FmEPjYg6aDz/I5biKAs2hp6IjplB kum2sZpLju/Qdd/iUygZbyDKP2sOmAkyb1k9NROdHUwB3b4lWYqMCOp16ZoD5ONsCPHH TP7d4Du7m2CiLyLUuVVHH2OoHxtlOg5OMux1TOliUUmM4Ac6+d5mfJrvHc1SflFumLNc pTDJ6vSoFN5lse62Oy9cR5TfYmkdXF5xZeX3IaIZkU3LV+M53tATUYL8mNoEjzPgIgKX wuekwv4HugEH9r3EDjp+hdrPpndFxPeOlCTS/Cz4YeMRjGgsHPN1Orssgd+yEheG39+x dwGQ==
X-Gm-Message-State: APf1xPDBiYU8Vb6FgsAdoBD0KAKrtuBBUoAe2swpUuzHubqzPkdg0b7i wrrcewvOtlQ5gFV1KGlLap51xu6KaYu6EBYAvhGTSf5zPTM=
X-Google-Smtp-Source: AG47ELvgZ8Mx2KJYlm8whTtn0ruDUM8PBsqvAMsq5+Lm1zvo6337K0Ra+kLNuOovIcoIr5vfMjewjTI7L6qOdjGW+pY=
X-Received: by 10.107.155.197 with SMTP id d188mr7378058ioe.3.1520011328439; Fri, 02 Mar 2018 09:22:08 -0800 (PST)
MIME-Version: 1.0
Reply-To: cpu@letsencrypt.org
Received: by 10.107.21.2 with HTTP; Fri, 2 Mar 2018 09:22:07 -0800 (PST)
From: Daniel McCarney <cpu@letsencrypt.org>
Date: Fri, 02 Mar 2018 12:22:07 -0500
Message-ID: <CAKnbcLjuVPZa5P2FZa_cKAGmk1dP6ezrv3AgWSp9KK5HCzxPbg@mail.gmail.com>
To: IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="001a1140c8fe4960670566713766"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/uFw6U60KXruYohtPluVmW_kQFlE>
Subject: [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 17:22:11 -0000

Hi folks,

There is a slight disconnect with the current specification between
identifiers in newOrder/newAuthz requests and identifiers in authorization
objects. The former is allowed to include wildcard domains in the value of
DNS type identifiers while the latter is forbidden.

Let's Encrypt's implementation of ACME wildcard issuance guessed this might
lead to confusion and introduced a non-standardized "Wildcard" boolean
field in authorization objects. If true, then the identifier value in the
authorization identifier is known to be the base domain corresponding to a
wildcard identifier from the newOrder/newAuthz request.

I think it would be beneficial to the entire ecosystem if this optional
"wildcard" authz field could be standardized so I've sent a small PR:
https://github.com/ietf-wg-acme/acme/pull/402 Both Certbot and ACME4J have
independently bumped into this disconnect, which helps justify the need.

- Daniel / cpu