[cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Mon Nov 23 10:35:07 MST 2020
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 <mailto: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
> <mailto: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 <mailto:sleevi at google.com>>;
> CA/Browser Forum Validation SC List <validation at cabforum.org
> <mailto: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 <mailto:sleevi at google.com>>
> *Sent:* Monday, November 16, 2020 16:23
> *To:* Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com
> <mailto:Paul.vanBrouwershaven at entrust.com>>; CA/Browser Forum
> Validation SC List <validation at cabforum.org
> <mailto: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
> <mailto: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 list
> Validation at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/validation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201123/6e7bbeb4/attachment-0001.html>
More information about the Validation
mailing list