[cabf_validation] Revision to OU requirements

Thu Sep 24 08:50:29 MST 2020

Thanks Christian,

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.

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.

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.

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.

On Thu, Sep 24, 2020 at 11:38 AM Christian Heutger <ch at psw.net> wrote:

> Hi Ryan,
>
>
>
> 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.
>
>
>
> Regards
>
> Christian
>
>
>
> *Von: *Ryan Sleevi <sleevi at google.com>
> *Datum: *Donnerstag, 24. September 2020 um 16:00
> *An: *Christian Heutger <ch at psw.net>
> *Cc: *CA/Browser Forum Validation SC List <validation at cabforum.org>
> *Betreff: *Re: [cabf_validation] Revision to OU requirements
>
>
>
> Hi Christian,
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> On Thu, Sep 24, 2020 at 5:26 AM Christian Heutger <ch at psw.net> wrote:
>
> Hi,
>
>
>
> 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.
>
>
>
> Regards,
>
> Christian
>
>
>
> *Von: *Validation <validation-bounces at cabforum.org> im Auftrag von Ryan
> Sleevi via Validation <validation at cabforum.org>
> *Antworten an: *Ryan Sleevi <sleevi at google.com>, CA/Browser Forum
> Validation SC List <validation at cabforum.org>
> *Datum: *Donnerstag, 24. September 2020 um 00:11
> *An: *Michelle Coon <Michelle.Coon at oati.net>, CA/Browser Forum Validation
> SC List <validation at cabforum.org>
> *Betreff: *Re: [cabf_validation] Revision to OU requirements
>
>
>
> 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/20200924/2e860c14/attachment-0001.html>