<div dir="ltr"><div>Thanks Michelle,</div><div><br></div><div>This is really useful! However, it's not clear to me why the wholesale electric industry is using browser-based certificates. The discussion here would only be regarding those used as part of browser/OS, and surely these devices aren't using the same trust anchors, given the risks, right? Certainly, using a dedicated trust anchor for different compliance regimes has long been understood as good practice, at least within the Forum, as we saw first-hand with 1024-bit RSA and SHA-1.<br></div><div><br></div><div>Given the size and depth of this information, could you perhaps provide a more specific reference? Looking through FERC 888, 889, and 2222, I don't see any specific references to organizationalUnit. Perhaps I'm overlooking something, however?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 23, 2020 at 3:59 PM Michelle Coon via Validation <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">OATI has the following comments regarding the OU field discussion:<br>
The wholesale electric industry currently uses the optional OU field in the certificate string of client certificates to identify a specific organization unit having authority to conduct business transactions as allowed under regulatory requirements promulgated by the Federal Energy Regulatory Commission (FERC). In FERC Orders 888 and 889, utilities were required to isolate business units for purposes of sharing transmission grid information. Transmission and wholesale energy trading business units in all major U.S. grid interconnections, Western, Eastern, and ERCOT, are required to be broken up into separate business units for different activities. Different units must be completely "brick walled" from each other, and operate as different entities even though they are still technically sub units of the same company. For more than 20 years, OU field has been and is currently used by energy industry entities as an integrated business process to clearly and distinctly identify the specific organization unit associated with discrete certificates in compliance of FERC Orders 888 and 889. Additionally, with the recent FERC Order 2222, the use of the optional OU field in the certificate string may be expanded as a business practice to the distribution/retail level of power entities as integrated into energy markets of North America. <br>
Removal of the optional OU field in the certificate string would cause disruption of current business practice in the energy industry of North America. Specifically, removal of the optional OU field would prevent energy industry entities from clearly and distinctly identifying the specific organization unit associated with discrete certificates, thereby compromising their compliance with U.S. federal regulatory mandates. Additionally, it would require energy industry entities to modify their current business processes, requiring time, staff, and resources. <br>
The OU field in the certificate string is optional and should remain optional, to accommodate all organizations-those that use the optional OU field as part of their established business processes, as well as those organizations that do not use the optional OU field.  <br>
<br>
Michelle Coon<br>
Associate Director, Compliance<br>
Phone: <a href="tel:(763)%20201-2000" value="+17632012000" target="_blank">763.201.2000</a>  <br>
Fax: <a href="tel:(763)%20201-5333" value="+17632015333" target="_blank">763.201.5333</a> <br>
Open Access Technology International, Inc.<br>
3660 Technology Drive NE, Minneapolis, MN 55418<br>
<br>
<br>
<br>
CONFIDENTIAL INFORMATION: This email and any attachment(s) contain confidential and/or proprietary information of Open Access Technology International, Inc. Do not copy or distribute without the prior written consent of OATI. If you are not a named recipient to the message, please notify the sender immediately and do not retain the message in any form, printed or electronic.<br>
<br>
<br>
-----Original Message-----<br>
From: Validation [mailto:<a href="mailto:validation-bounces@cabforum.org" target="_blank">validation-bounces@cabforum.org</a>] On Behalf Of Kurt Roeckx via Validation<br>
Sent: Monday, September 21, 2020 3:47 PM<br>
To: Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>>; CA/Browser Forum Validation SC List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br>
Subject: Re: [cabf_validation] Revision to OU requirements<br>
<br>
{External email message: This email is from an external source. Please exercise caution prior to opening attachments, clicking on links, or providing any sensitive information.}<br>
<br>
On Mon, Sep 21, 2020 at 02:01:20PM -0400, Ryan Sleevi via Validation wrote:<br>
> Can you clarify: Was this at the request of BCSS (the "server", in <br>
> their<br>
> parlance) or in the use of TLS certificates as client-auth certificates?<br>
> <br>
> This appears to be detailing a very specific mutual-TLS authentication <br>
> flow, and it's unclear whether or not a browser-used CA is essential <br>
> for this.<br>
<br>
Reading the document, it says that the KSZ/BCSS/CBSS has 3 certificates (TLS server, TLS client, TLS client to sign documents), and depending on the communications, one of the 3 is used. Clients wishing to authenticate them should get the certificates. Clients should also send their own certificate to KSZ/BCSS/CBSS.<br>
<br>
<br>
Kurt<br>
<br>
_______________________________________________<br>
Validation mailing list<br>
<a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/validation" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a><br>
_______________________________________________<br>
Validation mailing list<br>
<a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/validation" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a><br>
</blockquote></div></div>