[cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements

Mon Nov 23 11:45:12 MST 2020

Hi Dimitris,

I understand we have different viewpoints, and despite past attempts to
help you understand the systemic issues, it appears we will not resolve
them.

Our focus is to ensure all information included in certificates is
necessary and has been validated against well-defined, interoperable
criteria. Entrust's latest proposal fails on both those very simple tests,
being neither well-defined nor interoperable, as have their previous
efforts. I can understand that some CAs would prefer a single PKI to serve
multiple distinct purposes, but despite good-faith efforts on establishing
the rationale for such information, the provided explanations are weak, at
best, although many fall into the long-discredited approach to "risk
management" that says "There is no risk until something goes wrong". As it
stands, nearly half of the CA security incidents we see are related to
approaches and proposals similar to what's proposed here for OU, and
frankly, that's not acceptable to continue. You can see Ben Wilson's
presentation at our recent F2F, in the event you'd like to know more about
those statistics.

For every CA we trust, we want to make sure they're operating a
well-defined PKI, with a clear set of purposes and constituencies. While
certificates can be used to express a wide variety of information, it's
best to ensure separate protocols (e.g. TLS vs S/MIME), separate naming
scopes (e.g. legal identity, domain identity, application identity), and
user communities (e.g. payment terminals, web browsers, banking industry)
use separate PKIs. "PKI" is merely a collection of related technologies,
but the successful deployment requires care across all of those dimensions,
and attempting to combine them has, over the past 25 years, shown
repeatedly the security risks that can come from it.

You are correct for recognizing that, at the core, this is a question about
identity in certificates. However, this is not merely a disagreement, but
one that touches on the heart of the security of every user, as it affects
a multitude of security principles: from the ability to easy replace
certificates (e.g. not having to undergo complex identity vetting processes
for information that is not programatically used), the ability to easily
change CAs (in which the identity validating processes are used to raise
the complexity in changing to a better CA), to the need and frequency of
replacing certificates (due to CAs failing to follow the procedures they
themselves helped draft). These principles have a direct impact on user
security, and these are things we take very seriously.

When it comes to the CAs that we partner with and include out-of-the-box in
a fresh install, without requiring the user to take any explicit action to
install or configure, our intent is to work with CAs that share that common
goal, and understand that this is an ecosystem issue. I understand the
appeal of "If you don't like the certificate, don't trust it", but it's
much easier, safer, and interoperable to simply not partner with CAs that
only produce "good" results 50% of the time, then it is to try to add
complexity (and risk) to end users by trying to reject the insecure 50%.
This doesn't prevent the organization from issuing such certificates, but
does limit whether or not such "roots" are candidates for inclusion.

This is no different from how, out of the box, modern web browsers don't
support Gopher, or increasingly, FTP: if you want to use those protocols,
you have to take an added action to install or configure an
application/extension for them. PKI technologies, such as certificates, are
not a protocol or a singular solution; they're a set of tools and
techniques used to define different protocols. Just as the travel document
PKI <https://www.icao.int/publications/pages/publication.aspx?docnum=9303>
has a vastly different set of constraints than a PKI used for datacenter
authentication between virtual machines <https://spiffe.io/>, even though
both use "PKI" and "certificates", when it comes to our browser product,
our goal in the set of CAs we support is to limit the demands on
sophistication/attentiveness of users, ensure security out of the box,
automate security checks
<https://tools.ietf.org/html/draft-ietf-pkix-ipki-00#section-2.3>, and
treat it as a holistic, systems issue, rather than one-offs. When it comes
to web browsers, these requirements and needs have been known for decades,
and on a technical level, such proposals simply don't match how the
technology works
<https://www.ccadb.org/documents/Qualified_Website_Authentication_Certificates_Interoperability.pdf>
.

The Baseline Requirements do not, nor have they ever, permitted CAs to
include unverified, self-attested information. Every piece of information
included in a certificate has a requirement to be validated by the CA, as
captured by 7.1.2.4 of the BRs, as well as more specific individual
requirements. It is unfortunate that a CA needs to be reminded of this, or
of the principles and motivations, and this applies equally to LEI, OU, or
any other field or data the CA might imagine here.

On Mon, Nov 23, 2020 at 12:35 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
>
> On 23/11/2020 5:23 μ.μ., Ryan Sleevi via Validation wrote:
>
>
>
> On Mon, Nov 23, 2020 at 6:58 AM Doug Beattie <doug.beattie at globalsign.com>
> wrote:
>
>> Paul,
>>
>>
>>
>> This does not address Ryan’s concerns he’s previously stated, so I doubt
>> it’s really advancing the cause.
>>
>
> Wholeheartedly agreed. This continues to be a facile attempt to dismiss
> two years of thoughtful collaboration in order to advance a discredited
> idea that harms user security and server agility.
>
>
>> Ryan: I’m thinking the use of a private extension for this type of data
>> (including LEIs and other industry desired data) that cannot be validated
>> in accordance with the BRs (section 3.2) might be a good approach, similar
>> to the QCStatement extension.  Would you have any serious objections to
>> the long term use of a private extension which the browsers can ignore for
>> conveying this type of data?
>>
>
> Yes.
>
>
>
> I believe that the organizationalUnitName field is an extension of the
> organizationName field for larger organizations, especially governmental
> structures. This group has not seen any evidence in the past several years
> where using OU in end-entity TLS certificates has caused any user security
> harm. Perhaps there were discussions in m.d.s.p. or other Forums about
> users claiming they were deceived by following information in the OU
> fields. Even when this field was used to convey tracking information or
> displaying the policy validation level in a more humanly readable manner
> ("This Certificate is Domain/Organization/Extended Validated") used by some
> CAs, I don't remember users reporting anything about security harm. HARICA
> has been using OU fields in OV Certificates for the last 10 years and we've
> never received a report from a Relying Party that they were misguided or
> harmed in any way because of information in the OU field.
>
> Entrust's proposal is trying to make improvements to the current BRs
> practice which a significant part of Internet Certificate Subscribers use
> today. Assuming that Identity in Certificates is of some use (some think it
> is useful and some think it's not; we're not going to solve this problem on
> this thread), Relying Parties that check the information in certificates
> can see which Organizational Unit of the validated Organization is
> responsible for the site/certificate. Just like they do with the
> countryName, stateOrProvinceName, localityName and organizationName, they
> can see useful information in the organizationalUnitName field.
>
> It is self-reported information by the Applicant, but the risk of adding
> harmful or misleading data is significantly mitigated by the proposed
> language of the ballot.
>
> There is probably not going to be 100% consensus on this proposal so
> perhaps the best way forward is to proceed with the ballot and see how it
> goes.
>
> Ryan's last response on the extension proposal is not clear whether it has
> to do with something "similar to the QCStatement" or if there are serious
> objections to any type of extension. I was hoping that since the BRs allow
> custom extensions to be defined by CAs (and how CAs validate this
> information), it would be allowed for a CA to include an extension that is
> designed -say- for the EV Profile, like the CABFSelectedAttributeTypes
> extension, and include the LEI value. Ryan, can you please clarify?
>
>
> Thanks you,
> Dimitris.
>
>
>
>>
>> *From:* Validation <validation-bounces at cabforum.org> *On Behalf Of *Paul
>> van Brouwershaven via Validation
>> *Sent:* Monday, November 23, 2020 4:00 AM
>> *To:* Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Validation SC
>> List <validation at cabforum.org>
>> *Subject:* Re: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve
>> OU validation requirements
>>
>>
>>
>> I created a version to address the highlighted concerns on the usage of
>> the word 'equivalent' and the validation of trademarks and trade/business
>> names.
>>
>> This version:
>>
>>    - is using a *fixed set* of pre/suffix values
>>    - includes a requirement for a *certified translation* for the
>>    equivalent in a language other than English
>>    - requires the CA to check the value in the WIPO Global Brand
>>    Database and the local business registry
>>
>> Proposed OU validation requirements:
>>
>> *If the Subject Identity Information is to include an organizational
>> unit, then it MUST be preceded or followed by a whitespace and one of the
>> words “unit”, “department”, “division”, “group”, “service", "system",
>> "center", "office", “school”, “faculty”, "administration", "operations” in
>> singular or plural form; or a certified translation of the equivalent in a
>> language other than English. *
>>
>> *The CA MUST verify the existence and affiliation of the organizational
>> unit with the Applicant using an Organizational Chart provided by an
>> authoritative source within the Applicant's organization, such as the
>> Applicant's main business offices, corporate offices, human resource
>> offices, information technology offices, or other department that the CA
>> deems appropriate. *
>>
>> *If a value holds an active registration in the ‘WIPO Global Brand
>> Database’ or a local business register the CA MAY only include these
>> registered values when the CA has verified the right of usage in relation
>> to the Application in accordance with Section 3.2. *
>>
>> *The value SHALL not be abbreviated unless this would exceed the maximum
>> length of the `subject:organizationalUnitName` field, in which case it
>> SHALL only use locally accepted abbreviation. *
>>
>>
>>
>> Please share your thoughts about this version.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Paul
>> ------------------------------
>>
>> *From:* Ryan Sleevi <sleevi at google.com>
>> *Sent:* Monday, November 16, 2020 16:23
>> *To:* Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com>;
>> CA/Browser Forum Validation SC List <validation at cabforum.org>
>> *Subject:* Re: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve
>> OU validation requirements
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Nov 16, 2020 at 10:12 AM Paul van Brouwershaven via Validation <
>> validation at cabforum.org> wrote:
>>
>> I have been thinking about a more simplistic and strict approach that
>> doesn't follow all the current allowed methods listed in section 3.2 of the
>> BR like we have proposed currently.
>>
>>
>>
>> As with every other proposal Entrust has offered to date, this doesn't
>> actually address the problem inherent to any use of this field, which is
>> that it's unverified, unvetted data, as there is *no* way to validate and
>> vet it.
>>
>>
>>
>> The most recent proposal reflects a thoroughly-debunked theater exercise
>> to security, which is to rely on statements like "The user should
>> understand that ...". It attempts to absolve the CA of the responsibility
>> for not placing unverified data in certificates in the first place, by
>> trying to make it the user's responsibility on distinguishing that data
>> from other fields and making an informed decision. Thankfully, this has
>> been shown to be a theater exercise that harms users, so I feel like it's
>> reasonable to simply reject it outright.
>>
>>
>>
>> If that were not troubling enough, however, I think it also bears
>> mentioning that this approach continues with one which has been firmly
>> discredited, and which we've been actively moving away from in the Forum
>> since the Forum's very creation, which is the introduction of significant
>> interpretation differences and leeway. "and an equivalent of the word ... "
>> and "in the equivalent of the language" should best be read as "any other
>> method", and much like how "but" serves to negate that which precedes it in
>> a sentence, the "an equivalent" serves to negate any presumption of any
>> rigor described.
>>
>>
>>
>> This isn't progress on any measured dimension of providing rigor or
>> addressing the fundamental issues, and is an attempt to preserve the status
>> quo without actually addressing the issues. I'm glad Entrust is now
>> interested in this space, but this approach was discussed as far back as
>> London in 2018, during the WG day, and highlights the problematic approach.
>>
>>
>>
>> And, in the spirit of completely missing the problem space, it does
>> nothing to address the fact that the following language is, practically
>> speaking, unimplementable: "It SHALL NOT include 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 relation to the Application accordance with Section 3.2."
>>
>
> _______________________________________________
> Validation mailing listValidation at cabforum.orghttps://lists.cabforum.org/mailman/listinfo/validation
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201123/8a1d24f0/attachment-0001.html>