Re: [Acme] CAA in draft-ietf-acme-client-01.txt Tue, 28 July 2020 19:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D03033A0C5C for <>; Tue, 28 Jul 2020 12:57:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0pdlJ_Ui8A-J for <>; Tue, 28 Jul 2020 12:57:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E66823A0C29 for <>; Tue, 28 Jul 2020 12:57:25 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 06SJt69C030202 for <>; Tue, 28 Jul 2020 15:57:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=OmikWpQx029RKaBbhwkW3ngEdsJj4A+OBTL8uNj8wLI=; b=buTrhwS14/Y6RU2c5tQt6yhIqXn7VXyGpLLcvsZU6jOqyEvws718aYgrQNQH6wRzts0R y9KTLb1dB1qaecS2vHcv6bMtUdrhl3NZoyRUTJlVt0nyC8Chj4T9vycXo8t6Z/0wI5nI XWARIMh+x0FfN7In2/XeSTvmwgNMRswejXnEulL6CVbMxMwdQXURliQcVN2cdmLatZjz KfWO+aq7cgoBxLYgTGxYtC55cRp1WM5zyiBGdQ0nrHYtq/FJttcOTae9sEHUhD+bQByS JUtVNL+pXhRkhsWNbOho8qxr4GqsysfWKDm12hQEEcoCN5taUCBBvPGo/kYY+IL/KbPd RQ==
Received: from ( []) by with ESMTP id 32gfy7vum4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <>; Tue, 28 Jul 2020 15:57:25 -0400
Received: from pps.filterd ( []) by ( with SMTP id 06SJo98f110481 for <>; Tue, 28 Jul 2020 15:57:24 -0400
Received: from ( []) by with ESMTP id 32jt84gccq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <>; Tue, 28 Jul 2020 15:57:24 -0400
X-LoopCount0: from
X-PREM-Routing: D-Outbound
X-IronPort-AV: E=Sophos;i="5.60,349,1549951200"; d="scan'208,217";a="513346544"
Thread-Topic: [Acme] CAA in draft-ietf-acme-client-01.txt
Thread-Index: AQHWLSrHtM3ez/4FxU2HHqcQN3Oh3qkdx1eAgABLlID//8Ug8A==
Date: Tue, 28 Jul 2020 19:57:21 +0000
Message-ID: <9e2db5c2011348d280e3b00074f12ea8@x13pwhopdag1404.AMER.DELL.COM>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd;; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-07-28T19:57:20.9757106Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_ActionId=92b675b8-f01c-4183-a1b1-a2b648cb6814; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9e2db5c2011348d280e3b00074f12ea8x13pwhopdag1404AMERDELL_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-28_16:2020-07-28, 2020-07-28 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 mlxlogscore=998 lowpriorityscore=0 priorityscore=1501 suspectscore=0 bulkscore=0 impostorscore=0 phishscore=0 adultscore=0 mlxscore=0 clxscore=1011 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007280140
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 spamscore=0 mlxlogscore=999 adultscore=0 bulkscore=0 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007280140
Archived-At: <>
Subject: Re: [Acme] CAA in draft-ietf-acme-client-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Jul 2020 19:57:35 -0000


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,

From: Roland Shoemaker <>
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

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 <<>> 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 <<>> 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<>]  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<>]

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,, advises against its use.

I am happy to edit to consensus.  If a change is needed, I can turn that around quickly.

Best regards,

-carl mehner

Acme mailing list<>


Best regards,
Acme mailing list<>