[cabf_validation] Revision to OU requirements
Bruce Morton
Bruce.Morton at entrustdatacard.com
Wed Sep 2 13:52:58 MST 2020
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> On Behalf Of Jeremy Rowley via Validation
Sent: Wednesday, September 2, 2020 4:29 PM
To: Ryan Sleevi <sleevi at google.com>
Cc: CABforum3 <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/20200902/74a754f8/attachment.html>
More information about the Validation
mailing list