Re: [Acme] CAA in draft-ietf-acme-client-01.txt

Ben Schwartz <bemasc@google.com> Tue, 28 July 2020 20:12 UTC

Return-Path: <bemasc@google.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 E7D533A0BF1 for <acme@ietfa.amsl.com>; Tue, 28 Jul 2020 13:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 9MPEjHpEIgwl for <acme@ietfa.amsl.com>; Tue, 28 Jul 2020 13:12:28 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 618993A0B58 for <acme@ietf.org>; Tue, 28 Jul 2020 13:12:27 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id f18so715957wmc.0 for <acme@ietf.org>; Tue, 28 Jul 2020 13:12:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0NiMqPls7RUiUHnFfx8Yvi8pIv6FQGs6tnAzyk/BXeA=; b=IHA0tyVxRfY7GD7gMuHMWG+46wVa1r+P+n2GAC14X3QNViDvHU4Y7V8/gw57WBNqsw DGsYB2bmrTj8660MvPw3bImCbsFD+Plpn83BtbK6TZIb15KNDU9V9d7E3ywE/V4zjzgy +xvS0aOC5RK0ubsAVKEhn/xej2c3JA8fqaBxu1Fb8teRnbhQPYn7AQwqGcXqcoHbQwxz TQ5Cg20m6Sq3bXKappiyeD4YFDpSRuRTG2/1uDJYNTj3SL5kKOj1pU/RVFloYb53nRJS fIbeSsti11uPN4Y2VCEPAoVkP14vA8/yXKNUH8BLeYgAMEZU+XUKWymYydVj2tjbSDOx 2c8g==
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=0NiMqPls7RUiUHnFfx8Yvi8pIv6FQGs6tnAzyk/BXeA=; b=mLplXlFTlNKhGnZng3HzHHhiFzTSZI6LtuR7GKINq3Ym19iJEIYwe+1YA4TKazpltm N4ooq3bqdoEYelGkuJqFd4Dvr9nukDfygCPi7TrUJpnp9NWH0xfxXFzlHR5TnGZ7mqtf H8BhGAn2jVXua5k7zRKoJGzP86XEj3IAhFsxFcieU/+RgBZYThy/Wx4QYxPrITR7vjvS hOonIOdwMzdSkYjEJsIxCbUSg7ozxgE9cnV50M4EGfRp2xhygUIMMQdOqvXeAuA1tjd0 fsaXM7vuZyPJHfThjaxUx1TPcaFBPlNYoMRHTKP96wrpZo2LQaVm5sATaYvujXTwuYWt 7SDw==
X-Gm-Message-State: AOAM530wRiM23EZtFiPMdvlgHGHAHSyJB7AaquVuaSVz2UFFvVWPHRON Aq44I2pIZibcz6r7mqHHzx13xC1IJ2rUNsJhjpqUeg==
X-Google-Smtp-Source: ABdhPJwF1ztU0a/IOYDSQ34t1ic9opW29c5EaeebP2s0Gn+T2lE9Xxx3C4vS0xjLK+jd41TvYeGu6jEReu331iLAuY0=
X-Received: by 2002:a1c:a757:: with SMTP id q84mr5257053wme.1.1595967145597; Tue, 28 Jul 2020 13:12:25 -0700 (PDT)
MIME-Version: 1.0
References: <158981033392.26980.4468928473194139329@ietfa.amsl.com> <CAEa9xj4x16PYeX9jcBxdPmR08AkOEN6jZ5RfxQKQy0xgT-4CCw@mail.gmail.com> <CAHbuEH6Q8cPaFYwv_v-74z2JEZY5fqF3VmkVLOn+OdJCEmZhfw@mail.gmail.com> <CAF1ySfELcy=V9UJqkY8TLNF-mdk05owp5TSJ3xHTaXQaUgKdfg@mail.gmail.com> <9e2db5c2011348d280e3b00074f12ea8@x13pwhopdag1404.AMER.DELL.COM>
In-Reply-To: <9e2db5c2011348d280e3b00074f12ea8@x13pwhopdag1404.AMER.DELL.COM>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 28 Jul 2020 16:12:14 -0400
Message-ID: <CAHbrMsCvnr+aDnC0zWpS6hnEh0ZB96Sy+wsSrV5Ueha=PntoOA@mail.gmail.com>
To: Kathleen.Moriarty@dell.com
Cc: Roland Bracewell Shoemaker <roland@letsencrypt.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, c@cem.me, acme@ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000d0b5e605ab860e54"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/uLPm0mMExTSLEH57YLS1jfrKEFg>
Subject: Re: [Acme] CAA in draft-ietf-acme-client-01.txt
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, 28 Jul 2020 20:12:31 -0000

RFC 6844 Section 4.1 points out that logged DNSSEC-signed CAA records can
be used when auditing CAs for mis-issuance.  The current draft says "CAA
helps as anyone ... can verify that the CA used has been authorized", which
is true, but only if "anyone" has access to a log of the signed CAA records
used by the CA, and the domain is DNSSEC-signed.

I would like it if CAs published such logs, but I don't know whether it is
a common practice.

On Tue, Jul 28, 2020 at 3:58 PM <Kathleen.Moriarty@dell.com> wrote:

> Roland,
>
>
>
> Thank you, that’s very helpful  Any other opinions?  I’m very happy to
> delete with consensus and appreciate the reviews on this particular issue
> as well as on the draft.
>
>
>
> Best regards,
>
> Kathleen
>
>
>
> *From:* Roland Shoemaker <roland@letsencrypt.org>
> *Sent:* Tuesday, July 28, 2020 3:27 PM
> *To:* Kathleen Moriarty
> *Cc:* Carl Mehner; Moriarty, Kathleen; IETF ACME
> *Subject:* Re: [Acme] CAA in draft-ietf-acme-client-01.txt
>
>
>
> [EXTERNAL EMAIL]
>
> I think the disconnect here is between CAs and Relying Applications (i.e.
> browsers) using CAA. The CA should use CAA to validate if they have
> authority to issue, but the relying application must not because the CAA
> records are only applicable at the time of issuance and there is no
> guarantee that the current CAA records may match the records that were
> present in the past (i.e. I may set my CAA record to allow "example-ca",
> issue a certificate, and then set my CAA record to an empty string to
> prevent issuance from anyone, the check is valid at the time of issuance,
> but anyone trying to do post-issuance validation would fail since the
> record has changed).
>
>
>
> I would support removing the paragraph.
>
>
>
> On Tue, Jul 28, 2020 at 7:57 AM Kathleen Moriarty <
> kathleen.moriarty.ietf@gmail.com> wrote:
>
> Hello Carl,
>
>
>
> Thank you for your review and I apologize for my extremely tardy response.
>
>
>
> On Mon, May 18, 2020 at 11:41 AM Carl Mehner <c@cem.me> wrote:
>
> Looking at the latest draft for acme-client, I noticed that it mentions
> CAA:
>    CAA helps as anyone verifying a certificate used for code signing can
>    verify that the CA used has been authorized to issue certificates for
>    that organization.
>
> However, in the CAA RFC it states:
>    Relying Applications MUST
>    NOT use CAA records as part of certificate validation.
>
> I propose removing the statement in acme-client about CAA that is quoted
> above.
>
>
>
> I recall having gone through this conversation before to wind up where the
> draft is now.  RFC8555 has the following:
>
>       caaIdentities (optional, array of string):  The hostnames that the
>
>       ACME server recognizes as referring to itself for the purposes of
>
>       CAA record validation as defined in [RFC6844 <https://tools.ietf.org/html/rfc6844>].  Each string MUST
>
>       represent the same sequence of ASCII code points that the server
>
>       will expect to see as the "Issuer Domain Name" in a CAA issue or
>
>       issuewild property tag.  This allows clients to determine the
>
>       correct issuer domain name to use when configuring CAA records.
>
>  Section 9.7.8 has the following:
>
>    Validation methods do not have to be compatible with ACME in order to
>
>    be registered.  For example, a CA might wish to register a validation
>
>    method to support its use with the ACME extensions to CAA [ACME-CAA <https://tools.ietf.org/html/rfc8555#ref-ACME-CAA>].
>
>
>
> Section 11.2 has the following:
>
>    An ACME-based CA must only use a resolver if it trusts the resolver
>
>    and every component of the network route by which it is accessed.
>
>    Therefore, it is RECOMMENDED that ACME-based CAs operate their own
>
>    DNSSEC-validating resolvers within their trusted network and use
>
>    these resolvers both for CAA record lookups and all record lookups in
>
>        furtherance of a challenge scheme (A, AAAA, TXT, etc.).
>
>
>
> As you point out, https://tools.ietf.org/html/rfc6844, advises against
> its use.
>
>
>
> I am happy to edit to consensus.  If a change is needed, I can turn that
> around quickly.
>
>
>
> Best regards,
>
> Kathleen
>
>
>
> -carl mehner
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>