[lamps] CAA tags

Tim Hollebeek <tim.hollebeek@digicert.com> Mon, 18 December 2017 17:41 UTC

Return-Path: <tim.hollebeek@digicert.com>
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 80CD8124B18 for <spasm@ietfa.amsl.com>; Mon, 18 Dec 2017 09:41:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.012
X-Spam-Level: *
X-Spam-Status: No, score=1.012 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TRACKER_ID=1.102, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 NiEzmosJlN1T for <spasm@ietfa.amsl.com>; Mon, 18 Dec 2017 09:41:53 -0800 (PST)
Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.14]) (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 906141200F1 for <spasm@ietf.org>; Mon, 18 Dec 2017 09:41:53 -0800 (PST)
Received: from [216.82.249.212] by server-14.bemta-12.messagelabs.com id EA/D4-03539-1EDF73A5; Mon, 18 Dec 2017 17:41:53 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WTW0zTYBiG97frqLCaMoZ8LqBY4wF1UzRDEr3 wRsOFJsYLD4jBopVVtrG008wzmogwJCERDaCAKGjEM9FgEBQneIxRkGBAiRIMInhCo4Ii2u4f ijd/nrzv+7Vvv/ylScP+IBMteNyC5OTtnC5Y+9hy0m1+9Wt+4pz650R8YcugLr6kdcMiIuHD5 zdUQnn5ILGcSKREZ0q6Zz1l+9F9hXR9O0N4Dv1ckoFacwkvGkNr2Y8E3CtOU9nA5hPQUDnWi4 IVbkBwt7FHpxo6dg601t31DxhZD1w68EXRaTqMDYXcdwF5HHQdORtgC2Sca/FHtOwUGHixU5U ZNgnu7D2OVEZK/PuDc/44yUZA++tSPwNrhM6mhzrM4fC2a5jC+SQo/uIL6Bw8Pz+AMEdBc2kO UisD6wuCx8eaKGzMA29eLYWNyxSU33wamF4GNVkvddg4haAp97oWGzPgxPc6Um0NbBpcHE4ek bMaigicv01CeUl34NWR0NWQo8Wb2wj5lbheGGuCjpZshDkSel7UUfgzSxEU1EfjVYTC/cLX2j w0tWjUBopGxYpGxbCeCIMHMxFmM9TcqCcxT4Tq98cCPAsyXz4M8Ew4VdYX4AVQ8OOWDvMkyM/ pDMJshb7GfnQchVSi6bIgbRUk87w4S4okptrcDl60m2Nj51ocgizzqYKdT5EtG9IdVUi5ens0 GnQNPSpb60PjaYILZwpD4hINY1PSN26z8bItWdpiF2QfiqRpDpgg5YoaQiUhVfBsEu3K/R2xg dZzRoZVbUZ28Q5ZTMXWA7SYHqptHyLoS20dynnDf9bUXv1N0N2FfRmkQetMdwqmCKZrSBlm1W HbFuffR4/8Hc0oyhTGII1GY9C7BMkhuv/3e1EEjbgwJkqtoBed7r8NepVyhFLu8Gp/OTf/zzJ lIH2cZN0VM5sq1ptdvZmHtrYdTcjrb9EYiVWf2t5vr8jatzJa+pW9YrVcdcFIxnh3RVs7+ias 29Ne1j88a27F25kFxmfeEDGh2XXkXuzthclM/ORe8dlAcWf15neNS0NXxuwIf5Kk70kenLasx FcxZMpevCYu2HctbTdjtZ6O575ynFa28bEzSEnm/wD5YQqiGAQAAA==
X-Env-Sender: tim.hollebeek@digicert.com
X-Msg-Ref: server-3.tower-219.messagelabs.com!1513618907!200475936!1
X-Originating-IP: [207.46.163.116]
X-StarScan-Received:
X-StarScan-Version: 9.4.45; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15731 invoked from network); 18 Dec 2017 17:41:51 -0000
Received: from mail-sn1nam01lp0116.outbound.protection.outlook.com (HELO NAM01-SN1-obe.outbound.protection.outlook.com) (207.46.163.116) by server-3.tower-219.messagelabs.com with AES256-SHA256 encrypted SMTP; 18 Dec 2017 17:41:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qHsqLQEdVECla885pE62dfX3kW7h5aWw9s0FJjZvFdM=; b=WUlsrX/XX89xyg6edFByyBJwnZ+XLFONPqLvLeD/xVLmmQtv91oKEjXDX6Jf+fQnMBhwdxmViKe+2DI6afKLQAwJtVSBZtVOL7Bq6QwQitN26rD1oWSf6smzat9g1QVeCYfdInNNTzF2F2xS7gyMlHO2Z4kvJFmrKhORa1t554k=
Received: from DM5PR14MB1289.namprd14.prod.outlook.com (10.173.132.19) by DM5PR14MB1291.namprd14.prod.outlook.com (10.173.132.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Mon, 18 Dec 2017 17:41:46 +0000
Received: from DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) by DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) with mapi id 15.20.0323.018; Mon, 18 Dec 2017 17:41:45 +0000
From: Tim Hollebeek <tim.hollebeek@digicert.com>
To: Tim Hollebeek <tim.hollebeek@digicert.com>, Jacob Hoffman-Andrews <jsha@eff.org>, "spasm@ietf.org" <spasm@ietf.org>
Thread-Topic: CAA tags
Thread-Index: AdN4J3TZ60fppeKgRNaOHREkYP39nw==
Date: Mon, 18 Dec 2017 17:41:45 +0000
Message-ID: <DM5PR14MB1289FA2B76543ABAF16FD0EF830E0@DM5PR14MB1289.namprd14.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [74.111.107.128]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR14MB1291; 6:b2Zm0j4L5O7+EhzzFctqjm3U5cyJ0ZB5W+ws9nuNP2jeXTmtCnBgyQS+qqVKwNpL0m9V8YCfPP2Wp2jZc08YALKeq6xiICsnBvHFXqzbtfwLqG0KhtZ4V4GHfMpyGBYwbRabv/6AstejzKJTV/+6mJZayLnKs3nFtp96yU6d/u13ubDry5A7Bt6sIaQ3p4191eaGvjE6FecRUjXuotqBUYuR6MMeE8KNllThACgrCIdvt/+PwkQaEwzMog2gWE7brPxptiEm0QI2KSbbJBJIGqXfY6AtC0zMjxfOmOmzkFTNEoM+bZgmykzpnAYF1HdICbLQ7jAxIUTpb0H4IqHvNm7zeIWZtFXNa5IJAEI4wZ8=; 5:SpTLXpJp8P6tyKVOnoyP8gQHQq9oKuuCOibncwt40cqI0Snxtq/ckKHjhNgTz2XC/Gv5+YWUgWKersKmtxzrD382bqEIQeHskBpVrmK+9X2H52bQlg180oW4Pd1mICMfbTNVrgSbsCL0c3T5KOFrnuAXxolC9drI4sx6ZTk18mo=; 24:wlAblmdY0oRo7jkHN/pm+0K0cVR1LL8OHCf5btjBcFjGFNzJvBgzh2swlboHnKIIvn2aJfWB4GMLLCkkHTVHsnACLMaFCFGpB14Fc9mIkzo=; 7:qU9+P4cGO0gIrXmyALdoC9at4p/AXhKshz+l/xWmk31tWp/roXA8m6qNb2HYw0vjF84EmANPEFuf1xPxFwlwGr4IEsfI0AvmRHKa3x360jYr7YOyUDlssZTL4KtO90b4YZ8lJi0fu7pWSaLEJQS6skopw90CksKl/YM2VrPUnqk7RoLdBE/Kxm9OgiQLfrfgLq42SnIHp/RbnkcPXzO3YazJcTxJL6+BnqAavvgkppPphTpV7l4hg3UVWR9ZSAUp
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39850400004)(366004)(376002)(396003)(346002)(199004)(189003)(9686003)(2501003)(3480700004)(99936001)(7736002)(6436002)(305945005)(74316002)(77096006)(53936002)(14454004)(561944003)(25786009)(33656002)(55016002)(68736007)(478600001)(99286004)(105586002)(97736004)(2900100001)(106356001)(59450400001)(7116003)(81166006)(81156014)(8676002)(6506007)(221733001)(7696005)(3280700002)(110136005)(316002)(3660700001)(5660300001)(2906002)(86362001)(6116002)(102836003)(8936002)(66066001)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR14MB1291; H:DM5PR14MB1289.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-ms-office365-filtering-correlation-id: fb54147d-8af8-4ad1-be2a-08d5463e9bb1
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603307)(49563074); SRVR:DM5PR14MB1291;
x-ms-traffictypediagnostic: DM5PR14MB1291:
x-microsoft-antispam-prvs: <DM5PR14MB12915D0254180D083534A3D1830E0@DM5PR14MB1291.namprd14.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231023)(3002001)(6041248)(2016111802025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(6072148)(6043046)(201708071742011); SRVR:DM5PR14MB1291; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR14MB1291;
x-forefront-prvs: 0525BB0ADF
received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0522_01D377EC.C88FF0A0"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fb54147d-8af8-4ad1-be2a-08d5463e9bb1
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2017 17:41:45.4483 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR14MB1291
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/Jse-FslACq3wair2B2_YSwpViNs>
Subject: [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 17:41:56 -0000

Here is my tags proposal, in case others want to comment on it on this list.

 

Note that it has been privately pointed out to me that one possible solution
to the criticality problem and the scaling problem is to use top-level tags
that are independent of the issue records:

 

Something like:

 

CAA 0 issue "a.example.com"

CAA 0 issue "b.example.com"

CAA 128 validation "Phone"

 

-Tim

 

----------------------------------------------------------------------------
---------------------------------------------------------------------------


Introduction and Motivation


 

In addition to being able to specify which CA or CAs are allowed to issue
certificates for a given domain, RFC 6844 allows additional parameters, such
as the account number, that the CA can consume for a variety of uses.  RFC
6844 defines the format, but otherwise leaves the kinds of properties and
their meanings up to the issuer.

While this is appropriate for a technical standard, standardizing the names
and meanings of CAA properties across the CA industry has the following
benefits:

1.	Reduce user confusion when the same or similar property is used by
different CAs with different names and semantics
2.	Make it simpler to migrate from one CA to another while preserving
the CAA configuration
3.	Simplifying configuration and expression of CAA policies that allow
issuance from multiple CAs
4.	Allow CAA record creation tools to support creating CAA records that
contain properties that have been standardized


History


 

CAA property tags have been discussed at several CA/B Forum meetings, most
recently at the October meeting in Taipei.  Four were suggested: Acceptable
validation methods, an account identifier, certificate types (DV/OV/EV), and
ability to specify a brand.

 


Method of Adoption


 

Since these CAA properties are just a voluntary industry standard that any
CA could implement, they don't necessarily have to exist in a standards
document.  However, it seems like it would be helpful if the names and
semantics were agreed upon by the industry as a whole, so it is probably
best to include them in the Baseline Requirements as an optional feature CAs
MAY implement.

On the other hand, it might be desirable to reserve the names, and require
that if these particular property names are used, the semantics MUST be the
semantics specified in the Baseline Requirements.

 


Brands


 

I'm starting with this one because I'm going to argue it isn't necessary.
CAs can and do have multiple names that they accept in CAA records.  It is
hard to imagine a brand existing without the associated domain and website
also existing.  I'd suggest that CAs that maintain multiple brands simply
use a different domain name for each brand, e.g.

certs.example.com               CAA 0 issue "megaca.com"

catlover.example.com         CAA 0 issue "certsforcats.com"    #
certsforcats is a brand owned by MegaCA.

CAAs can also publicize examples of CAA records that allow for issuance by
all of their brands.


Acceptable Validation Methods


 

A list of acceptable validation methods can be specified using the
"validation" tag.

There are two challenges here, that have been discussed elsewhere in
relation to keeping records of which validation method was used for a
particular certificate.  The first is that validation methods can change
over time.  This seems to be less of a concern for issuance than it is for
historical validations, as a CAA record can and should be interpreted as
always requiring the version of the method that is enforced by the BRs at
issuance time.  However, this can cause the exact meaning of a CAA record to
change over time as the BRs evolve.  I don't think this is a big problem,
but wanted to note it.

The second issue is that it is possible that the numbering of the BR
validation methods could potentially change over time.  For that reason, I
think it might be reasonable to standardize on a label for each validation
method, that can be used in addition to the section number:


BR Section (BR v. 1.5.4)

Short Section

Validation method label


3.2.2.4.1

1

DomainContact


3.2.2.4.2

2

EmailOrSimilar


3.2.2.4.3

3

Phone


3.2.2.4.4

4

ConstructedEmail


3.2.2.4.5

5

DomainAuthorizationDocument


3.2.2.4.6

6

WebsiteChange


3.2.2.4.7

7

DNSChange


3.2.2.4.8

8

IPAddressLookup


3.2.2.4.9

9

TestCertificate


3.2.2.4.10

10

RandomValueInCertificate

 

Examples:

CAA 0 issue "ca.example.net; validation=3"                      # Call me
about all certificates

CAA 0 issue "ca.example.net; validation=Phone"             # Same as
previous example

CAA 0 issue "ca.example.net; validation=1,2,3,4,7,8,9,10"   # I don't like
DADs and website changes

CAA 0 issue "ca.example.net; validation=!5,6"                 # Same as
previous example.  Worth the trouble?


Account Identifier


 

This one is relatively straightforward, as the identifier is going to be
CA-specific anyway.  Use the "account" keyword:

CAA 0 issue "ca.example.net; account=8675309"

The format and values of the account specifier is up to the individual CA.


Acceptable Certificate Types


 

This one also seems to be relatively straightforward.  I've chosen to make
the categories disjoint, so if you're ok with more than one type, you have
to specify more than one.  Use the "type" keyword.

CAA 0 issue "ca.example.net; type=EV"                         # EV only

CAA 0 issue "ca.example.net; type=DV"                         # DV only

CAA 0 issue "ca.example.net; type=OV,EV"                   # No DV


Lack of Property Tag Value Criticality


 

Supporting the various properties is optional.  Unlike the CAA "issue"
property, these properties do not have to be ubiquitously supported to have
value, because Domain holders can restrict their issue records to only
include CAs that have publicly stated that they support the desired property
tags.

For example, if CAs A, B, and C support the "type=EV" tag, then the
following will prevent non-EV issuance:

CAA issue 0 "A.com; type=EV"

CAA issue 0 "B.com; type=EV"

CAA issue 0 "C.com; type=EV"

Unfortunately, this does scale poorly with a large number of CAs.

The problem is that RFC 6844 supports "Critical" for property tags (like
"issue"), but there is no way to mark a parameter tag is "Critical".  I
intend to bring this up with the IETF WG.

Any easy solution is to use reserved bit #1 for property tag criticality:


CAA issue 64 "A.com; type=EV"            # type=EV tag must be respected;
                                                                    # cannot
issue if you don't understand or enforce it.


 


Multiple Tags


 

Just for completeness, these individual features can also be used together:

CAA issue 0 "ca.example.com; type=EV validation=Phone account=8675309"