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

[Paul van Brouwershaven]

Hi Burton,

While I do agree that for some use cases a certificate policy could have a preference over putting constraints on an OU, this is not the intend of this ballot.

With this (draft) 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 to support organizations, infrastructure and application that rely on the OU field today.

Thanks for your suggestion,

Paul
________________________________
From: Burton <burton at typewritten.net>
Sent: Monday, October 19, 2020 14:02
To: Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com>; CA/Browser Forum Validation SC List <validation at cabforum.org>
Subject: [EXTERNAL]Re: [cabf_validation] Draft Ballot SCXX: Improve OU validation requirements

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Hi Paul,

Why can't businesses and governments use enterprise numbers OIDs in the certificates policy section for identifying department purposes? That OID can be verified with IANA enterprise number list.

Thank you

Burton

On Mon, 19 Oct 2020, 09:39 Paul van Brouwershaven via Validation, <validation at cabforum.org<mailto:validation at cabforum.org>> wrote:
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 (draft) 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.

Entrust provided a draft ballot redline [1] to improve the OU validation requirements. This is created as a Draft Pull Request to allow others to point out issues, and the current fixed commit version is [2], since [1] will be updated if/as feedback is received.

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.

[1] https://github.com/cabforum/documents/pull/225
[2] https://github.com/cabforum/documents/pull/225/commits/33ac251f0105f4ebb55ac22ce0c198796da685c3

Thanks,

Paul van Brouwershaven
Entrust


_______________________________________________
Validation mailing list
Validation at cabforum.org<mailto: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/20201019/c0415ecd/attachment-0001.html>