Hi John, > On 10 May 2022, at 17:07, John Scudder <[email protected]> > wrote: > > 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:
I agree with your read that this is a tautology. > >>>>>> 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/ > > <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. I like Terry’s text as well. A fourth question may be if we see any risk in RPs accepting a EE certificate that has the basic constraints extension with CA bit set to false. The library used by the (deprecated) RIPE NCC RPKI Validator 3 does accept this case and I would expect there to be other RPs that accept certificates with basicConstraints present and containing ca:FALSE. Kind regards, Ties > > —John > >> On May 10, 2022, at 8:46 AM, Terry Manderson <[email protected] >> <mailto:[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://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$ >>> >>> <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 <[email protected] >>>>> <mailto:[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] <mailto:[email protected]>> >>>>> Sent: Wednesday, February 16, 2022 5:23 PM >>>>> To: RFC Errata System <[email protected] >>>>> <mailto:[email protected]>> >>>>> Cc: George Michaelson <[email protected] <mailto:[email protected]>>; >>>>> [email protected] <mailto:[email protected]>; [email protected] >>>>> <mailto:[email protected]>; [email protected] >>>>> <mailto:[email protected]>; [email protected] >>>>> <mailto:[email protected]>; Chris Morrow <[email protected] >>>>> <mailto:[email protected]>>; [email protected] >>>>> <mailto:[email protected]>; Corey Bonnell <[email protected] >>>>> <mailto:[email protected]>>; [email protected] <mailto:[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] >>>>>> <mailto:[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://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6854__;!!NEt6yMaO-gk!Bdgioqq_ZZJbLYpMzziW-hkm1NBZpa0fACOEmjaxS-VZOqYmcCAD-uaXLK73YxlSEU_S8ym75As$ >>>>>> >>>>>> <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 <[email protected] >>>>>> <mailto:[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] <mailto:[email protected]> >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sidrops__;!!NEt6yMaO-gk!Bdgioqq_ZZJbLYpMzziW-hkm1NBZpa0fACOEmjaxS-VZOqYmcCAD-uaXLK73YxlSEU_SIPFE6Uw$ >>>> >>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sidrops__;!!NEt6yMaO-gk!Bdgioqq_ZZJbLYpMzziW-hkm1NBZpa0fACOEmjaxS-VZOqYmcCAD-uaXLK73YxlSEU_SIPFE6Uw$> >>> >>> _______________________________________________ >>> sidr mailing list >>> [email protected] <mailto:[email protected]> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sidr__;!!NEt6yMaO-gk!Bdgioqq_ZZJbLYpMzziW-hkm1NBZpa0fACOEmjaxS-VZOqYmcCAD-uaXLK73YxlSEU_SP-Pd7mQ$ >>> >>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sidr__;!!NEt6yMaO-gk!Bdgioqq_ZZJbLYpMzziW-hkm1NBZpa0fACOEmjaxS-VZOqYmcCAD-uaXLK73YxlSEU_SP-Pd7mQ$> >> > > _______________________________________________ > sidr mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/sidr > <https://www.ietf.org/mailman/listinfo/sidr>
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
