[cabf_validation] [EXTERNAL]Re: Revision to OU requirements

[Jeremy Rowley]

I thought our experience turning off OUs might be of interest. We generally turned off all OUs starting Sep 1. To date, we’ve re-enabled OUs for about 100 accounts where they required additional time to migrate away from using OUs.  The only technical reason we have encountered is where people are using VMware’s cert installation tool, which I posted about earlier. Of the remaining, most simply needed time to change how they tracked certs. They previously used the OU as a tracking mechanism for cert installation and deployment. They needed to move to another system, outside of the certificate itself. A couple (two that I know of), pinned their application to the OU value. They needed time to update the application to not specify the expected value of OU.  Overall, the move away from OU has been surprisingly quiet.

From: Ryan Sleevi <sleevi at google.com>
Sent: Wednesday, September 2, 2020 3:38 PM
To: Bruce Morton <Bruce.Morton at entrustdatacard.com>
Cc: Jeremy Rowley <jeremy.rowley at digicert.com>; CABforum3 <validation at cabforum.org>
Subject: Re: [EXTERNAL]Re: [cabf_validation] Revision to OU requirements

Right, but that's slightly different than the point I was making :)

Up to (through?) AMT 7.0, you could only use several commercial CAs, and only with SHA-1.
From AMT 7.0+, an organization can add their own CA to the set of management hashes, so there's no need to obtain a commercial CA certificate to function.

While AMT supports a variety of commercial CAs still, expanded as part of the Great SHA-1 deprecation, these aren't required, which is the scenario that I think we're trying to understand re: VMware. That is, if the Forum, or browsers, took a step to forbid OU, then there are options for both commercial CAs (using the root rotation I mentioned) and enterprises using AMT (using a private CA, whether commercially-managed or privately-managed) to function.

AMT using commercial CAs baked into firmware is a bit like the payment terminal scenario, or, for that matter, certificate pinning, both of which Forum members have largely recognized as problematic for security, interoperability, and of course, for CAs not on those lists, competition. Luckily, we have options to avoid that.

On Wed, Sep 2, 2020 at 5:17 PM Bruce Morton <Bruce.Morton at entrustdatacard.com<mailto:Bruce.Morton at entrustdatacard.com>> wrote:
Intel trusts a number of public CAs, https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Frootcertificatehashes.htm.

Bruce.

From: Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>>
Sent: Wednesday, September 2, 2020 4:59 PM
To: Bruce Morton <Bruce.Morton at entrustdatacard.com<mailto:Bruce.Morton at entrustdatacard.com>>
Cc: Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>>; CA/Browser Forum Validation SC List <validation at cabforum.org<mailto:validation at cabforum.org>>
Subject: [EXTERNAL]Re: [cabf_validation] Revision to OU requirements

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
I thought private CAs for AMT were supported since AMT 7.0, which was circa-2010/2011 if I remember correctly?

Prior to that, Intel hard-coded a list of commercial CAs into the firmware of their chips, which is just... many levels of "don't do that". On the upside, it's possible to smoothly transition to new roots, for the commercial CAs still wanting to provide those certificates, by spinning up new roots, cross-signing new with old, issuing BR-compliant certs from new, and withdrawing old from root stores (so they could issue non-BR compliant certs). Basically, SHA-1 transition, but more structured, but I think that should only matter for hardware more than 10 years old, and I think the old stuff only supported SHA-1 anyways?

On Wed, Sep 2, 2020 at 4:53 PM Bruce Morton <Bruce.Morton at entrustdatacard.com<mailto:Bruce.Morton at entrustdatacard.com>> wrote:
Intel also uses the OU for Intel VPro/AMT use case where they require OU= Intel (R) Client Setup Certificate.
https://www.intel.com/content/dam/support/us/en/documents/software/software-applications/Intel_SCS_Deployment_Guide.pdf

Bruce.

From: Validation <validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org>> On Behalf Of Jeremy Rowley via Validation
Sent: Wednesday, September 2, 2020 4:29 PM
To: Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>>
Cc: CABforum3 <validation at cabforum.org<mailto:validation at cabforum.org>>
Subject: [EXTERNAL]Re: [cabf_validation] Revision to OU requirements

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Yeah – we wanted to see what would happen if we turned it off. So far, there hasn’t been  a lot of noise. This is the first one we’ve encountered.

VMware generate the OU as part of the cert request to create a unique identifier. The tool uses that unique identifier to do the installation. Removing the OU is breaking the VMware install tool and causing it not to load the certificate. We’re reaching out to them to see if we can get them to update their software and stop requiring OU.

From: Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>>
Sent: Wednesday, September 2, 2020 2:23 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>>
Cc: CABforum3 <validation at cabforum.org<mailto:validation at cabforum.org>>; Richard Smith <rich at sectigo.com<mailto:rich at sectigo.com>>
Subject: Re: [cabf_validation] Revision to OU requirements



On Wed, Sep 2, 2020 at 4:14 PM Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> wrote:
We’ve been working to shut off OU completely to see if there are issues with doing so.  So far, we’ve found one automation tool that requires OU:  https://kb.vmware.com/s/article/2044696

Thanks Jeremy! I saw DigiCert was taking a good step here, in https://knowledge.digicert.com/alerts/ou-removal.html , and think that's a model for all CAs (by virtue of the BRs)

I'm hoping you can share more details about the issue there. Are you saying the system doesn't load a publicly-trusted certificate if it's missing the OU field, or merely that their tool produces CSRs with the OU field populated, as part of ensuring a globally unique DN?

Much like past work on working out interoperable, standards-based approaches to IP addresses ( https://cabforum.org/guidance-ip-addresses-certificates/ ), it'd be great to understand the problem more to see what options we have.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200917/c07ca393/attachment-0001.html>