Re: [Acme] AD Review: draft-ietf-acme-caa-05

Hugo Landau <hlandau@devever.net> Sat, 22 December 2018 16:28 UTC

Return-Path: <hlandau@devever.net>
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 C1AC012870E for <acme@ietfa.amsl.com>; Sat, 22 Dec 2018 08:28:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=devever.net
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 K1OsmxLDRqsH for <acme@ietfa.amsl.com>; Sat, 22 Dec 2018 08:28:20 -0800 (PST)
Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603AD127AC2 for <acme@ietf.org>; Sat, 22 Dec 2018 08:28:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 9D8571C591; Sat, 22 Dec 2018 17:28:16 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mimas; t=1545496096; x=1563685457; bh=kzl5U/hgaEGUwn6FHyCUVByew6/J/cScFdfMs5wW9zo=; b= WOJZMw8krK43/XBSpjEvPBQ6kBwWWcIXryz+4Aj25BPyPUL9JywhfNp+25qvUJ/7 8gsdQYf06sOnXcOFz3UyCKYVFYdbjZ8TYFlg4RRP4vbmceRP28eFjg2Ps2cimo1V n9cTrhbSJI0kH5rGRxhVLWJM/sKvGOzHHtyAUlogc+nmPPCGDVLHjlHdYB6q7fyv 6ubGZNzzBuU/HEUjgf8o/L2gwvPX1keYAI2f+qzd9Axwh/Oq8ZvQ80nkzaxLq6uv 4xS94UyGCrO4tb8Xrvn0G6c/eG6iz0AxcZnrEeIbKlhK8nJ6i3mkxk4PKRjWRron Jm2orfF5heigXvXRoqBnnA==
Received: from umbriel.devever.net ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id qiQ4rCRbO343; Sat, 22 Dec 2018 17:28:16 +0100 (CET)
Received: from axminster (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id 559371C585; Sat, 22 Dec 2018 17:28:16 +0100 (CET)
Date: Sat, 22 Dec 2018 16:28:16 +0000
From: Hugo Landau <hlandau@devever.net>
To: Eric Rescorla <ekr@rtfm.com>
Cc: acme@ietf.org
Message-ID: <20181222162816.GA23425@axminster>
References: <CABcZeBMoHaDGEgQXmM2qdGi=i0mXxPsuKdiq3jtAKTojVOAG_A@mail.gmail.com> <20181204022641.GA29286@axminster> <CABcZeBOBSWysCEJXJ+rD6mG4=QgMyuo77giNm5NuWJKrxZMK1Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBOBSWysCEJXJ+rD6mG4=QgMyuo77giNm5NuWJKrxZMK1Q@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/fMr6cY91LX41aA7tBYY3PaqmDnE>
Subject: Re: [Acme] AD Review: draft-ietf-acme-caa-05
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: Sat, 22 Dec 2018 16:28:24 -0000

> I'm open to alternative methods of preventing conflicts. A prefix could
> > be reserved for CA-specific use, e.g. "nonacme-".
> >
> 
> That would be fine.

Amended to:

  Where a CA supports both the "validationmethods" parameter and one or
  more non-ACME challenge methods, it MUST assign identifiers to those
  methods. If appropriate non-ACME identifiers are not present in the
  ACME Validation Methods IANA registry, the CA MUST use identifiers
  beginning with the string "nonacme-". Such identifiers have
  CA-specific meaning.

Attention should be drawn to the following text in the ACME I-D:

  When evaluating a request for an assignment in this registry, the designated
  expert should ensure that the method being registered has a clear,
  interoperable definition and does not overlap with existing validation methods.
  That is, it should not be possible for a client and server to follow the
  same set of actions to fulfill two different validation methods.

  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 in
  order to support its use with the ACME extensions to CAA
  {{?I-D.ietf-acme-caa}}.

Since this is a prefix and not an entry per se, it seems like the
cleanest way to accommodate this is to amend the ACME I-D, rather than
use of "IANA Considerations" section, which is currently nil. The ACME
I-D is already referencing ACME-CAA above. But I'm open to suggestions.