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

Roland Shoemaker <> Tue, 28 July 2020 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5FCB3A0BA1 for <>; Tue, 28 Jul 2020 12:27:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iGdICukmcGUV for <>; Tue, 28 Jul 2020 12:27:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B27C3A0AB3 for <>; Tue, 28 Jul 2020 12:27:28 -0700 (PDT)
Received: by with SMTP id f18so19385833wrs.0 for <>; Tue, 28 Jul 2020 12:27:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D1uYFfJ9jGv+ukNFOVUYPZyrHtwO5n8D99pUmNSWO0k=; b=F9l7b6wSGeZMy+tf3XbwwdM7o2OxfReArNAvjhfzgnZg7XKGCLGmP6D4v6qyJoOPRF eqAVS/UjaB6m9epPDrj7pHSdR+PMiUTrttnrihlh63EoMM+K7a0X7Kfdj5Hv7HHJM6YH NBnwU9WCCikPWww1idnEnZd3tqlu9B1/aD+p0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D1uYFfJ9jGv+ukNFOVUYPZyrHtwO5n8D99pUmNSWO0k=; b=aOsvai+fyMN8UqUO9ICPTjcErj9WYr9fYNPP1T1g/qnISgkPvHhec7TikT2lWVP5ow D4Bn4ZFxWJgo1MP6fyXsHRub45vyPNwCk6GY6pR2fzcmGgSbBRcrP4OMeOpJNQ+nvCk8 JiydTE8ycyanlClonEXeqyXEJnCxGklsHE9z73EMxfD36yCBdtMEiH7Byl+AWug4seSq tjG7ZYzabAAerRKPS7I0Df5pyGEWDjycQcEOM+PGCW/kQ7SgJ16+aphn/Ty3QHo5EhyO t+Xf8/mvUg7EMsT615GFianImju94uFupNIH+kW4E3975zAqRc+jZhkrUs12EDTmXyAs LTBg==
X-Gm-Message-State: AOAM530sJwoNn2H4cdlu/mqXhQ5TPctW3N7Tn+vpmeJTLNN21BCP5OLz KUwerRN+FfWcJyaKKXHPaZv/XSNHN/hyQFxJ1aSCwQ==
X-Google-Smtp-Source: ABdhPJwBSiL0UY5FOt2Q4NrlOwWrBd0B1Lbk2/K5GpxRfxCB1XmwZgVEQxXujllKt0Ru/RnhJfD+Ed4bjyEtgZPSXZ0=
X-Received: by 2002:adf:f486:: with SMTP id l6mr21678365wro.265.1595964446639; Tue, 28 Jul 2020 12:27:26 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Roland Shoemaker <>
Date: Tue, 28 Jul 2020 12:27:15 -0700
Message-ID: <>
To: Kathleen Moriarty <>
Cc: Carl Mehner <>, "Moriarty, Kathleen" <>, IETF ACME <>
Content-Type: multipart/alternative; boundary="000000000000eaa13105ab856da6"
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:27:32 -0000

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,
> Kathleen
> -carl mehner
>> _______________________________________________
>> Acme mailing list
> --
> Best regards,
> Kathleen
> _______________________________________________
> Acme mailing list