<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Trebuchet MS";
        panose-1:2 11 6 3 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Trebuchet MS",sans-serif;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Trebuchet MS",sans-serif;
        color:#1F497D;}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:"Trebuchet MS",sans-serif;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif;color:#1F497D">Good Day – I tried to insert OATI’s comments inline below in five areas labeled with “</span><b><span style="font-family:"Trebuchet MS",sans-serif;color:blue">OATI
 Response:</span></b><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif;color:#1F497D">”. 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif;color:#1F497D">Thank you.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="FR" style="font-family:"Trebuchet MS",sans-serif;color:#2F5496">Michelle Coon<o:p></o:p></span></b></p>
<p class="MsoNormal"><span lang="FR" style="font-size:10.0pt;font-family:"Trebuchet MS",sans-serif;color:#2F5496">Associate Director, Compliance<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="FR" style="font-size:10.0pt;font-family:"Trebuchet MS",sans-serif;color:#2F5496">Phone: 763.201.2000 
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA" style="font-size:10.0pt;font-family:"Trebuchet MS",sans-serif;color:#2F5496">Fax: 763.201.5333
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Trebuchet MS",sans-serif;color:#2F5496">Open Access Technology International, Inc.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Trebuchet MS",sans-serif;color:#2F5496">3660 Technology Drive NE, Minneapolis, MN 55418<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Trebuchet MS",sans-serif;color:#2F5496"><img width="208" height="76" id="Picture_x0020_1" src="cid:image002.jpg@01D6A3D4.4E368B40" alt="25 in 20 Email Signature-02 325x118 v0.3 VK 021820"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif;color:#2F5496"><img width="624" height="1" id="Picture_x0020_2" src="cid:image003.png@01D6A3C0.6158DBB0" alt="Adobe Systems"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif;color:#2F5496"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Trebuchet MS",sans-serif;color:#2F5496">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.</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#2F5496"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Validation [mailto:validation-bounces@cabforum.org]
<b>On Behalf Of </b>Ryan Sleevi via Validation<br>
<b>Sent:</b> Thursday, September 24, 2020 10:50 AM<br>
<b>To:</b> Christian Heutger <ch@psw.net><br>
<b>Cc:</b> CA/Browser Forum Validation SC List <validation@cabforum.org><br>
<b>Subject:</b> Re: [cabf_validation] Revision to OU requirements<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p><b><span style="color:red">{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.}</span></b><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">Thanks Christian,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm still having trouble understanding your point, since as you note, you're talking about client and S/MIME certificates. However, again, I would stress that it's not a goal to have a single certificate that is intended for different purpose
 and compliance schemes. That's simply bad engineering, and harmful to security. The design and implementation of a PKI is tied directly to its use cases, ranging from everything from the validation requirements, the certificate lifecycle (of both end-entities
 and roots), the overall design of the hierarchy (e.g. cross-certificates, key rollover), and of course, matters like certificate profiles and revocation. This is nothing new or controversial: the very standards, such as RFC 5280 and RFC 3647, were designed
 intentionally to allow different user communities to profile certificates according to their needs, including profiling in ways that are incompatible within a single hierarchy.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As I mentioned, it's important not to think of PKI or a certificate hierarchy as a "product", but rather a set of technologies and approaches. This is obvious in looking at why we have CP/CPSes, which describe how the particular set of
 technologies are combined for a particular use case.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Different certificate using communities set their own rules and policies, which we see from the ample PKIs in existence, ranging from those that are internal-only, those that are industry consortia lead like the USB-IF PKI, federated PKIs
 for particular sectors, such as SAFE-BioPharma or GRID PKI, and of course, various government PKIs intended for G2G and G2B use cases, such as the US Federal PKI or the eIDAS Regulation.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So if the assertion is that "it's nice to have one certificate that works everywhere", I agree that's nice, but that's not how the technology is designed, much like having "one password you use everywhere" is antithetical to security. So
 while it's useful to understand that other communities make use of the OU field, it's not clear that it is at all relevant to this discussion, especially when interoperating with those PKI communities is a non-goal. Expecting different PKIs to follow the same
 profile is like expecting different web servers (such as Facebook vs Twitter) to all store the same information about users, served via the same HTTP URLs. That doesn't make any sense at all.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in;text-indent:-.5in"><b><span style="font-family:"Trebuchet MS",sans-serif;color:blue">OATI Response: 
</span></b><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif">Thanks, Ryan. What is clear is that keeping the lights on is relevant and important—and to do that, we need to have certificates that are interoperable. If not, the cost of delivering
 electricity to consumers and business will become astronomic, and we will have “undone” what it took the FERC 26 years to achieve and undermined how we will all integrate our distributed energy assets into the grid.
