Re: [pkix] [Technical Errata Reported] RFC6844 (5244)

Corey Bonnell <> Thu, 01 February 2018 13:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F00D12E042 for <>; Thu, 1 Feb 2018 05:15:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FQhWHJMZBNik for <>; Thu, 1 Feb 2018 05:15:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 67A5612E046 for <>; Thu, 1 Feb 2018 05:15:29 -0800 (PST)
Received: from (Not Verified[]) by with Trustwave SEG (v7, 5, 7, 10058) (using TLS: TLSv1.2, AES256-SHA256) id <B5a7312ef0003>; Thu, 01 Feb 2018 07:15:27 -0600
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Thu, 1 Feb 2018 13:15:25 +0000
Received: from ([]) by ([]) with mapi id 15.20.0464.012; Thu, 1 Feb 2018 13:15:24 +0000
From: Corey Bonnell <>
To: RFC Errata System <>, "" <>, "" <>, "" <>, "" <>, "" <>, "" <>
CC: "" <>
Thread-Topic: [Technical Errata Reported] RFC6844 (5244)
Thread-Index: AQHTlsgRAMbBIcv4ykadVUMS+K93IKOPPAyA
Date: Thu, 1 Feb 2018 13:15:24 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR07MB3455; 7:Trwk2RlSno772cPF4Qnw86kvbVACofwJjAz2QvGdeXjct6erQQ0wqkydtIN98MpEEOFw8OIYxgC9mmklc9cF0vB1zFSsDef+NS5tV4f6XHew1XTIgyt5+T8djXD74KXujdi005KxJ+mX6jxee32sx7CdeXr8b9KgW2CL/s8kIaosfn233BJfeCXEburdA25bnUGe6LAn/7H+D+H6MIIbv3FDFsztPTHdO4ZjAvCjQOClbaUY7+129AApT0+G9m7s
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 17a981c8-0674-4efc-dc63-08d56975dafa
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR07MB3455;
x-ms-traffictypediagnostic: MWHPR07MB3455:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(232896897485771)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231101)(2400082)(944501161)(10201501046)(3002001)(6041288)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:MWHPR07MB3455; BCL:0; PCL:0; RULEID:; SRVR:MWHPR07MB3455;
x-forefront-prvs: 0570F1F193
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(396003)(376002)(39380400002)(39860400002)(189003)(199004)(2501003)(3846002)(53936002)(6512007)(6246003)(110136005)(3280700002)(316002)(3660700001)(36756003)(14454004)(2201001)(82746002)(76176011)(106356001)(86362001)(966005)(105586002)(83716003)(97736004)(6116002)(72206003)(478600001)(2906002)(102836004)(186003)(305945005)(6506007)(5660300001)(99286004)(80792005)(59450400001)(6306002)(8676002)(77096007)(7736002)(33656002)(25786009)(2950100002)(2900100001)(81156014)(6486002)(39060400002)(229853002)(6436002)(66066001)(68736007)(4326008)(81166006)(8936002)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR07MB3455;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: jBIPt6OrcSus6Rp73dpt6M3yy5bSTitmfTV4kKGmOgyf+bVe1MD43WVtUnUeuYs92Gp3gDgivjg4f/iII9k+Ww==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 17a981c8-0674-4efc-dc63-08d56975dafa
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2018 13:15:24.7506 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cb1dab68-a067-4b6b-ae7e-c012e8c33f6a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR07MB3455
Archived-At: <>
Subject: Re: [pkix] [Technical Errata Reported] RFC6844 (5244)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Feb 2018 13:15:33 -0000

I submitted this erratum in response to discussions that occurred on the LAMPS WG mailing list ( as well as in the CA/B Forum Validation WG. Those discussions concluded that the current wording of the RFC is ambiguous, but the intent is clear.

We would like to clarify the ambiguity in the CA/B Forum Baseline Requirements, but several CA/B Forum members commented that it would be best to first submit this erratum and have it approved ( so that it can be referenced in the Baseline Requirements directly in the same manner Erratum 5065 was handled. Since this is not a compatibility-breaking or semantics-altering change but merely a clarification, I am hoping that this erratum can be approved relatively quickly so that we can proceed with including this erratum in the Baseline Requirements.

Is there anything I can do to help get this erratum approved or perhaps address any concerns with how I phrased the proposed clarification?

Corey Bonnell
Senior Software Engineer

t: +1 412.395.2233
2017 Best Managed Security Service Winner – SC Media

On 1/26/18, 12:06 PM, "RFC Errata System" <> wrote:

    The following errata report has been submitted for RFC6844,
    "DNS Certification Authority Authorization (CAA) Resource Record".
    You may review the report below and at:
    Type: Technical
    Reported by: Corey Bonnell <>
    Section: 5.2
    Original Text
    CAA authorizations are additive; thus, the result of specifying both
    the empty issuer and a specified issuer is the same as specifying
    just the specified issuer alone.
    Corrected Text
    CAA authorizations are additive; thus, the result of specifying both
    the empty issuer and a specified issuer is the same as specifying
    just the specified issuer alone.  A non-empty CAA record set that does
    not contain an issue property tag is authorization to any certificate
    issuer to issue for the corresponding domain, provided that no
    records in the CAA record set otherwise prohibit issuance.
    The current wording in the RFC does not clearly state how non-empty CAA record sets which do not contain any "issue" property tags should be handled in terms of whether or not such record sets authorize issuance. The additional wording clarifies the correct handling of this case.
    This erratum is currently posted as "Reported". If necessary, please
    use "Reply All" to discuss whether it should be verified or
    rejected. When a decision is reached, the verifying party  
    can log in to change the status and edit the report, if necessary. 
    RFC6844 (draft-ietf-pkix-caa-15)
    Title               : DNS Certification Authority Authorization (CAA) Resource Record
    Publication Date    : January 2013
    Author(s)           : P. Hallam-Baker, R. Stradling
    Category            : PROPOSED STANDARD
    Source              : Public-Key Infrastructure (X.509)
    Area                : Security
    Stream              : IETF
    Verifying Party     : IESG