[cabf_validation] Revision to OU requirements

[Ryan Sleevi]

Thanks Michelle,

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.

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?

On Wed, Sep 23, 2020 at 3:59 PM Michelle Coon via Validation <
validation at cabforum.org> wrote:

> OATI has the following comments regarding the OU field discussion:
> 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.
> 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.
> 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.
>
> Michelle Coon
> Associate Director, Compliance
> Phone: 763.201.2000 <(763)%20201-2000>
> Fax: 763.201.5333 <(763)%20201-5333>
> Open Access Technology International, Inc.
> 3660 Technology Drive NE, Minneapolis, MN 55418
>
>
>
> 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.
>
>
> -----Original Message-----
> From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of
> Kurt Roeckx via Validation
> Sent: Monday, September 21, 2020 3:47 PM
> To: Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Validation SC List <
> validation at cabforum.org>
> Subject: Re: [cabf_validation] Revision to OU requirements
>
> {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.}
>
> On Mon, Sep 21, 2020 at 02:01:20PM -0400, Ryan Sleevi via Validation wrote:
> > Can you clarify: Was this at the request of BCSS (the "server", in
> > their
> > parlance) or in the use of TLS certificates as client-auth certificates?
> >
> > This appears to be detailing a very specific mutual-TLS authentication
> > flow, and it's unclear whether or not a browser-used CA is essential
> > for this.
>
> 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.
>
>
> Kurt
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/validation
> _______________________________________________
> Validation mailing list
> 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/20200923/055b0424/attachment.html>