[sidr] [Errata Held for Document Update] RFC6487 (6854)

rfc-editor@rfc-editor.org Tue, 24 May 2022 17:59 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B7A48C20D6AE for <sidr@ietfa.amsl.com>; Tue, 24 May 2022 10:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.645
X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NHS8lky7L39K for <sidr@ietfa.amsl.com>; Tue, 24 May 2022 10:59:26 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC62C20D6AD for <sidr@ietf.org>; Tue, 24 May 2022 10:59:25 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 6317ED8454; Tue, 24 May 2022 10:59:25 -0700 (PDT)
To: corey.bonnell@digicert.com, gih@apnic.net, ggm@apnic.net, robertl@apnic.net
From: rfc-editor@rfc-editor.org
Cc: Alvaro Retana <aretana.ietf@gmail.com>, John Scudder <jgs@juniper.net>, Martin Vigoureux <martin.vigoureux@nokia.com>, morrowc@ops-netman.net, sandy@tislabs.com, sidr@ietf.org, RFC Editor <rfc-editor@rfc-editor.org>
Content-type: text/plain; charset=UTF-8
Message-Id: <20220524175925.6317ED8454@rfcpa.amsl.com>
Date: Tue, 24 May 2022 10:59:25 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/zsj0D16V6DVUSyS3YYFyNG3wdHQ>
Subject: [sidr] =?utf-8?q?=5BErrata_Held_for_Document_Update=5D_RFC6487_?= =?utf-8?b?KDY4NTQp?=
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2022 17:59:29 -0000

The following errata report has been held for document update
for RFC6487, "A Profile for X.509 PKIX Resource Certificates".

You may review the report below and at:

Status: Held for Document Update
Type: Technical

Reported by: Corey Bonnell <corey.bonnell@digicert.com>
Date Reported: 2022-02-16
Held by: John Scudder (IESG)

Section: 4.8.1

Original Text
  The Basic Constraints extension field is a critical extension in the
  resource certificate profile, and MUST be present when the subject is
  a CA, and MUST NOT be present otherwise.

  The issuer determines whether the "cA" boolean is set.

Corrected Text
   The Basic Constraints extension field is critical and MUST be present 
   when the "cA" field is TRUE, otherwise it MUST NOT be present.

See discussion at https://mailarchive.ietf.org/arch/msg/sidrops/dPCiDz_pDR68G4cTC8W7X5LTE5o/

The original text is tautological -- Since according to RFC 5280 § the "cA" boolean MUST be set when the subject is a CA, and MUST NOT be set when the subject is not a CA, then it's axiomatic that 

cA boolean set <=> Basic Constraints field present <=> subject is a CA

Although the original text is not strictly speaking wrong, it's potentially misleading since it could be read as implying that it's possible to have the cA boolean FALSE in a CA certificate, which is not so. 

RFC6487 (draft-ietf-sidr-res-certs-22)
Title               : A Profile for X.509 PKIX Resource Certificates
Publication Date    : February 2012
Author(s)           : G. Huston, G. Michaelson, R. Loomans
Category            : PROPOSED STANDARD
Source              : Secure Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG