Re: [lamps] CAA tags

Jacob Hoffman-Andrews <jsha@eff.org> Mon, 18 December 2017 19:30 UTC

Return-Path: <jsha@eff.org>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E47B126C83 for <spasm@ietfa.amsl.com>; Mon, 18 Dec 2017 11:30:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.111
X-Spam-Level:
X-Spam-Status: No, score=-5.111 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org
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 CGSOrHbZqhxp for <spasm@ietfa.amsl.com>; Mon, 18 Dec 2017 11:30:42 -0800 (PST)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B7C120454 for <spasm@ietf.org>; Mon, 18 Dec 2017 11:30:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=RWHji3OQbAeL5/wvN8DBigj9MCpcgEcD8fncVa5sNpc=; b=s62jNtCoZNsXez/YhO7dHP9ktqKHpX7urWuvdJe324xZQm+rm2e1el+xx2BhmwCzBIuZAir+V14qGf9rSZ+NI/QthdZv4iELRLWAMJ7x0NkCfni6coJXwM6ZkkyfRWiIfRc3OjkiL3WDIyyRLVFWpyXvBQGZIBs1QOmPmbh8EMA=;
Received: ; Mon, 18 Dec 2017 11:30:37 -0800
To: spasm@ietf.org
References: <DM5PR14MB1289FA2B76543ABAF16FD0EF830E0@DM5PR14MB1289.namprd14.prod.outlook.com>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <0ab8efa3-378c-ece7-4fa3-913308f81c22@eff.org>
Date: Mon, 18 Dec 2017 11:30:40 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <DM5PR14MB1289FA2B76543ABAF16FD0EF830E0@DM5PR14MB1289.namprd14.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/6AKCMMYAgrCOKinSrQruuSqT6IM>
Subject: Re: [lamps] CAA tags
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Dec 2017 19:30:45 -0000

I'm following up your the related validation@cabforum thread at
https://cabforum.org/pipermail/validation/2017-December/000686.html,
hoping to merge the streams a little bit. :-)

On 12/18/2017 11:10 AM, Tim Hollebeek via Validation wrote:
> I personally find OIDs very hard for non-technical users to grasp.

This is a good point, although most users should be using a CAA record
generator, which can help with this.

> readable text labels, like Validation=Phone?

My issue with validation=phone is that it is not precise enough; there's
one version of validation by phone defined in the BRs today, but what if
that changes significantly? One could solve this by defining a versioned
validation method, e.g. validation=phone-01, with an IANA registry to
register new ones as requirements change.

However, there does seem to be some interest in embedding information
about validation methods in certificates. It would be nice if there was
a correspondence between the namespace used in CAA and the one used in
certificates.

> I think account and account-uri are complimentary approaches.  I agree
> that CAs need the freedom to put whatever they want on the right hand
> side of these, and many CAs have existing customer identification
> schemes that are not URIs, so the account-uri field cannot be used.

It's easy to define a URI mapping for an existing account identifier.
For instance, if customers have a numeric id 123456, the CA can specify
that the corresponding account-uri is
https://ca.example.net/accounts/123456. There's no requirement that
account-uris are fetchable.

It seems inefficient to define the same mechanism under two different
names in two different places (account vs account-uri), and I think is
likely to lead to user error.