IETF Logo Mail Archive

Re: [Acme] Comment on draft-ietf-acme-subdomains-06: How about using wildcard certificates for subdomains?

Deb Cooley <debcooley1@gmail.com> Sat, 04 February 2023 13:31 UTC

Return-Path: <debcooley1@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 E983AC14CE2B for <acme@ietfa.amsl.com>; Sat, 4 Feb 2023 05:31:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.843
X-Spam-Level:
X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMtkiLlF6egz for <acme@ietfa.amsl.com>; Sat, 4 Feb 2023 05:31:43 -0800 (PST)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236CEC14F737 for <acme@ietf.org>; Sat, 4 Feb 2023 05:31:43 -0800 (PST)
Received: by mail-ej1-x633.google.com with SMTP id dr8so22430265ejc.12 for <acme@ietf.org>; Sat, 04 Feb 2023 05:31:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=J0XJgfqE2b4+RAOBtS7yicBcFtzN+yuWMX8b06dpevs=; b=aRHR9OuzlKwFFkXg85UxvH082aojcCI1E0zemr+e187AYLzQMFtuDINF++WOvfPTHF NB34v6qJ9xAuGmoBxgI54vVQXFm7WQ34uP0OuDYoZJjDgG5Xlmole+ag2RsWpZg0hlwi YsU1P5GkOfhLz3hdI2tb+zlPUqcnfAF9/thVsZxSWqSN5oQZm6Ejwp5q8NebDSGY2R4x e7LYogjnOEGJPlkTqMJ5tslImur4IWd8Xd5nw5oyYJC8H3ijclOTLWOyWMyVdelmso+f tDSrO/k6Olp+TD9d8eMjyxFXi9ac5IvrKdyDCNSLuOUHej95WgywuxAuMQ+1SMLlcsa9 5yfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=J0XJgfqE2b4+RAOBtS7yicBcFtzN+yuWMX8b06dpevs=; b=cuTB+cYJCMWTfLryXYj2HZSI+ZKBPJrgVij/XuDiDlwJCIViEb/zBlwF8RqxODqf2W 1M7xOhfkzwxSNuy7LjMgz23R/lih7A1L0Fmu3KDOhiYfK5R2cfjxyGKMH/+GJogxf6aK Mrmd3ZaOq2hedGF0An+FipZtW6ZSsOGEWg4am6EvmHD1bmx+JUfRzkHVuE8uhMM+StGj Z+IGy85znrTKsXPW1Ein+B61i8WFfmdrTJT1YvPLzZ3gKgyGWM9ll0ICpFu3tKshcGxe h8USnx4sxXQsu1QEhAVaZWZnvM9jHSBCMVtomQEOGz5sth0738AO5JxHt5VUSHRAwITF 1KCg==
X-Gm-Message-State: AO0yUKWm/ZuDEPJ3NRMvhCvlNcNI9P73TxNFa13g8uExHOrVyNHFayzW NBVMUEX0UNeRK3fuqX8UDDumLrCB2LeC7zTobS+PO/U=
X-Google-Smtp-Source: AK7set8TkXXlTEAY492c11Dhd8iH+RpBNGZfVZj7B0Sy9snuWFiC+U9BerftUlEpdhtlMjBwwfRVh/QWJOJfbSNM+5w=
X-Received: by 2002:a17:906:60d1:b0:878:54d2:1080 with SMTP id f17-20020a17090660d100b0087854d21080mr3279645ejk.98.1675517501568; Sat, 04 Feb 2023 05:31:41 -0800 (PST)
MIME-Version: 1.0
References: <34218eee7c3a49d5bb1f2d1afb657ed3@huawei.com>
In-Reply-To: <34218eee7c3a49d5bb1f2d1afb657ed3@huawei.com>
From: Deb Cooley <debcooley1@gmail.com>
Date: Sat, 04 Feb 2023 08:31:31 -0500
Message-ID: <CAGgd1OdOAA40GxvnNfTX1VRR3JoTFkA8jbYvBmmWSZjgY++VBQ@mail.gmail.com>
To: "Yanlei(Ray)" <ray.yanlei=40huawei.com@dmarc.ietf.org>, "acme@ietf.org" <acme@ietf.org>
Cc: Dorothy E Cooley <decoole@radium.ncsc.mil>
Content-Type: multipart/alternative; boundary="0000000000007efa1a05f3dfd16d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/Ycp4exKlYeRiP4aGHJRYZHX3Qrk>
Subject: Re: [Acme] Comment on draft-ietf-acme-subdomains-06: How about using wildcard certificates for subdomains?
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 04 Feb 2023 13:31:44 -0000

RFC8555 already addresses wildcards, no?

Deb Cooley
ACME chair
decoole@radium.ncsc.mil


On Tue, Jan 31, 2023 at 7:11 AM Yanlei(Ray) <ray.yanlei=
40huawei.com@dmarc.ietf.org> wrote:

> Hi，
>
>
>
> I'm new to this group and sorry for the late comment. I just saw this
> draft and have an idea after reading. I'd like to know from you experts
> whether it's reasonable.
>
>
>
> The illustration in Section 5 uses Subject Alternative Name (SAN) to list
> every subdomain name in a certificate.
>
> I wonder if this mechanism can be replaced by using a wildcard certificate?
>
> Compared with using the Subject Alternative Name (SAN), a wildcard
> certificate can simplify the complexity and reduce the costs for securing a
> number of subdomains.
>
> As the sub-domain name changes, the client with SAN has to re-apply its
> certificate, but the client with wildcard certificate does not need to
> change its certificate.
>
> I think wildcard certificates have been commonly used in subdomains
> management.
>
> As illustrated in Section 5:
>
>   +--------+                  +------+     +-----+
>
>   | Client |                  | ACME |     | DNS |
>
>   +---+----+                  +---+--+     +--+--+
>
>       |                            |            |
>
>     STEP 1: Pre-Authorization of ancestor domain
>
>       |               .            |            |
>
>       |               .            |            |
>
>       |               .            |            |
>
>     STEP 2: Place order for sub1.example.org
>
>       |               .            |            |
>
>       |               .            |            |
>
>       |               .            |            |
>
>     STEP 3: Place order for sub2.example.org.
>
>       |               .            |            |
>
>       |               .            |            |
>
>       |               .            |            |
>
>
>
> If there are multiple subdomains, the client has to place an order
> multiple times for every subdomain.
>
> If using a wildcard certificate, the client only needs to place an order
> once for the wildcard certificate.
>
> Then the client can configure its subdomain servers with the same wildcard
> certificate.
>
>   +--------+                  +------+     +-----+
>
>   | Client |                  | ACME |     | DNS |
>
>   +---+----+                  +---+--+     +--+--+
>
>       |                            |            |
>
>     STEP 1: Pre-Authorization of ancestor domain
>
>       |               .            |            |
>
>       |               .            |            |
>
>       |               .            |            |
>
>     STEP 2: Place order for *.example.org    |
>
>       |                            |            |
>
>
>
>
>
> This is just a preliminary idea, and please correct me if I'm thinking
> wrongly.
>
>
>
> Regards,
>
> Lei YAN
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>

v2.23.0 | Report a Bug | By Email