Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Certificate OU= fields with missing O= field
884 views
Skip to first unread message
Matthias van de Meent
Nov 1, 2019, 6:08:43 AM11/1/19
to MDSP
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".
BR v1.6.6 § 7.1.4.2.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 3.2.2.1."
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 7.1.4.2.2i correct?
- Matthias
[0] please find attached 3 files which contain a query on the crt.sh
database, with their results ( queried 2019-10-30T10:00:00Z and
T12:00:00Z )
The queries count certificate IDs in the range 1890000000 ...
1900000000 (10M possible certificate IDs), and are filtering
certificates which have an organizationalUnitName <> 'Domain Control
Validated', but not the organizationName field:
- cert_no_dcv: Total count count of the filtered certificate_ids
- cert_by_issuer_no_dcv: Counted, grouped by issuer ID. This can
contain duplicate counts, but only due to multiple issuer_ca_ids per
certificate, which should not exist.
- cert_by_issuer_name_no_dcv: Counted, grouped by issuer &
organizationalUnitName: Certificates may be counted twice here due to
multiple OU entries for one certificate.
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".
BR v1.6.6 § 7.1.4.2.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 3.2.2.1."
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 7.1.4.2.2i correct?
- Matthias
[0] please find attached 3 files which contain a query on the crt.sh
database, with their results ( queried 2019-10-30T10:00:00Z and
T12:00:00Z )
The queries count certificate IDs in the range 1890000000 ...
1900000000 (10M possible certificate IDs), and are filtering
certificates which have an organizationalUnitName <> 'Domain Control
Validated', but not the organizationName field:
- cert_no_dcv: Total count count of the filtered certificate_ids
- cert_by_issuer_no_dcv: Counted, grouped by issuer ID. This can
contain duplicate counts, but only due to multiple issuer_ca_ids per
certificate, which should not exist.
- cert_by_issuer_name_no_dcv: Counted, grouped by issuer &
organizationalUnitName: Certificates may be counted twice here due to
multiple OU entries for one certificate.
Kurt Roeckx
Nov 1, 2019, 6:14:50 AM11/1/19
to Matthias van de Meent, MDSP
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".
>
> BR v1.6.6 § 7.1.4.2.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 3.2.2.1."
>
> 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 7.1.4.2.2i correct?
That OU clearly doesn't have anything to do with the subject that
> 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".
>
> BR v1.6.6 § 7.1.4.2.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 3.2.2.1."
>
> 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 7.1.4.2.2i correct?
was validated, so I also consider that a misissue.
Kurt
Matthias van de Meent
Nov 1, 2019, 10:27:07 AM11/1/19
to MDSP
Hi,
I was notified that the attachments were lost in transmission, so here
are the links:
cert_no_dcv: https://drive.google.com/open?id=1s43AaW5lCkSzbr-If6l2F_gwLkwDVy6w
cert_by_issuer_no_dcv:
https://drive.google.com/open?id=1-er8R2CfcG8CRK4I3KUXnv8PDgGQKc1Y
cert_by_issuer_name_no_dcv:
https://drive.google.com/open?id=1DHwpEwU0qP1FiJx6Wb6L-kMQEIp3atKX
-Matthias
On Fri, 1 Nov 2019 at 11:08, Matthias van de Meent
<matthias....@cofano.nl> 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".
>
> BR v1.6.6 § 7.1.4.2.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 3.2.2.1."
>
> 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 7.1.4.2.2i correct?
>
I was notified that the attachments were lost in transmission, so here
are the links:
cert_no_dcv: https://drive.google.com/open?id=1s43AaW5lCkSzbr-If6l2F_gwLkwDVy6w
cert_by_issuer_no_dcv:
https://drive.google.com/open?id=1-er8R2CfcG8CRK4I3KUXnv8PDgGQKc1Y
cert_by_issuer_name_no_dcv:
https://drive.google.com/open?id=1DHwpEwU0qP1FiJx6Wb6L-kMQEIp3atKX
-Matthias
On Fri, 1 Nov 2019 at 11:08, Matthias van de Meent
<matthias....@cofano.nl> 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".
>
> BR v1.6.6 § 7.1.4.2.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 3.2.2.1."
>
> 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 7.1.4.2.2i correct?
>
Alex Cohn
Nov 1, 2019, 11:13:49 AM11/1/19
to Kurt Roeckx, Matthias van de Meent, MDSP
On Fri, Nov 1, 2019 at 5:14 AM Kurt Roeckx via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
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 7.1.4.2.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 3.2.2.1.
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-secur...@lists.mozilla.org> 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 [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".
> >
> > BR v1.6.6 § 7.1.4.2.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 3.2.2.1."
> >
> > 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 7.1.4.2.2i correct?
>
> 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".
> >
> > BR v1.6.6 § 7.1.4.2.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 3.2.2.1."
> >
> > 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 7.1.4.2.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
> was validated, so I also consider that a misissue.
>
>
> Kurt
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 7.1.4.2.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 3.2.2.1.
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?
Jeremy Rowley
Nov 1, 2019, 11:41:34 AM11/1/19
to mozilla-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 that?
There's no requirement that the OU field information relate to the O field information as long as the information is verified.
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
There's no requirement that the OU field information relate to the O field information as long as the information is verified.
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Ryan Sleevi
Nov 1, 2019, 12:11:40 PM11/1/19
to Jeremy Rowley, mozilla-dev-security-policy
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 7.1.4.2, the section in which this is placed.
As to the <domain>.com in the OU, 7.1.4.2 also prohibits this:
CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute
except as specified in Section 3.2.2.4 or Section 3.2.2.5.
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 7.1.4.2, the section in which this is placed.
As to the <domain>.com in the OU, 7.1.4.2 also prohibits this:
CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute
except as specified in Section 3.2.2.4 or Section 3.2.2.5.
Robin Alden
Nov 1, 2019, 12:12:39 PM11/1/19
to Kurt Roeckx, Matthias van de Meent, mozilla-dev-s...@lists.mozilla.org
> -----Original Message-----
> From: Kurt Roeckx via dev-security-policy
> Sent: 01 November 2019 10:15
> To: Matthias van de Meent <matthias....@cofano.nl>
> Cc: MDSP <dev-secur...@lists.mozilla.org>
> Subject: Re: Certificate OU= fields with missing O= field
>
> From: Kurt Roeckx via dev-security-policy
> Sent: 01 November 2019 10:15
> To: Matthias van de Meent <matthias....@cofano.nl>
> Cc: MDSP <dev-secur...@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".
> >
>
> 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]
> was validated, so I also consider that a misissue.
>
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
Jeremy Rowley
Nov 1, 2019, 12:31:24 PM11/1/19
to ry...@sleevi.com, mozilla-dev-security-policy
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 <ry...@sleevi.com>
Sent: Friday, November 1, 2019 10:11 AM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Certificate OU= fields with missing O= field
https://lists.mozilla.org/listinfo/dev-security-policy
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 <ry...@sleevi.com>
Sent: Friday, November 1, 2019 10:11 AM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: mozilla-dev-security-policy <mozilla-dev-s...@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 7.1.4.2, the section in which this is placed.
As to the <domain>.com in the OU, 7.1.4.2 also prohibits this:
CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute except as specified in Section 3.2.2.4 or Section 3.2.2.5.
As to the <domain>.com in the OU, 7.1.4.2 also prohibits this:
CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute except as specified in Section 3.2.2.4 or Section 3.2.2.5.
On Fri, Nov 1, 2019 at 8:41 AM Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> 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-...@lists.mozilla.org<mailto:dev-security-...@lists.mozilla.org>> On Behalf Of Alex Cohn via dev-security-policy
Sent: Friday, November 1, 2019 9:13 AM
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-...@lists.mozilla.org<mailto:dev-security-...@lists.mozilla.org>> On Behalf Of Alex Cohn via dev-security-policy
Sent: Friday, November 1, 2019 9:13 AM
To: Kurt Roeckx <ku...@roeckx.be<mailto:ku...@roeckx.be>>
Cc: Matthias van de Meent <matthias....@cofano.nl<mailto:matthias....@cofano.nl>>; MDSP <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.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 <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:
Cc: Matthias van de Meent <matthias....@cofano.nl<mailto:matthias....@cofano.nl>>; MDSP <dev-secur...@lists.mozilla.org<mailto:dev-secur...@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".
> >
> 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".
> >
> > BR v1.6.6 § 7.1.4.2.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 3.2.2.1."
> >
> > 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 7.1.4.2.2i correct?
>
> > 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 3.2.2.1."
> >
> > 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 7.1.4.2.2i correct?
>
> That OU clearly doesn't have anything to do with the subject that was
> validated, so I also consider that a misissue.
>
>
> 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 7.1.4.2.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 3.2.2.1.
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
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
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 7.1.4.2.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 3.2.2.1.
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
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
_______________________________________________
dev-security-policy mailing list
https://lists.mozilla.org/listinfo/dev-security-policy
Ryan Sleevi
Nov 1, 2019, 2:33:49 PM11/1/19
to Jeremy Rowley, ry...@sleevi.com, mozilla-dev-security-policy
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...@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 <ry...@sleevi.com>
> *Sent:* Friday, November 1, 2019 10:11 AM
> *To:* Jeremy Rowley <jeremy...@digicert.com>
> *Cc:* mozilla-dev-security-policy <
> mozilla-dev-s...@lists.mozilla.org>
> *Subject:* Re: Certificate OU= fields with missing O= 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...@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.
>
>
>
> *Sent:* Friday, November 1, 2019 10:11 AM
> *To:* Jeremy Rowley <jeremy...@digicert.com>
> *Cc:* mozilla-dev-security-policy <
> mozilla-dev-s...@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 7.1.4.2, the section in which this is placed.
>
>
>
> As to the <domain>.com in the OU, 7.1.4.2 also prohibits this:
>
> CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute
> except as specified in Section 3.2.2.4 or Section 3.2.2.5.
>
>
>
> On Fri, Nov 1, 2019 at 8:41 AM Jeremy Rowley via dev-security-policy <
>
>
> 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 7.1.4.2, the section in which this is placed.
>
>
>
> As to the <domain>.com in the OU, 7.1.4.2 also prohibits this:
>
> CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute
> except as specified in Section 3.2.2.4 or Section 3.2.2.5.
>
>
>
> On Fri, Nov 1, 2019 at 8:41 AM Jeremy Rowley via dev-security-policy <
> dev-secur...@lists.mozilla.org> 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-...@lists.mozilla.org>
> On Behalf Of Alex Cohn via dev-security-policy
> Sent: Friday, November 1, 2019 9:13 AM
> To: Kurt Roeckx <ku...@roeckx.be>
> Cc: Matthias van de Meent <matthias....@cofano.nl>; MDSP <
> dev-secur...@lists.mozilla.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 <
>
> 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-...@lists.mozilla.org>
> On Behalf Of Alex Cohn via dev-security-policy
> Sent: Friday, November 1, 2019 9:13 AM
> To: Kurt Roeckx <ku...@roeckx.be>
> Cc: Matthias van de Meent <matthias....@cofano.nl>; MDSP <
> dev-secur...@lists.mozilla.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 <
> https://lists.mozilla.org/listinfo/dev-security-policy
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
>
>
Jakob Bohm
Nov 1, 2019, 5:38:08 PM11/1/19
to mozilla-dev-s...@lists.mozilla.org
[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
validity).
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.
Enjoy
Jakob
--
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
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
validity).
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.
Jakob
--
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
0 new messages