John, Thanks for the pragmatic approach - personally I would advocate for "hold for update" as I don't believe there is any nuance to the behaviour of the issuer [to answer question #1] - it is thus (from my interpretation) a wording and logic framing concern [ending at result #3] at most.
T. > On 11 May 2022, at 1:07 am, John Scudder <j...@juniper.net> 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: > >>>>>> 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
