> -----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 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, 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
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.

Robin Alden
dev-security-policy mailing list

Reply via email to