The text proposed by Terry is consisted with the RFC 5280 and is seems to correct confusion with the text under discussion.
Russ > On May 10, 2022, at 8:46 AM, Terry Manderson <[email protected]> wrote: > > I've read, and re-read (several times), the errata text. > > I read Geoff's confusion and shared that belief. I then read Job's historical > context. And shifted my posture slightly. > > With that context it clarified an understanding how others have read > (including me) 6487. > > SoooOOOOooo.. > > I now read this with simplified logic: > > "The Basic Constraints extension field is critical and MUST be present when > the "cA" field is TRUE, otherwise it MUST NOT be present. > > (which aligns to to the historical text and context - and clarifies my my own > understanding) > > T. > >> On 10 May 2022, at 5:58 pm, Job Snijders <[email protected]> >> wrote: >> >> 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 <[email protected]> >>>> 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 <[email protected]> >>>> Sent: Wednesday, February 16, 2022 5:23 PM >>>> To: RFC Errata System <[email protected]> >>>> Cc: George Michaelson <[email protected]>; [email protected]; >>>> [email protected]; [email protected]; [email protected]; >>>> Chris Morrow <[email protected]>; [email protected]; Corey Bonnell >>>> <[email protected]>; [email protected] >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>> >>>>> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/sidrops >> >> _______________________________________________ >> sidr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
