Yes. I'm concerned about an interpretation that says the Subject field doesn't identify the Subject, while also being sensitive to past discussions (e.g. dnQualifier) that are explicitly specified not to identify the Subject. The OU, as specified both in the BRs and within the relevant ITU-T standards, seems to make it clear it's Subject Identity Information.
The BRs place prohibitions on when it can appear, as well as prohibitions on certain type of content that can appear. Despite these prohibitions, it does grant significant flexibility into arbitrary content, provided it fits those constraints - but some of the content being discussed seems to clearly violate the requirements. It sounds like we're in agreement there? On Fri, Nov 1, 2019 at 12:31 PM Jeremy Rowley <jeremy.row...@digicert.com> wrote: > My view is that the OU field is a subject distinguished name field and > that a CA must have a process to prevent unverified information from being > included in the field. > > > > Subject Identity Information is defined as information that identifies the > Certificate Subject. > > > I suppose the answer to your question depends on a) what you consider as > information that identifies the Certificate Subject and b) whether the > process required establishes the minimum relationship between that > information and your definition of SII. > > > > *From:* Ryan Sleevi <r...@sleevi.com> > *Sent:* Friday, November 1, 2019 10:11 AM > *To:* Jeremy Rowley <jeremy.row...@digicert.com> > *Cc:* mozilla-dev-security-policy < > mozilla-dev-security-pol...@lists.mozilla.org> > *Subject:* Re: Certificate OU= fields with missing O= field > > > > Is your view that the OU is not Subject Identity Information, despite that > being the Identity Information that appears in the Subject? Are there other > fields and values that you believe are not SII? This seems inconsistent > with 188.8.131.52, the section in which this is placed. > > > > As to the <domain>.com in the OU, 184.108.40.206 also prohibits this: > > CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute > except as specified in Section 220.127.116.11 or Section 18.104.22.168. > > > > On Fri, Nov 1, 2019 at 8:41 AM Jeremy Rowley via dev-security-policy < > email@example.com> wrote: > > A mistake in the BRs (I wrote the language unfortunately so shame on me > for not matching the other sections of org name or the given name). There's > no certificate that ever contains all of these fields. How would you ever > have that? > > There's no requirement that the OU field information relate to the O field > information as long as the information is verified. > > -----Original Message----- > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Alex Cohn via dev-security-policy > Sent: Friday, November 1, 2019 9:13 AM > To: Kurt Roeckx <k...@roeckx.be> > Cc: Matthias van de Meent <matthias.vandeme...@cofano.nl>; MDSP < > firstname.lastname@example.org> > Subject: Re: Certificate OU= fields with missing O= field > > On Fri, Nov 1, 2019 at 5:14 AM Kurt Roeckx via dev-security-policy < > email@example.com> wrote: > > > > On Fri, Nov 01, 2019 at 11:08:23AM +0100, Matthias van de Meent via > dev-security-policy wrote: > > > Hi, > > > > > > I recently noticed that a lot of leaf certificates  have > > > organizationalUnitName specified without other organizational > > > information such as organizationName. Many times this field is used > > > for branding purposes, e.g. "issued through <someone's kpi manager>" > > > or "SomeBrand SSL". > > > > > > BR v1.6.6 § 22.214.171.124.2i has guidance on usage of the OU field: "The > > > CA SHALL implement a process that prevents an OU attribute from > > > including a name, DBA, tradename, trademark, address, location, or > > > other text that refers to a specific natural person or Legal Entity > > > unless the CA has verified this information in accordance with > > > Section 3.2 and the Certificate also contains > > > subject:organizationName, , subject:givenName, subject:surname, > > > subject:localityName, and subject:countryName attributes, also > > > verified in accordance with Section 126.96.36.199." > > > > > > As the organizationName and other related attributes are not set in > > > many of those certificates, even though e.g. "COMODO SSL Unified > > > Communications" is a very strong reference to Sectigo's ssl branding > > > & business, I believe the referenced certificate is not issued in > > > line with the BR. > > > > > > Is the above interpretation of BR section 188.8.131.52.2i correct? > > > > That OU clearly doesn't have anything to do with the subject that was > > validated, so I also consider that a misissue. > > > > > > Kurt > > A roughly-equivalent Censys.io query, excluding a couple other unambiguous > "domain validated" OU values: "not _exists_: > parsed.subject.organization and _exists_: > parsed.subject.organizational_unit and not > parsed.subject.organizational_unit: "Domain Control Validated" and not > parsed.subject.organizational_unit: "Domain Validated Only" and not > parsed.subject.organizational_unit: "Domain Validated" and > validation.nss.valid: true" returns 17k hits. > > IMO the "Hosted by ____.Com" certs fail 184.108.40.206.2i - the URL of a web host > is definitely "text that refers to a specific ... Legal Entity". > > > Certificate also contains subject:organizationName, , > > subject:givenName, subject:surname, subject:localityName, and > > subject:countryName attributes, also verified in accordance with Section > 220.127.116.11. > > I'm pretty sure this isn't what the BRs intended, but this appears to > forbid issuance with a meaningful subject:organizationalUnitName unless all > of the above attributes are populated. EVG §9.2.9 forbids including those > attributes in the first place. Am I reading this wrong, or was this an > oversight in the BRs? > _______________________________________________ > dev-security-policy mailing list > firstname.lastname@example.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ > dev-security-policy mailing list > email@example.com > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ dev-security-policy mailing list firstname.lastname@example.org https://lists.mozilla.org/listinfo/dev-security-policy