> -----Original Message-----
> From: Kurt Roeckx via dev-security-policy
> Sent: 01 November 2019 10:15
> To: Matthias van de Meent <matthias.vandeme...@cofano.nl>
> Cc: MDSP <dev-security-policy@lists.mozilla.org>
> Subject: Re: Certificate OU= fields with missing O= field
>
> 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 [0] 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".
> >
>
> That OU clearly doesn't have anything to do with the subject that
> was validated, so I also consider that a misissue.
>
[Robin Alden]
Kurt, Matthias,
We are aware of 7.1.4.2 i. but we had not read it the same way.
We originally read it as saying that where information pertaining to the
subject organization was included in an OU field:
a) That information must be validated per 3.2.2.1, and
b) It must only be included in an OV or EV certificate, i.e. it could not be
included in DV.
Looking at it now, it seems to say that you can only have meaningful,
validated, OU information in a certificate which is either OV or EV, and which
also includes subject:givenName and subject:surname attributes.
That seems to be a very limited subset.
The BR language around OUs (apart from the givenName and surname) was proposed
in 2012, and that is probably the last time we evaluated it from scratch.
Other interpretations are definitely possible.
If the prohibition on name, tradename, trademark, address, etc., is not
intended to apply to the subject organization then it is hard to see how you
would verify it under 3.2.2.1.
We believed that the prohibition was there to bolster the CA Warranty (9.6.1
4) that the CA (i) implemented a procedure for reducing the likelihood that the
information contained in the Certificate's subject:organizationalUnitName
attribute would be misleading.
Regards
Robin Alden
Sectigo
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
