Revision of subject:organizationalUnitName

[vanbroup]

Draft Ballot SCXX: Improve OU validation requirements

As discussed on the last CA/Browser Forum call last week, we would like to retain the OU field. Our enterprise customers have indicated (using a survey) to rely on this field for identifying certificate owners in large organizations and governments.

With this ballot we try to align the subject:organizationalUnitName with the purpose as described by the ITU-T X.520 section 6.4.2 Organizational Unit Name.

A few explanations, this ballot:

1. introduces a requirement to verify the existence and affiliation of the unit with the Applicant
2. prevents misinterpretations by requiring self-reported values to be preceded or followed by a whitespace and the well-known words “department”, “division”, “unit” or ...
3. supports automation by linking to a directory system of the applicant and by allowing well-known pre-approved values such as “information technology”, “marketing” or “sales”.
4. supports manual validation using authoritative sources, an organization charts or public directory (e.g. https://www.gov.ie/en/help/departments/)
5. allows values or series as defined by a government, standard, or regulatory body
6. allows certificate tracking using numerals which can be preceded or followed by two alphabetical characters for easier identification.

I'm curious for feedback on these proposed changes and looking for potential endorsers for providing a ballot to the CA/Browser Forum's Server Certificate Working Group as a whole.

[sleevi]

Thanks Paul. While an interesting approach, it seems it suffers many of the security failures that, as an industry, we’ve recognized are not acceptable to the security of users.

Pragmatically, these issues are obvious:

• Divergence among CAs between values
  The disclosure requirements adopted by EV are precisely to forbid per-CA lists, which vary in quality and consistency, and was done to explore a path towards industry standardization of recognized values.
• Incomplete validation
  The validation sources, modeled after corporate validation, incorrectly and inappropriately assume that the third-party source is actual authoritative for the values and takes appropriate steps to disambiguate. While this is presumed true, even though in many cases demonstrably false, with respect to company name and address (e.g. Companies House lack of validation), this is easily seen as untrue with respect to OU.
• Presumes global uniqueness without a tangible way to validate
  This draft ignores the many valuable discussions to date with respect to the inherently global nature of what this field “must not” contain, with no practical means to achieve. As such, while it might appear appealing, and might be materially misrepresented by CAs as proof that trade names and trademarks can’t be included, there’s inherently no way to practically achieve that to an appropriate level.
• Continues to make validation a delegatable task, assuming third parties such as attestation letters or utility bills are reasonable degrees of validation.
  Attestation letters were explicitly removed from domain validation because of their lack of reliability, and the same inherently applies to organization validation. CAs understandably value them, as it allows them to assign blame to the third-party with zero accountability to the CA (e.g. there’s no penalty to the CA is the letter makes a “mistake”, while if the CA themselves validated, they would of course be expected to be accountable). Similarly, the ability to add arbitrary data to the address field of a utility bill (e.g. “c/o Sleevi’s awesome department”) should be obvious as an insufficient level of validation.

Ultimately, this ballot appears to cobble together the areas of the Baseline Requirements that are already known to be weak and unreliable, and, much like the mortgage-backed securities that lead to the financial crisis of 2007/2008, hope that relying parties will believe that “a bundle of categorically risky and weak assets/requirements make it a AAA bundle, because of how many there are”

While we appreciate this ballot for discussion, it also fails the most fundamental and basic task, which is capturing the functional use case for the injection of this arbitrary data. As such, we remain strongly opposed, as this ballot will harm the security of our users, the trust in certificates, and the reliability of data there-in.

[vanbroup]

Thanks for you feedback Ryan.

As stated in the description of the PR, this ballot is intended to address the concerns our enterprise subscribers have shared. They clearly indicated that the most fundamental and basic task of the OU field is exactly how it's described by the ITU-T X.520 in section 6.4.2:

... it identifies an organizational unit with which the named object is affiliated.

For large organisations its hard to identity the owner of a certificate. This becomes even harder when certificates are issued by a variety of certificate authorities. The subject:organizationalUnitName is the official designated field to address this problem.

• Divergence among CAs between values
  The disclosure requirements adopted by EV are precisely to forbid per-CA lists, which vary in quality and consistency, and was done to explore a path towards industry standardization of recognized values.

This follows the Disclosure of Verification Sources of the EV guidelines with the intent to stay consistent.

With the agreement from other members, we can instead use a list managed by the CA/Browser forum. The main reason to maintain a list is to not include a list of values within the section itself.

• Incomplete validation
  The validation sources, modeled after corporate validation, incorrectly and inappropriately assume that the third-party source is actual authoritative for the values and takes appropriate steps to disambiguate. While this is presumed true, even though in many cases demonstrably false, with respect to company name and address (e.g. Companies House lack of validation), this is easily seen as untrue with respect to OU.

This is a currently accepted usage, please create a new ballot if you would like to address this in the current document.

• Presumes global uniqueness without a tangible way to validate
  This draft ignores the many valuable discussions to date with respect to the inherently global nature of what this field “must not” contain, with no practical means to achieve. As such, while it might appear appealing, and might be materially misrepresented by CAs as proof that trade names and trademarks can’t be included, there’s inherently no way to practically achieve that to an appropriate level.

More importantly it also clearly states what it should contain and how this must be validated. Concrete and actual improvements are welcome.

• Continues to make validation a delegatable task, assuming third parties such as attestation letters or utility bills are reasonable degrees of validation.

This is a currently accepted usage, please create a new ballot if you would like to address this in the current document.

Attestation letters were explicitly removed from domain validation because of their lack of reliability, and the same inherently applies to organization validation. CAs understandably value them, as it allows them to assign blame to the third-party with zero accountability to the CA (e.g. there’s no penalty to the CA is the letter makes a “mistake”, while if the CA themselves validated, they would of course be expected to be accountable). Similarly, the ability to add arbitrary data to the address field of a utility bill (e.g. “c/o Sleevi’s awesome department”) should be obvious as an insufficient level of validation.

This is a currently accepted usage, please create a new ballot if you would like to address this in the current document.

Ultimately, this ballot appears to cobble together the areas of the Baseline Requirements that are already known to be weak and unreliable, and, much like the mortgage-backed securities that lead to the financial crisis of 2007/2008, hope that relying parties will believe that “a bundle of categorically risky and weak assets/requirements make it a AAA bundle, because of how many there are”

This proposal does indeed follow existing requirements of the Baselines, if these existing requirements are deemed not sufficient these can be addressed in a different ballot. For now, we think this is a good improvement of the existing organizational unit requirements.

While we appreciate this ballot for discussion, it also fails the most fundamental and basic task, which is capturing the functional use case for the injection of this arbitrary data. As such, we remain strongly opposed, as this ballot will harm the security of our users, the trust in certificates, and the reliability of data there-in.

You are welcome to vote NO when this comes to a ballot.

We strongly feel that this ballot addresses the functional use case as indicated by the ITU-T X.520 section 6.4.2 and certificate subscribers.

We would like to review this ballot with the wider members of this forum, with the intent of improving the current requirements and validation of an organizational unit when included in the Subject Identity Information.

[sleevi]

For large organisations its hard to identity the owner of a certificate. This becomes even harder when certificates are issued by a variety of certificate authorities.

Thank you for clarifying this. As the only use case is to "help large organizations manage a certificate", this was a use case that was discussed extensively within the CA/Browser Forum. There are many other technical approaches to this, which do not impose the security risk to users from allowing poorly validated data that is not relevant to establishing TLS connections.

It is important to make sure these use cases are established first and foremost, and it's clear that viable technical alternatives exist. We do not see there being a path forward where we can support this usage.

This follows the Disclosure of Verification Sources of the EV guidelines with the intent to stay consistent.

Yes, I'm aware of why Entrust proposed this. However, it would appear Entrust is unaware of why the Validation WG took the approach it did, and failed to recognize that the approach was to deal with a failure to validate even the most basic of information, such as state and country. It can thus be safely said Entrust's proposal fails to address the substantive concerns.

• Incomplete validation
  The validation sources, modeled after corporate validation, incorrectly and inappropriately assume that the third-party source is actual authoritative for the values and takes appropriate steps to disambiguate. While this is presumed true, even though in many cases demonstrably false, with respect to company name and address (e.g. Companies House lack of validation), this is easily seen as untrue with respect to OU.

This is a currently accepted usage, please create a new ballot if you would like to address this in the current document.

This is a response without substance or, unfortunately, understanding of the concern, and I was specifically trying to address such a misguided and confused response.

To help spell this out clearer:

• The current validation methods assume the third-party data sources used are adequate to validate legal incorporation data, such as organization name and address
  • They are, in fact, insufficient, and the Forum has had ample discussions about flaws with each of those sources
• However, even if each of those sources were to be infallable, in every case, the organizationalUnit is not something that these sources validate
  • As such, they are wildly inappropriate to propose for this ballot and this field.

To help better explain this, it would be like using my passport to validate my favorite breakfast meal. Just because my passport can be used to validate my legal status at a border crossing, it has no bearing on my breakfast preferences. Further, as anyone who has ever worked with a toddler can tell you, people's breakfast preferences change and can easily be made-up nonsense, and so the notion of validating my favorite breakfast is a-priori laughably flawed.

More importantly it also clearly states what it should contain and how this must be validated. Concrete and actual improvements are welcome.

This is demonstrably false. It does not clearly state how something must be validated, it only makes a brief reference to validation sources and the continued use of unvalidable criteria. Furthermore, those validation sources have no bearing whatsoever on validation of the data you propose, which is the entire point of using a validation source: The use of these sources is because they're relevant to the data being validated, but no source you've provided is that, nor can they be.

I appreciate your call to collaboration, but the premise is so deeply flawed that there is not a common ground. I suspect this may be a result of Entrust's failure to participate in the years of discussion, which would have allowed them to better understand the challenges and flaws.

We strongly feel that this ballot addresses the functional use case as indicated by the ITU-T X.520 section 6.4.2 and certificate subscribers.

The appeal to X.520 has no relevance here, and demonstrates a profound lack of technical understanding that goes back to the very introduction of certificates within SSL. The use of the Distinguished Name is directly tied to the notion of the non-existent X.500 global directory, which itself was proposed as a manifestation of Kohnfelder's proposed implementation of the Hellman/Diffie Public File. The profile of certificates, adopted in RFC 2459 through to the subsequent (and current) RFC 5280 took an approach that exclusively relied on the Subject Alternative Name for purposes of naming within IETF protocols, and within the appropriate naming scope, and the inclusion of the Distinguished Name was solely to allow potential interoperability with the X.500 directory, should it manifest. Further, the inclusion of these fields within X.509 was not intended to itself provide details about the named entity, but to locate information within the global X.500 directory, with the semantics of the Distinguished Name largely being supplanted by the extended attributes available within the DAP.

So if the appeal is going to be to X.520, then it's necessary to demonstrate an understanding about why X.520 exists, and how it was intended to be used, which this ballot fails to do.

However, regardless of whether or not it addresses the perceived use case, the past several years of discussion have shown the risks to this approach. Whether it is intentional dismissiveness, unintentional ignorance, or simply complete disregard, this failure of this Ballot to show even a basic attempt to address the substance of the concerns raised is deeply troubling, in that it does not appear Entrust is committed to collaborative approaches. If it were, then one might have hoped for a greater demonstration of that, by demonstrating awareness and understanding of the ample concerns that have been raised about why such naive approaches are flawed.

I would encourage Entrust to be more active in participation in these discussions, and to raise questions if they have concerns or confusion about statements. As it relates to this problem, it appears Entrust has overlooked the fact that there is no canonical source for this information other than the organization itself, and as such, by definition, cannot be validated by a CA, no more than anyone can "correctly validate" my self-reported, ever-changing favorite breakfast meal. Further, as my choice in breakfast preference has no bearing on the establishment of a secure connection to browsers, much like this OU field does not, it underscores the opportunity that Entrust has to explore meaningful alternative technical approaches to helping their customers manage their certificates. This approach, which requires no modification to certificates whatsoever, better serves both communities.

[RufusJWB]

For large organisations its hard to identity the owner of a certificate. This becomes even harder when certificates are issued by a variety of certificate authorities.

Thank you for clarifying this. As the only use case is to "help large organizations manage a certificate", this was a use case that was discussed extensively within the CA/Browser Forum. There are many other technical approaches to this, which do not impose the security risk to users from allowing poorly validated data that is not relevant to establishing TLS connections.

It is important to make sure these use cases are established first and foremost, and it's clear that viable technical alternatives exist. We do not see there being a path forward where we can support this usage.

If I may give you one example from a large enterprise: We at Siemens informed our internal customers in July that from October on the OU field will be retired for publicly trusted TLS certificates. We expected a lot of discussions and escalations but we got no negative feedback at all. Everybody just accepted it. I was really surprised. That's why I'm sharing this experience here.

[chemalogo]

AC Firmaprofesional will endorse this Ballot.

OU field is not only useful for large organizations but also mandatory for a specific type of website certificates for the Spanish Public Administration: https://administracionelectronica.gob.es/pae_Home/dam/jcr:474ae40a-fe06-45fa-aa8f-113049e9c889/2016_Perfiles_de_certificados_1-ed.pdf. Unfortunately the text is only available in Spanish but I would like to draw your attention to page 37 (R means 'Required'. and 'Sí' means 'Yes').

Up to two OU entries are required.

IMHO, the justification of Security issues is not sound and the real underlying reason is to make the certificates smaller.

When we put ourselves in Browser's shoes, we clearly understand the need of lightweight certificates on the Web PKI. It is clear when you read the rationale behind it at:

• https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html

and

• https://www.ccadb.org/documents/Qualified_Website_Authentication_Certificates_Interoperability.pdf

but making certificates smaller and smaller at any cost, without considering the needs of the Organizations publishing their websites and protecting them with certificates, I do not think it is the best approach.

Please, consider the usefulness of OU filed not only in Browser terms, but also in Organization's and Big Public Administration terms (such a Ministry)

[sleevi]

IMHO, the justification of Security issues is not sound and the real underlying reason is to make the certificates smaller.

When we put ourselves in Browser's shoes, we clearly understand the need of lightweight certificates on the Web PKI.

Hi Chema,

I appreciate you not misrepresenting the views here with wildly incorrect speculation. The objection is clearly stated: This information is not validated. There was lengthy discussion on yesterday's CA/Browser Forum F2F about how this ballot fundamentally and structurally fails to improve anything, and how this field cannot be validated.

While Paul has copied language from Section 3.2, as he acknowledged on the call, there is no appropriate naming authority, and no meaningful way to validate this information, because it is fundamentally defined by the Subscriber. The example sources listed in this ballot are, without question, not the "naming authority" for the OU - only the organization is - and thus provide no validation service that is suitable for the goal. The process of "validation" for certificate issuance is contacting the appropriate naming authority (e.g. the IANA root zone, through to the registry and registrar, for DNS names, or the relevant business registry for organizational information), and validating data independent of relying upon the Applicant. The use of this field is inherently at odds with that, because the Applicant is the only authority for validating this information.

Containing arbitrary data controlled by the Applicant that cannot be validated, is, without reservation or hesitation, wildly inappropriate, insecure, and irresponsible, and we have ample evidence from CA incidents to support this. It is the explicit goal to ensure that the only information included within certificates has been appropriately and competently validated according to the relevant naming authority and that, in the event of multiple naming authorities, it is clear and unambiguous on a technical level, without necessitating any form of manual inspection. This ballot fails to account for any of those discussions over the years, and is thus technically unsound.

So please do not misrepresent this as some hidden agenda as a means of avoiding engaging the substance of the concerns, as this only serves to lower the discussion from concrete technical details.

Please, consider the usefulness of OU filed not only in Browser terms, but also in Organization's and Big Public Administration terms (such a Ministry)

As stated on the list, the use of PKI in this manner is fundamentally incompatible with the security needs of browser users. Organizations are, of course, free to describe their own rules for certificate profiles and fields, but that comes with a corresponding need to manually install such certificates. This is no different than any other feature of a browser or operating system, where, if the software vendor does not provide a particular feature, third-parties can install extensions or third-party software to satisfy the need. There is zero reason to believe this is necessary in a "default install", and the set of CAs subject to the Baseline Requirements are, very much so, for the purpose of assessing the necessary security for a "default install".

You do raise an interesting case, and it sounds like, should browsers adopt a ballot forbidding OU, or should do so via their root programs, Firmaprofesional might exercise 9.16.3 of the Baseline Requirements if they can demonstrate that the above requirements are functional legislation. Should they do so, browser vendors could then decide whether that would be justification to remove the CA from their default included set, in recognition of the incompatibility.

[chemalogo]

First of all, thanks Ryan for explaining to me the rationale behind this issue, since I could not attend the F2F meeting. On the other hand, I'm afraid that my intention was not to misrepresent, but to open what could be another reason to undertake the OU concern, and if the reason is different, maybe so is the solution. I think that we can agree that the seek of lightweight certificates is something where Browsers are putting a lot of effort, and that forbidding the OU field would go in this direction. This is why it does not seem crazy to me to think that minimizing the weight of certificates can also be an important reason to eliminate the OU field. Independently of the underlying reason, I agree that validation of OU field could be difficult, and of course maybe impossible to automate. And yes, there is specific profile in the Spanish Public Administration for "SEDE ELECTRÓNICA" (could be translated as "Electronic Main Office") requiring two OU entries: 1. A literal one stating "SEDE ELECTRÓNICA". Here there is no need to validate anything. The content is as declared in the profile. 2. <name of the electronic office>: i.e "Industry Ministry" or "National Tax Agency".Here you can perform a *manual validation against one of the Official Bulletins*, since, by law , it is necessary to publish in an Official Bulletin some data of the "Electronic Office" before this Public Administration requests a certificate. You can find the text here (only in Spanish): https://administracionelectronica.gob.es/pae_Home/dam/jcr:474ae40a-fe06-45fa-aa8f-113049e9c889/2016_Perfiles_de_certificados_1-ed.pdf . Please, refer to page 37 (R means 'Required'. and 'Sí' means 'Yes'): [image: image.png] For Firmaprofesional and I think that for any Spanish QTSP issuing "SEDE ELECTRÓNICA" certificates it is important to keep the OU field. Thanks for the reference to BR 9.16.3. If, in the end, the OU is forbidden we will need to update our CPS. Best regards, *Chema López* Director Área Innovación, Cumplimiento y Tecnología +34 666 429 224 *Barcelona *Av. Torre Blanca 57, Edif. Esadecreapolis, Local 3B6 - 08173 Sant Cugat del Vallès | +34 934 774 245 *Madrid *C/ Velázquez 59, 1º Ctro-Izda. - 28001 Madrid | +34 915 762 181 www.firmaprofesional.com *El contenido de este correo electrónico y de sus anexos es confidencial. Si usted recibe este mensaje por error, debe saber que está prohibido hacer uso, divulgación y/o copia del mismo. En tal caso le agradeceríamos que advierta de inmediato a su remitente y que proceda a destruir el mensaje.* *Le informamos que, cumpliendo la normativa en materia de protección de datos, FIRMAPROFESIONAL tratará sus datos con la finalidad de garantizar las relaciones con la empresa, entidad u organización a la que usted representa o en la que trabaja y por el período que dure dicha relación. Podrá ejercer sus derechos de acceso, rectificación, supresión, limitación, portabilidad y oposición al tratamiento ante el Responsable: FIRMAPROFESIONAL, S.A., Av. Torre Blanca, 57, local 3B6 (Edificio Esadecreapolis), 08173 Sant Cugat del Vallès (Barcelona), o bien mediante correo electrónico a: rgpd@firmaprofesional.com <rgpd@firmaprofesional.com>, en cualquier caso adjuntando una copia de su D.N.I. o documento equivalente. Asimismo, podrá formular reclamaciones ante la Agencia Española de Protección de Datos. Para más información puede consultar nuestra política de privacidad <https://www.firmaprofesional.com/esp/aviso-legal>.*

…

On Wed, 21 Oct 2020 at 16:10, sleevi ***@***.***> wrote: IMHO, the justification of Security issues is not sound and the real underlying reason is to make the certificates smaller. When we put ourselves in Browser's shoes, we clearly understand the need of lightweight certificates on the Web PKI. Hi Chema, I appreciate you not misrepresenting the views here with wildly incorrect speculation. The objection is clearly stated: This information is not validated. There was lengthy discussion on yesterday's CA/Browser Forum F2F about how this ballot fundamentally and structurally fails to improve anything, and how this field cannot be validated. While Paul has copied language from Section 3.2, as he acknowledged on the call, there is no appropriate naming authority, and no meaningful way to validate this information, because it is fundamentally defined by the Subscriber. The example sources listed in this ballot are, without question, not the "naming authority" for the OU - only the organization is - and thus provide no validation service that is suitable for the goal. The process of "validation" for certificate issuance is contacting the appropriate naming authority (e.g. the IANA root zone, through to the registry and registrar, for DNS names, or the relevant business registry for organizational information), and validating data independent of relying upon the Applicant. The use of this field is inherently at odds with that, because the Applicant is the only authority for validating this information. Containing arbitrary data controlled by the Applicant that cannot be validated, is, without reservation or hesitation, wildly inappropriate, insecure, and irresponsible, and we have ample evidence from CA incidents to support this. It is the explicit goal to ensure that the only information included within certificates has been appropriately and competently validated according to the relevant naming authority and that, in the event of multiple naming authorities, it is clear and unambiguous on a technical level, without necessitating any form of manual inspection. This ballot fails to account for any of those discussions over the years, and is thus technically unsound. So please do not misrepresent this as some hidden agenda as a means of avoiding engaging the substance of the concerns, as this only serves to lower the discussion from concrete technical details. Please, consider the usefulness of OU filed not only in Browser terms, but also in Organization's and Big Public Administration terms (such a Ministry) As stated on the list, the use of PKI in this manner is fundamentally incompatible with the security needs of browser users. Organizations are, of course, free to describe their own rules for certificate profiles and fields, but that comes with a corresponding need to manually install such certificates. This is no different than any other feature of a browser or operating system, where, if the software vendor does not provide a particular feature, third-parties can install extensions or third-party software to satisfy the need. There is zero reason to believe this is necessary in a "default install", and the set of CAs subject to the Baseline Requirements are, very much so, for the purpose of assessing the necessary security for a "default install". You do raise an interesting case, and it sounds like, should browsers adopt a ballot forbidding OU, or should do so via their root programs, Firmaprofesional might exercise 9.16.3 of the Baseline Requirements if they can demonstrate that the above requirements are functional legislation. Should they do so, browser vendors could then decide whether that would be justification to remove the CA from their default included set, in recognition of the incompatibility. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#225 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADYKOL7JTFD4ZR776NP7JRLSL3TWHANCNFSM4SVY2NQQ> .

[vanbroup]

Thanks for these great references @chemalogo, I got similar feedback from CA's in France, Italy, India, China that have local requirements as well. Not to forgot industry specific requirements such as the North American energy industry.

Here you can find a document for India, containing some requirements, including for specific certificates such as OCSP responders:
http://cca.gov.in/sites/files/pdf/guidelines/CCA-IOG.pdf

I'm still trying to collect feedback and documents for other countries. It looks like some containing stricter requirements than others.

[vanbroup]

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.

The version below only provides one method that must be followed and always requires a prefix/suffix to be added. I don't think it will satisfy all use cases, but it should be sufficient for the large majority and might be a good compromise:

Suggested change

	If the Subject Identity Information is to include an organizational unit, then 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 accordance with Section 3.2.
	The usage of commonly recognized organizational unit names is permitted and the CA is not required to verify the existence of and affiliation with the Applicant as long the value is included on a publicly disclosed list of CA has pre-approved values (disclosure of this list SHALL be through an appropriate and readily accessible online means).
	Self reported values SHALL be preceded or followed by a whitespace and the word “department”, “division”, “unit” or the equivalent in a language other than English. The CA may extend these options using a publicly disclosed list containing the preceded or followed values which the CA has approved; as log it's disclosed through an appropriate and readily accessible online means.
	The CA SHALL verify the existence of and affiliation of the organizational unit with the Applicant using at least one of the following:
	1. A government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition;
	2. A government agency responsible for the management of such organizational units, DBAs or tradenames;
	3. A third party database that is periodically updated and considered a Reliable Data Source;
	4. A site visit by the CA or a third party who is acting as an agent for the CA;
	5. An Attestation Letter;
	6. A utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable;
	7. A connection with the Applicant's directory system;
	8. An Organizational Chart or public directory of the Applicant; or
	9. Communication with 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.
	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.
	Alternatively, the CA MAY allow values or series as defined by a Government, standard, or regulatory body; or a series of at least five numerals, optionally preceded or followed by two alphabetical characters. The CA is not required to verify the accuracy of these non descriptive identifiers.
	If the Subject Identity Information is to include an organizational unit, then it MUST be preceded or followed by a whitespace and an equivalent of the word “unit”, “service", "system", "center", "office", “faculty”, "administration", "operations” in singular or plural form, or the equivalent in a language other than English. 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.
	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.
	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.

[vanbroup]

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

Suggested change

	If the Subject Identity Information is to include an organizational unit, then 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 accordance with Section 3.2.
	The usage of commonly recognized organizational unit names is permitted and the CA is not required to verify the existence of and affiliation with the Applicant as long the value is included on a publicly disclosed list of CA has pre-approved values (disclosure of this list SHALL be through an appropriate and readily accessible online means).
	Self reported values SHALL be preceded or followed by a whitespace and the word “department”, “division”, “unit” or the equivalent in a language other than English. The CA may extend these options using a publicly disclosed list containing the preceded or followed values which the CA has approved; as log it's disclosed through an appropriate and readily accessible online means.
	The CA SHALL verify the existence of and affiliation of the organizational unit with the Applicant using at least one of the following:
	1. A government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition;
	2. A government agency responsible for the management of such organizational units, DBAs or tradenames;
	3. A third party database that is periodically updated and considered a Reliable Data Source;
	4. A site visit by the CA or a third party who is acting as an agent for the CA;
	5. An Attestation Letter;
	6. A utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable;
	7. A connection with the Applicant's directory system;
	8. An Organizational Chart or public directory of the Applicant; or
	9. Communication with 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.
	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.
	Alternatively, the CA MAY allow values or series as defined by a Government, standard, or regulatory body; or a series of at least five numerals, optionally preceded or followed by two alphabetical characters. The CA is not required to verify the accuracy of these non descriptive identifiers.
	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 an unambiguous 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.

[vanbroup]

Strengthen the validation requirements further:

Suggested change

	If the Subject Identity Information is to include an organizational unit, then 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 accordance with Section 3.2.
	The usage of commonly recognized organizational unit names is permitted and the CA is not required to verify the existence of and affiliation with the Applicant as long the value is included on a publicly disclosed list of CA has pre-approved values (disclosure of this list SHALL be through an appropriate and readily accessible online means).
	Self reported values SHALL be preceded or followed by a whitespace and the word “department”, “division”, “unit” or the equivalent in a language other than English. The CA may extend these options using a publicly disclosed list containing the preceded or followed values which the CA has approved; as log it's disclosed through an appropriate and readily accessible online means.
	The CA SHALL verify the existence of and affiliation of the organizational unit with the Applicant using at least one of the following:
	1. A government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition;
	2. A government agency responsible for the management of such organizational units, DBAs or tradenames;
	3. A third party database that is periodically updated and considered a Reliable Data Source;
	4. A site visit by the CA or a third party who is acting as an agent for the CA;
	5. An Attestation Letter;
	6. A utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable;
	7. A connection with the Applicant's directory system;
	8. An Organizational Chart or public directory of the Applicant; or
	9. Communication with 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.
	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.
	Alternatively, the CA MAY allow values or series as defined by a Government, standard, or regulatory body; or a series of at least five numerals, optionally preceded or followed by two alphabetical characters. The CA is not required to verify the accuracy of these non descriptive identifiers.
	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 an unambiguous certified translation of the equivalent in a language other than English.
	The CA MUST verify the existence of the organizational unit using an Organizational Chart provided by the human resource offices of the Applicant or that is signed by a listed officer of Applicant.
	If a word in the value holds an active registration in the ‘WIPO Global Brand Database’ or a local business register the CA MUST only include these registered values when the CA has verified the right of usage in relation to the Applicant 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.

[sleevi]

Hi there @dt1349git - I've marked your comment as hidden, as the way to submit feedback to the CA/Browser Forum is captured at https://cabforum.org/email-lists/ . We haven't yet formalized participation on GitHub for non-Members, although it will likely take form through discussions/issues, not through pull requests. However, in the mean time, feel free to submit your comments to our questions list, or consider joining the Forum as an Interested Party, subject to the IPR agreement.

Thanks!

[dt1349git]

Ryan, Thanks for letting me know. I have posted a question as you suggested below. Will my question get shared with the members and interested parties? Don Tripp Lead Member of Technical Staff Chief Security Organization AT&T Services, Inc. 801 Chestnut Ave, 6th Floor, Saint Louis, MO63101 m 314.608.7761 | o 314.335.3199 | don.tripp@att.com<mailto:don.tripp@att.com> From: sleevi <notifications@github.com> Sent: Thursday, January 14, 2021 12:53 PM To: cabforum/servercert <servercert@noreply.github.com> Cc: TRIPP, DON <dt1349@att.com>; Mention <mention@noreply.github.com> Subject: Re: [cabforum/servercert] Revision of subject:organizationalUnitName (#225) Hi there @dt1349git<https://urldefense.com/v3/__https:/github.com/dt1349git__;!!BhdT!3T3vCYENyOQN6t053xh4e_FQ3YbdKNUwpOJdiDuqsk7mjrcbnW7NOiWfrecUlA$> - I've marked your comment as hidden, as the way to submit feedback to the CA/Browser Forum is captured at https://cabforum.org/email-lists/<https://urldefense.com/v3/__https:/cabforum.org/email-lists/__;!!BhdT!3T3vCYENyOQN6t053xh4e_FQ3YbdKNUwpOJdiDuqsk7mjrcbnW7NOiXP2QgjhQ$> . We haven't yet formalized participation on GitHub for non-Members, although it will likely take form through discussions/issues, not through pull requests. However, in the mean time, feel free to submit your comments to our questions list, or consider joining the Forum as an Interested Party, subject to the IPR agreement. Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/cabforum/servercert/pull/225*issuecomment-760399307__;Iw!!BhdT!3T3vCYENyOQN6t053xh4e_FQ3YbdKNUwpOJdiDuqsk7mjrcbnW7NOiXgBrOsYw$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ASO4DIR6J3RC3CZH273MLE3SZ44RZANCNFSM4SVY2NQQ__;!!BhdT!3T3vCYENyOQN6t053xh4e_FQ3YbdKNUwpOJdiDuqsk7mjrcbnW7NOiU7l0-z3w$>.

[vanbroup]

Closed in favor of #282