</span><span style="font-size:10.0pt;font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif">Removing the OPTIONAL OU field WILL impact business in a negative way. Empowering and supporting business should be our goal. We need to understand
 that browsers support and are integral to SaaS applications that enhance reliability and security. We agree that PKI is an approach, and the current approach works.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Sep 24, 2020 at 11:38 AM Christian Heutger <<a href="mailto:ch@psw.net">ch@psw.net</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi Ryan,<span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE"><o:p> </o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">my point is, that for sure it’s possible to have different setups for different purposes. However, our experience (e.g. on client and s/mime certificates, e.g. especially for the
 german energy sector) is, that different setups for different purposes make it harder for CA to handle (and offer) as well as for customers as missing interoperability in usage. Solutions, which are usable for multiple purposes (but also require similar design
 and requirements) are very well welcome. As for such, fundamental changes like OU removal may disrupt such interoperability.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-family:"Trebuchet MS",sans-serif;color:blue">OATI Response: 
</span></b><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif">Agreed, Christian. Your comments also reflect the perspectives of the energy industry in North America—focusing on the business practices needed and used to keep the lights on.
 Interoperability is critical-especially as we move globally to the incorporation of billions of assets.</span><span lang="DE" style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Regards<span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Christian<span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <span lang="DE"><o:p></o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span lang="DE" style="color:black">Von:
</span></b><span lang="DE" style="color:black">Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>><br>
<b>Datum: </b>Donnerstag, 24. September 2020 um 16:00<br>
<b>An: </b>Christian Heutger <<a href="mailto:ch@psw.net" target="_blank">ch@psw.net</a>><br>
<b>Cc: </b>CA/Browser Forum Validation SC List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br>
<b>Betreff: </b>Re: [cabf_validation] Revision to OU requirements</span><span lang="DE"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE">Hi Christian,
<o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE">I'm not sure I understand your point here. The CA/Browser Forum is a discussion forum for browsers and CAs to discuss product requirements for browser products.
 While I agree that PKI technologies are used in a wide variety of use cases, proving how general purpose the technology is, there's no requirement that they all use the same CA infrastructure. Indeed, as the industry has shown consistently, both in terms of
 standards evolution and in response to security incidents, there are ample harms from using the "same" certificate hierarchy. That doesn't mean a single organization can't operate multiple hierarchies, but we should be careful to not mistake PKI hierarchies
 as general purpose, because they are not.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE">In this model, it helps to think of PKI like JSON or XML: a general purpose technology for expressing attributes, but specific uses of it (e.g. specific APIs or
 service endpoints) will define their own requirements on how that general technology is used. Much like it would be strange to think of an API for listing, say, shopping products, use the same structure and format as an API for managing smart meters, we can
 substitute "API" for "PKI" and get the same conceptual clarity about why they are fundamentally different.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE">As it relates to the question I asked of Michelle, which you're replying to here, it appears the relevant standards document is WEQ-012, developed by NAESB, and
 recognized by FERC. In that case, it would appear there is limited to no risk of the removal of OU creating incompatibility, because it appears the specification for the NAESB PKI within WEQ-012 is already incompatible with the specification for browser PKIs
 within browser root store requirements and the Baseline Requirements. Of course, I'm certainly hoping Michelle can share more details, such as a readily attainable public version of the most recent version, to facilitate further discussion.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in;text-align:justify"><b><span style="font-family:"Trebuchet MS",sans-serif;color:blue">OATI Response: 
</span></b><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif">Not sure further discussion is necessary. There is an industry—certainly not a small niche interest group—that uses the OPTIONAL field for a critically important business purpose.
</span><span style="font-size:10.0pt;font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in;text-align:justify"><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif">You suggest that the NAESB WEQ-012 and root requirements are incompatible—yet you offer no substantive support for that.   
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in;text-align:justify"><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif">It also seems this discussion is focusing around “certificates” as isolated elements, distinct from the business processes
 they support; and although that perspective is interesting as a mental exercise, it is disjoint from the role certificates have come to play after many years in use. Using certificates to access browsers to shop is a different business use of certificates
 compared to keeping the lights on across North America in full compliance with energy industry regulatory mandates—something that we can all agree is a ubiquitous activity used by everyone as they flip a light switch multiple times each day, charge their phones,
 or even plug in their computers.  <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in;text-align:justify"><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif">With the new FERC Order 2222, we anticipate that the OU field may become an important part of Distributed Energy Resource
 (DER) identification in the industry. Similar to the role of FERC at the transmission level, state-level public utility commissions, with jurisdiction over distribution-level energy, may impose additional business process requirements over DERs which could
 be supported by use of the optional OU field. It’s a new world now in the energy industry, and empowering the industry to continue its high level of reliability is critical.
