Re: [Acme] Fwd: New Version Notification for draft-ietf-acme-star-delegation-01.txt

Yaron Sheffer <yaronf.ietf@gmail.com> Thu, 10 October 2019 09:22 UTC

Return-Path: <yaronf.ietf@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 9DDBE12002F for <acme@ietfa.amsl.com>; Thu, 10 Oct 2019 02:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agTg9FcU6Npl for <acme@ietfa.amsl.com>; Thu, 10 Oct 2019 02:22:45 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 3D9C11200B3 for <acme@ietf.org>; Thu, 10 Oct 2019 02:22:45 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id j18so6913285wrq.10 for <acme@ietf.org>; Thu, 10 Oct 2019 02:22:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=A2NYddt3AcrGaX/w6ZRhNt7s81WumVsvosqp5DQlC0A=; b=H3WrNmN5hFeh4/a1yEW8tlXoAuKbBVqyFT/yOnfsJcFqnHS0GZNWQRP6MfX5Zs6+Mp 8kPuWdsMA+2wftPoebOBH5J6ZeSTJoXzVeTOHIRYVahVFhRgvF/iT2e98bM2EdLNwdrm eiKAOQp3H/OBVAt1G50rDX5KQT0p9HdTewtUlZZ4BXIh/wGjHbOg++aH2cYhRALNyRFX kNbmegTGadxyeeJ8KBreJSHb5mnpC8glgOKETTXebWASgWruG7MU0oexGACDsfJ0T/k9 NDdzj9KP1p5gsJ/2sQvouxFCc4WB97h6YqQ4a1F3i0V1Zvit9qk2zhDZWFTK3F/XlTTb HTqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=A2NYddt3AcrGaX/w6ZRhNt7s81WumVsvosqp5DQlC0A=; b=bE6PEo6HJTOj9ILHPqMruNTW46Ks2HTA3lqB1xpUZh4G9Fi0fsBhxsMPLhLH1dwDQA RCaTxTaI9l2+EtNtdSExYAJY2CoDHs9wpEWaDpAGo7IlfzJ6B6VqXdYZ8pK8Vl6yQx3z b9lDoP1qnWM+IDmeU6c0zU9JaIIxaq2ny+2BkNQzhABDtfbFYjmU1lEBmcTFfOOQcRvR p1Kzub7KcstRcFHsj5Gq0F9Rj3VBPewWthfJKkJuCu5lvhKhz/iIlAZa6Fgx1RJJemSF vTZ9xITpS28A8cIJnN1EpzLuBpNt9VikEQRXpYem5C+s6RA6Ze+71Poq8A4TBmJx8TVO jEPQ==
X-Gm-Message-State: APjAAAUsJ9H3+Ar9CQDXJTkS6oG8BjPrYYmkjrS4tabMdNWr54qSrf4U bqhFJMIC3L+Lb/tfmy+6W78=
X-Google-Smtp-Source: APXvYqzzXyDB2290dtllzVGinCyB9MC37dmLjyy1Cs+KkpZOMV6Ttx5K7GPAGzzCe/D3R+m2AgqnkQ==
X-Received: by 2002:adf:e9c8:: with SMTP id l8mr3253098wrn.270.1570699363774; Thu, 10 Oct 2019 02:22:43 -0700 (PDT)
Received: from [172.28.128.115] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id f20sm3857407wmb.6.2019.10.10.02.22.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Oct 2019 02:22:43 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/10.1d.0.190908
Date: Thu, 10 Oct 2019 12:22:41 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: Thomas Fossati <Thomas.Fossati@arm.com>, Ryan Sleevi <ryan-ietf@sleevi.com>
CC: "acme@ietf.org" <acme@ietf.org>
Message-ID: <AFD56CB0-0001-4FDC-9D2B-25A127E27BB8@gmail.com>
Thread-Topic: [Acme] Fwd: New Version Notification for draft-ietf-acme-star-delegation-01.txt
References: <156688663499.2633.13348873823926960427.idtracker@ietfa.amsl.com> <0d62ec19-399c-94e7-a44a-098ccf99bc7e@gmail.com> <CAErg=HFekDDOu0SPe171NJuXpCDUkiyV7_9bQMDz1GquXPoUiA@mail.gmail.com> <3FE5BE45-EB69-429E-A4DB-7B7838DC0AFE@arm.com>
In-Reply-To: <3FE5BE45-EB69-429E-A4DB-7B7838DC0AFE@arm.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/3BI3j882vnHRPgTXUaKS_f6Iy6w>
Subject: Re: [Acme] Fwd: New Version Notification for draft-ietf-acme-star-delegation-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: Thu, 10 Oct 2019 09:22:49 -0000

Hi Ryan,

Apologies for the very late reply. 

I accept your comments below, and we will reword this section as a recommendation or best practice. The flexibility of CAA means that the solution must be tailored to the particular CA(s) trusted by the IdO. This is unfortunate in the sense that we cannot recommend a one-size-fits-all security solution, and admins would need to have deeper understanding of the mechanisms they are using.

I am wondering though about this sentence: A CA can "also offer additional validation methods/issuance flows which also use the "dns-01" method." Doesn't specifying "dns-01" restrict the CA to one particular validation/authorization flow?

Thanks,
	Yaron

On 29/08/2019, 12:38, "Thomas Fossati" <Thomas.Fossati@arm.com> wrote:

    Hi Ryan,
    
    Thanks very much for the comments.  I'm going to address some of your
    points and let Yaron comment on the rest.
    
[snip]
    
    > 6.1 Restricting CDNs to the Delegation Mechanism There are RFC 2119
    > MUSTs attached here, when it seems these functionally should be
    > SHOULDs. That is, I think it's fair to highlight the consideration of
    > concerns between the IdO and the CDN, but I don't think it's
    > reasonable to normatively specify the policy consideration mechanism.
    > For example, as specified, those requirements would not be sufficient
    > to guarantee that a conforming CA uses this mechanism, as a number of
    > CAs "comply with ACME" (second bullet), but also offer additional
    > validation methods/issuance flows which also use the "dns-01" method.
    >
    > As CAA is intentionally flexible to allow for CA-specific policy
    > identifiers to be expressed between the IdO and the CA, I think it's
    > best to change these to SHOULD, and to recognize that CAs may devise
    > other means of technically expressing this conformance, and that's
    > between the IdO and the CA. CAA provides the necessary component (to
    > allow them to restrict to CAs that respect CAA, to allow CA-specific
    > policy), but I think that's the extent to which policy-specific
    > requirements can be made.