[Top posting because previous post did]
As a relying party and a subscriber of some certificates, I would
consider each of the following combinations as something that should be
both permitted and useful under any future rules, even if the current
BRs don't allow it.
1. O=Actual Org name and OU=An actual company name for a division that
is not obviously misleading, for example "HQ", "Accounting", "East
campus", "Virginia servers", even if there is no direct way for any
regular CA to verify the reality at time of issuance (will that
certificate actually be used only at the company HeadQuarters? Does
the organization actually have an accounting department other than an
old shoe-box filled with receipts, do they really have any servers in
either of the Virginia states?).
2. O=Actual Org name, OU=Actual company division, GivenNameEtc=An actual
person in that division.
3. O=Actual Org name, OU=Actual company division, No specific individual
listed because certificate is for entire division.
4. OU=Domain Validated or OU=Extended Validation etc. to indicate the
level of validation to relying parties that lack the skills to extract
this from the more formal fields such as policy OIDs. While this is
not in itself the subject identity, it is a hierarchical part of a
structured designation of the subject, similar to adding ST=California
to a DN that already contains L=Los Angeles and C=US.
5. 1, 2 or 3 combined with 4
The following would not be allowed:
6. OU=Google when the subject is not part of that company and has no
rights to that trademark.
7. OU=Ministry of Defence when the subject is not a (quasi) government
that could have such.
The following would be routinely revoked as no-longer-valid-but-not-
a-CA-incident if later discovered. (Similar to the BR rules about a
subscriber loosing their legal domain control during certificate
8. OU="Virginia servers" when it is found that the subject owns or
operates no servers in the Virginia States. Further sanctions against
subject would depend if the certificate was ever used elsewhere and if
the subject had actual servers in Virginia at a different time and
used the cert only for those.
9. Similar to 8 but for other such cases, see 1. for examples.
On 01/11/2019 17:31, Jeremy Rowley 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
Subject Identity Information is defined as information that identifies the
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
220.127.116.11, the section in which this is placed.
As to the <domain>.com in the OU, 18.104.22.168 also prohibits this:
CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute except
as specified in Section 22.214.171.124 or Section 126.96.36.199.
On Fri, Nov 1, 2019 at 8:41 AM Jeremy Rowley via dev-security-policy
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
There's no requirement that the OU field information relate to the O field
information as long as the information is verified.
On Behalf Of Alex Cohn via dev-security-policy
Sent: Friday, November 1, 2019 9:13 AM
To: Kurt Roeckx <k...@roeckx.be<mailto:k...@roeckx.be>>
Cc: Matthias van de Meent
Subject: Re: Certificate OU= fields with missing O= field
On Fri, Nov 1, 2019 at 5:14 AM Kurt Roeckx via dev-security-policy
On Fri, Nov 01, 2019 at 11:08:23AM +0100, Matthias van de Meent via
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 § 188.8.131.52.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 184.108.40.206."
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 220.127.116.11.2i correct?
That OU clearly doesn't have anything to do with the subject that was
validated, so I also consider that a misissue.
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 18.104.22.168.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
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
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
dev-security-policy mailing list