Thanks for all the discussion so far. I think we are making progress; I do have some outstanding questions at the bottom of this note.
On rereading the original text in question in light of the discussion so far, I can squint hard and call it not-technically-wrong: >>>>> 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. Since according to RFC 5280 §4.2.1.9 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 Strictly speaking I don’t think the text as written contradicts that, it’s just a tautology. I do agree that it’s written in a potentially misleading way, and I do agree that the proposed rewrite is less confusing: >>>>> 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. although I’d add that since 5280 is already clear on this matter, neither variant of the sentence is required at all. The proposed rewrite respecifies something that was already specified elsewhere, which is undesirable. (Then again, this sin was already present in the ur-text of 6487.) So an arguably better fix is just to strike the sentence, or to rewrite it without using the RFC 2119 scare capitals. Terry’s proposal, > 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. strikes the sentence at issue and as a bonus clarifies the remaining one. Seems like a win-win. His version still uses SCARY CAPITALS to respecify something that was already said perfectly well in RFC 5280, which I don’t love. But since RFC 6487 already did this, it’s beyond the scope of an erratum to correct it, the most we should do is make sure that the respecified text is consistent, clear, and accurate. So I’m OK with it. It seems like there’s consensus that the RFC 6487 text deserves an erratum. The things I’m still working out are, 1. Was there some nuance the authors were trying for in the “issuer determines whether the "cA" boolean is set” sentence, that we’re going to accidentally destroy? For example, is this really saying something like “yo, the issuer gets to decide if subdelgation is allowed”? 2. Is 6487 strictly speaking *wrong*, or does it just suffer from very unfortunate wording that makes it less clear than we would prefer? As discussed above I think it might be the latter. This affects whether the erratum should be marked “verified” or “hold for document update”, see https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ One test of this would be to ask, is there any realistic risk that an implementor would implement incorrectly based on the text as it stands? Right now I am inclined in the direction of “hold for document update”. 3. What corrected text do we want to use? As mentioned above I quite like Terry’s and plan to use that unless there’s pushback, pending an answer to question 1. —John > On May 10, 2022, at 8:46 AM, Terry Manderson <te...@terrym.net> 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 <job=40fastly....@dmarc.ietf.org> >> wrote: >> >> Hi, >> >> Earlier versions of RFC 6487 contained slightly more verbose guidance: >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-sidr-res-certs-18*section-4.9.1__;Iw!!NEt6yMaO-gk!Bdgioqq_ZZJbLYpMzziW-hkm1NBZpa0fACOEmjaxS-VZOqYmcCAD-uaXLK73YxlSEU_SBT0DaY0$ >> """ >> 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.bonn...@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 <g...@apnic.net> >>>> Sent: Wednesday, February 16, 2022 5:23 PM >>>> To: RFC Errata System <rfc-edi...@rfc-editor.org> >>>> Cc: George Michaelson <g...@apnic.net>; robe...@apnic.net; >>>> aretana.i...@gmail.com; j...@juniper.net; martin.vigour...@nokia.com; >>>> Chris Morrow <morr...@ops-netman.net>; sa...@tislabs.com; Corey Bonnell >>>> <corey.bonn...@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-edi...@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://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6854__;!!NEt6yMaO-gk!Bdgioqq_ZZJbLYpMzziW-hkm1NBZpa0fACOEmjaxS-VZOqYmcCAD-uaXLK73YxlSEU_S8ym75As$ >>>>> >>>>> -------------------------------------- >>>>> Type: Technical >>>>> Reported by: Corey Bonnell <corey.bonn...@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 >>> sidr...@ietf.org >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sidrops__;!!NEt6yMaO-gk!Bdgioqq_ZZJbLYpMzziW-hkm1NBZpa0fACOEmjaxS-VZOqYmcCAD-uaXLK73YxlSEU_SIPFE6Uw$ >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sidr__;!!NEt6yMaO-gk!Bdgioqq_ZZJbLYpMzziW-hkm1NBZpa0fACOEmjaxS-VZOqYmcCAD-uaXLK73YxlSEU_SP-Pd7mQ$ > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