<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE"> <o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE">On Thu, Sep 24, 2020 at 5:26 AM Christian Heutger <<a href="mailto:ch@psw.net" target="_blank">ch@psw.net</a>> wrote:<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi,<span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">SSL/TLS certificate usage is much wider than only for Web Sites, primary they are server certificates. Similar to client certificates, which may be S/MIME certificates, user certificates,
 signing certificates on machines, clients or gateways. The view here seems sometimes a bit to reduced, but has larger impact as sometimes recognized.<span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Regards,<span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Christian<span lang="DE"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <span lang="DE"><o:p></o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span lang="DE" style="color:black">Von:
</span></b><span lang="DE" style="color:black">Validation <<a href="mailto:validation-bounces@cabforum.org" target="_blank">validation-bounces@cabforum.org</a>> im Auftrag von Ryan Sleevi via Validation <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br>
<b>Antworten an: </b>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>
<b>Datum: </b>Donnerstag, 24. September 2020 um 00:11<br>
<b>An: </b>Michelle Coon <<a href="mailto:Michelle.Coon@oati.net" target="_blank">Michelle.Coon@oati.net</a>>, CA/Browser Forum Validation SC List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br>
<b>Betreff: </b>Re: [cabf_validation] Revision to OU requirements</span><span lang="DE"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE"> <o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE">Thanks Michelle,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in;text-align:justify"><b><span style="font-family:"Trebuchet MS",sans-serif;color:blue">OATI Response:
</span></b><b><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif;color:blue"> </span></b><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif">Thanks, Ryan. The North American energy industry uses browser-based certificates for
 SaaS (Software-as-a-Service) solutions, which opened up competition and access in the wholesale energy industry and paved the way for the advanced energy markets we have today. And the real genesis of the move to advance reliability and security can be found
 in the 1965 Northeast blackout and the energy industry’s response to it—with the development of specific industry organizations to address reliability. The SaaS solutions used by energy industry participants utilize mutually authenticated server and client
 certificates. </span><span style="font-size:10.0pt;font-family:"Trebuchet MS",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in;text-align:justify"><span style="font-size:11.0pt;font-family:"Trebuchet MS",sans-serif">Energy industry customers use OU to associate user roles to an organizational security/business segment role. Removal of this
 field could not only make those software applications less secure by allowing users to see information they should not otherwise be able to see based on their job function, but also subject their organizations to FERC civil penalties of up to $1,291,894/day. The
 business purpose of the optional OU field cannot be underscored enough. <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE">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?<o:p></o:p></span></p>
<p class="MsoPlainText" style="text-align:justify"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-align:justify"><b><span style="color:blue">OATI Response: 
</span></b>Correct—those orders do not talk at all about the OU issue. NAESB is empowered to develop business practices for the natural gas, electric power, and retail electric industry segments. In 2007, NAESB specifically required the OU field, incorporating
 then-current business processes in the energy industry that had been using certificates for many years. In 2012, NAESB made the OU field optional which continued to support energy industry business process. Today, wholesale electric participants continue to
 use the OU field in practice as a means to support the identification and segregation between functions as required by FERC Orders 888 and 889. As mentioned previously, the FERC orders require different units to be “brick walled” from each other; the OU field
 is still utilized to do this, and every energy industry participant at the bulk power level is required to comply with this FERC requirement. 
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-align:justify"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-align:justify">FERC orders require segregation between business units for purposes of sharing transmission grid information—the orders have driven the incorporation of thousands of energy industry participants,
 and paved the way for more non-traditional participants. In the most recent FERC Order 2222, renewable energy loads at the level of 100 kW (~3 households) must be accepted by the energy markets, thus opening up the markets for residential-level participation.
 This is a revolutionary (not just evolutionary) perspective which will empower you and your neighbors in the push to behind-the-meter distributed assets and renewable generation. Once you appreciate the magnitude of changes these FERC Orders advance, understanding
 how energy industry participant business processes need to empower these changes should answer your question. 
<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE">On Wed, Sep 23, 2020 at 3:59 PM Michelle Coon via Validation <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>> wrote:<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="DE">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" target="_blank">763.201.2000</a>  <br>
Fax: <a href="tel:(763)%20201-5333" 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" 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" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a><o:p></o:p></span></p>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</body>
</html>