[lamps] Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags

Corey Bonnell <CBonnell@trustwave.com> Fri, 12 January 2018 21:41 UTC

Return-Path: <CBonnell@trustwave.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4540A1200B9 for <spasm@ietfa.amsl.com>; Fri, 12 Jan 2018 13:41:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id D-1CU89tsktV for <spasm@ietfa.amsl.com>; Fri, 12 Jan 2018 13:41:23 -0800 (PST)
Received: from seg-node-elk-02.trustwave.com (seg-node-elk-02.trustwave.com []) (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 1FF3F124E15 for <spasm@ietf.org>; Fri, 12 Jan 2018 13:41:22 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (Not Verified[]) by seg-node-elk-02.trustwave.com with Trustwave SEG (v7, 5, 7, 10058) (using TLS: TLSv1.2, AES256-SHA256) id <B5a592b7f0001>; Fri, 12 Jan 2018 15:41:19 -0600
Received: from CY4PR07MB3575.namprd07.prod.outlook.com ( by BLUPR0701MB1890.namprd07.prod.outlook.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Fri, 12 Jan 2018 21:41:12 +0000
Received: from CY4PR07MB3575.namprd07.prod.outlook.com ([]) by CY4PR07MB3575.namprd07.prod.outlook.com ([]) with mapi id 15.20.0407.009; Fri, 12 Jan 2018 21:41:12 +0000
From: Corey Bonnell <CBonnell@trustwave.com>
To: "spasm@ietf.org" <spasm@ietf.org>
Thread-Topic: Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags
Thread-Index: AQHTi+4QDmko90Ob9kiZJwieEDaNDg==
Date: Fri, 12 Jan 2018 21:41:12 +0000
Message-ID: <878C91A0-6875-47A4-872F-F5D1F7F7AE7E@trustwave.com>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is ) smtp.mailfrom=CBonnell@trustwave.com;
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR0701MB1890; 7:5UZZV7rRGjKijse751I4A68fzLc7/TWf8MUu3tfq4JmXSyKX+sHrSnjSjxWnFMzYHI3JYQR9u3AQ8mgliu2ZvxJ2LV4bW6rx8lt/bl5dHM/F8JBJiQ9eaGmltKjnowJLaENDYsw5Tlu6disCqPaLQ263DVJqiy98MNKKZvE0ledNL0aTXmnttoepE5TYyyemh2ncbe5WF6jIz5PYgF307MGunrAB+puUtEnXC69uEnRggqtpXb0xd3X1MkEnOkY0
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39380400002)(366004)(376002)(346002)(39860400002)(396003)(189003)(199004)(6512007)(3660700001)(8936002)(97736004)(3846002)(6436002)(6306002)(6506007)(86362001)(6486002)(236005)(6916009)(54896002)(59450400001)(33656002)(9326002)(83716003)(8676002)(3280700002)(77096006)(5640700003)(7736002)(6116002)(36756003)(66066001)(2900100001)(80792005)(68736007)(1730700003)(72206003)(81156014)(53936002)(5660300001)(102836004)(2906002)(2501003)(606006)(81166006)(25786009)(478600001)(316002)(2351001)(14454004)(99286004)(82746002)(105586002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0701MB1890; H:CY4PR07MB3575.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
x-ms-office365-filtering-correlation-id: 4184090c-c1b7-40cb-038d-08d55a053335
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(3008032)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:BLUPR0701MB1890;
x-ms-traffictypediagnostic: BLUPR0701MB1890:
x-microsoft-antispam-prvs: <BLUPR0701MB1890665CC9B80DF045E21E48CF170@BLUPR0701MB1890.namprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(171964332516350)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(3231023)(944501075)(93006095)(93001095)(10201501046)(6041268)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:BLUPR0701MB1890; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR0701MB1890;
x-forefront-prvs: 0550778858
received-spf: None (protection.outlook.com: trustwave.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 70aauGcwoU7bxqCkQ3zTLqb72L5YPnf6h//hBz5lYLqk9Bk5tbICmWq61T8PbUL5Bo7QGSMS4BWSVnjLPdpnmQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_878C91A0687547A4872FF5D1F7F7AE7Etrustwavecom_"
MIME-Version: 1.0
X-OriginatorOrg: trustwave.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4184090c-c1b7-40cb-038d-08d55a053335
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 21:41:12.2460 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cb1dab68-a067-4b6b-ae7e-c012e8c33f6a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1890
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/SlO46FAsfQfFbI0FHCzLqhpa2iU>
Subject: [lamps] Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property 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: Fri, 12 Jan 2018 21:41:26 -0000

I believe that there are several ambiguities in RFC 6844 in regard to processing CAA resource record sets that do not contain "issue" records.

Section 3 of RFC 6844 (http://www.rfcreader.com/#rfc6844_line196) defines the "issue" property tag to authorize "the holder of the domain name <Issuer Domain Name> or a party acting under the explicit authority of the holder of that domain name to issue certificates for the domain in which the property is published". Based on my interpretation, the definition given here is suggesting that CAA issue restriction processing is done regardless of whether or not there is an "issue" record(s) present to specify the set of permitted Issuer Domain Names. In other words, the lack of "issue" records in a CAA resource record set indicates that no CA may issue for that domain, since no CA has been authorized to issue.

However, section 5.2 (http://www.rfcreader.com/#rfc6844_line447) defines the "issue" property tag to "request that certificate issuers perform CAA issue restriction processing for the domain and to grant authorization to specific certificate issuers". Based on this definition, it sounds as if CAA issue restriction processing is "opt-in". In other words, the absence of "issue" records in a CAA record set indicate that any CA may issue for that domain (since there was no "opt-in" into CAA restriction processing).

Section 4 (http://www.rfcreader.com/#rfc6844_line288) states that, "before issuing a certificate, a compliant CA MUST check for publication of a relevant CAA Resource Record set." Unfortunately, the term "relevant" is not defined by the RFC, which, compounded with the ambiguity highlighted above in regard to the definition of the "issue" property tag in sections 3 and 5.2, leads to ambiguity in the handling following scenarios:

- A CAA resource record set consisting solely of unknown non-critical property tags (including misspellings of "issue", such as "iisue", etc.)
- A CAA resource record set consisting solely of "iodef" property tags
- A CAA resource record set that contains both of the above

For each of these cases above, it is unclear which of the following three actions a CA should take:
- Fail issuance (since the CAA resource record set did not authorize any CA to issue, given the definition of the "issue" property tag in Section 3)
- Continue the tree-climbing search for records (since the resource record sets above could conceivably be considered as "not relevant")
- Allow issuance (since the resource record sets above could conceivably be considered as "relevant" and any CA may issue, given the definition of the "issue" property tag in section 5.2)

At Trustwave, we have taken the conservative approach and will not issue certificates if we encounter CAA resource record sets matching the descriptions of the three above. However, given that we may be overly restrictive by doing this, as well as for a desire for CAA record sets to be processed uniformly regardless of the CA, we would like to see these ambiguities resolved.

If others agree that the current wording of the RFC is ambiguous, I would be happy to present changes to relevant sections to clear up the ambiguity, but for now I wanted to send this along to see if others share our interpretation of the RFC.


Corey Bonnell
Senior Software Engineer
t: +1 412.395.2233


2017 Best Managed Security Service Winner – SC Media