Re: [sidr] [Sidrops] [Technical Errata Reported] RFC6487 (6854)

Job Snijders <job@fastly.com> Tue, 10 May 2022 07:58 UTC

Return-Path: <job@fastly.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CD0C157902 for <sidr@ietfa.amsl.com>; Tue, 10 May 2022 00:58:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd6PnYQFYS-s for <sidr@ietfa.amsl.com>; Tue, 10 May 2022 00:58:15 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 756B9C157B42 for <sidr@ietf.org>; Tue, 10 May 2022 00:58:15 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id m20so31244515ejj.10 for <sidr@ietf.org>; Tue, 10 May 2022 00:58:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=tWsuhDph5jJNh5jyNqTYOuxUXuhFvfTV+ePwWtdoFEI=; b=X8NCrHxm8wRCRseSOO6HiCLM4d1u/6jJh/cZCUvRBtz7a5eb8ZaOlJofksFhpEotV3 Ul4fsjUvrPp0DnHjar6D8CZIfzVWjF8Vg73M2rH5azXSOr7EZ/tl4Xg7dB2Jk/ngtA8z +0duN5b5I0S9zKFC9aGSkSNaqPz2aPk9Cd3Dc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=tWsuhDph5jJNh5jyNqTYOuxUXuhFvfTV+ePwWtdoFEI=; b=i58gbufzx6nlIM69Mw1YRkrd/o4L8AW1D4SmLNDzqad5T+5ThGaUKRJTXjN0Jrokpk ETCHctP1+rzE5nZeWfTcyMHh7V8ueABITILc972yYP4EMS7IRmFKC52d+6NNrfQbwabe qZnBv05YKmn7D+JXcw3zZYW4ruZVL36Yv2qhexdvwEn+8FGHtV58DXFUGwFu4GRtMYQM Z7/s2GZKoDGNq5WGF8ZTS58uQuKEa2N6D3BSGsDxTqfTiZ9r546p6dqIBMGVgDHLGek6 JIECKiyP8piQ6lodazGcWKDVK5E+WK8PjGF76Ew0rYMGLK0qG0uI6JMMhNOt2kR97Tce rpSA==
X-Gm-Message-State: AOAM530kYYQWqMMuwHpWAeTEgP4PgMTYlnRRmgrtyN2pqNTqX3A/StgQ WpH2csDwhx1AnlnWJGey6WH5qQ==
X-Google-Smtp-Source: ABdhPJxb6k7NHgIUaMbd2WjYfPWbr4vtObfCP6eiQSUCRqwW0cHMO+9hMFFiH2TrUMC2Y2EBZrUA+g==
X-Received: by 2002:a17:906:b48:b0:6f5:132c:1a17 with SMTP id v8-20020a1709060b4800b006f5132c1a17mr18521067ejg.748.1652169493053; Tue, 10 May 2022 00:58:13 -0700 (PDT)
Received: from snel ([2a10:3781:276:2:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id eb20-20020a170907281400b006f3ef214e71sm5762208ejc.215.2022.05.10.00.58.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 May 2022 00:58:12 -0700 (PDT)
Date: Tue, 10 May 2022 09:58:10 +0200
From: Job Snijders <job@fastly.com>
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: Corey Bonnell <Corey.Bonnell@digicert.com>, "sidrops@ietf.org" <sidrops@ietf.org>, Geoff Huston <gih@apnic.net>, George Michaelson <ggm@apnic.net>, "robertl@apnic.net" <robertl@apnic.net>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "martin.vigoureux@nokia.com" <martin.vigoureux@nokia.com>, Chris Morrow <morrowc@ops-netman.net>, "sandy@tislabs.com" <sandy@tislabs.com>, "sidr@ietf.org" <sidr@ietf.org>
Message-ID: <YnobEvvvrFGMG0B3@snel>
References: <20220216174658.65B404C1CE@rfc-editor.org> <E88BA6FA-9871-42FB-8B56-08ABBF375AA0@apnic.net> <DM6PR14MB218608968CAE1AF1311895F192359@DM6PR14MB2186.namprd14.prod.outlook.com> <75B90D51-F1F3-41F2-8142-D14997F59526@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <75B90D51-F1F3-41F2-8142-D14997F59526@juniper.net>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/hGb4MQCBhhKUCUWELzlsI76scwQ>
Subject: Re: [sidr] [Sidrops] [Technical Errata Reported] RFC6487 (6854)
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, 10 May 2022 07:58:20 -0000

Hi,

Earlier versions of RFC 6487 contained slightly more verbose guidance:
https://datatracker.ietf.org/doc/html/draft-ietf-sidr-res-certs-18#section-4.9.1
"""
   4.9.1.  Basic Constraints

   The Basic Constraints extension identifies whether the Subject of the
   certificate is a CA and the maximum depth of valid certification
   paths that include this certificate.

   The Issuer determines whether the "cA" boolean is set.  If this bit
   is set, then it indicates that the Subject is allowed to issue
   resources certificates within this overall framework (i.e. the
   Subject is a CA).

   The Path Length Constraint is not specified in this profile and MUST
   NOT be present.

   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.
"""

To me it seems the original intent was along the lines of "and that's
the range of choices available to you".

This errata report helps reduce a potential for confusion: there simply
are no valid circumstances in which a certificate contains a Basic
Constaints extension with "CA:FALSE".

Kind regards,

Job

On Mon, May 09, 2022 at 09:18:13PM +0000, John Scudder wrote:
> +sidrops
> -rfc-editor
> 
> Taking on faith that Corey’s description here is right, it does sound as though there’s an error in RFC 6487. I also don’t understand Geoff’s earlier comment that the erratum is implicitly adding “And thats the range of choices available to you”. Assuming Corey is right, it would be appropriate to verify the erratum
> 
> However before taking action I’d appreciate it if someone else with expertise in PKIX (i.e., not me) were to confirm. Don’t all speak up at once. ;-)
> 
> Thanks,
> 
> —John
> 
> > On Feb 16, 2022, at 5:41 PM, Corey Bonnell <Corey.Bonnell@digicert.com> wrote:
> > 
> > Geoff,
> > If the Basic Constraints extension is omitted then it is not possible to set the "cA" field to any value, as it is a field within the Basic Constraints extension.
> > 
> > The original language says, "The issuer determines whether the "cA" boolean is set.". We know from the current text that the Basic Constraints extension is prohibited in end-entity certificates. Therefore, the "cA" field does not exist in an end-entity certificate. As a result, the only possible value for "cA" in all cases where the field is present is "true", as that field may only exist in CA certificates. It is an RFC 5280 profile violation if a CA certificate contains a Basic Constraints extension with a "cA" field value of false.
> > 
> > Thanks,
> > Corey
> > 
> > -----Original Message-----
> > From: Geoff Huston <gih@apnic.net> 
> > Sent: Wednesday, February 16, 2022 5:23 PM
> > To: RFC Errata System <rfc-editor@rfc-editor.org>
> > Cc: George Michaelson <ggm@apnic.net>; robertl@apnic.net; aretana.ietf@gmail.com; jgs@juniper.net; martin.vigoureux@nokia.com; Chris Morrow <morrowc@ops-netman.net>; sandy@tislabs.com; Corey Bonnell <Corey.Bonnell@digicert.com>; sidr@ietf.org
> > Subject: Re: [Technical Errata Reported] RFC6487 (6854)
> > 
> > Frankly I am having some trouble in understanding what is going on here. 
> > 
> > The original says “You can issue anything you want. IF you want to issue a CA cert then you MUST use Basic Constraints and set the CA bit. If you want to issue a EE cert then you MUST omit Basic Constraints.”
> > 
> > What the document does not say is “And thats the range of choices available to you” Implicitly thats what this report is trying to add, and I’m not sure that the original RFC went that far to limit the issuer’s options in this manner.
> > 
> > I would argue that this is not an error in the original RFC. The reporter is trying to add to the original RFC, but doing so via an errata report seems to me to be inappropriate.
> > 
> > Therefore I tend toward rejecting this on the basis that the report is not a report of an error in the RFC.
> > 
> > Geoff
> > 
> > 
> > 
> > 
> >> On 17 Feb 2022, at 4:46 am, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> >> 
> >> The following errata report has been submitted for RFC6487, "A Profile 
> >> for X.509 PKIX Resource Certificates".
> >> 
> >> --------------------------------------
> >> You may review the report below and at:
> >> https://www.rfc-editor.org/errata/eid6854
> >> 
> >> --------------------------------------
> >> Type: Technical
> >> Reported by: Corey Bonnell <corey.bonnell@digicert.com>
> >> 
> >> 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 a critical extension in the
> >>  resource certificate profile, and MUST be present when the subject is
> >>  a CA, and MUST NOT be present otherwise.
> >> 
> >>  If this extension is present, then the "cA" field MUST be true.
> >> 
> >> Notes
> >> -----
> >> The original text is contradictory. If the basicConstraints extension is prohibited in end-entity certificates, then it follows that whenever the extension is present in a certificate, that certificate is a CA certificate. If the certificate is a CA certificate, then the "cA" boolean MUST be true in all cases. It is nonsensical to allow a "cA" field value of false.
> >> 
> >> Instructions:
> >> -------------
> >> 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.
> >> 
> >> --------------------------------------
> >> 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
> > 
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops