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 >
- [Acme] I-D Action: draft-ietf-acme-client-01.txt internet-drafts
- [Acme] CAA in draft-ietf-acme-client-01.txt Carl Mehner
- Re: [Acme] CAA in draft-ietf-acme-client-01.txt Kathleen Moriarty
- Re: [Acme] CAA in draft-ietf-acme-client-01.txt Roland Shoemaker
- Re: [Acme] CAA in draft-ietf-acme-client-01.txt Kathleen.Moriarty
- Re: [Acme] CAA in draft-ietf-acme-client-01.txt Ben Schwartz
- Re: [Acme] CAA in draft-ietf-acme-client-01.txt Ryan Sleevi
- Re: [Acme] CAA in draft-ietf-acme-client-01.txt Ben Schwartz
- Re: [Acme] CAA in draft-ietf-acme-client-01.txt Kathleen Moriarty