[Servercert-wg] Subject name requirements for CA Certificates

[Mike Reilly (GRC)]

Thanks Wayne,  I’ve read all the mails on this thread.  From a Microsoft Root Program perspective I generally view the BRs as default deny.  My experience running security programs in general is that viewing policies and standards where practices are considered as implicitly permitted is an approach that can be problematic.   I’ve generally found “white lists,” e.g. if it’s not present it’s not permitted works better than “block lists” approaches.   So, I would look to participants in our program to read the BRs as default deny.  CAs in our program typically reach out when something is unclear with our program requirements or our interpretation of the BRs.   I look forward to the discussion on this topic.  Thanks, Mike


From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Wayne Thayer via Servercert-wg
Sent: Thursday, October 31, 2019 8:56 AM
To: Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Subject name requirements for CA Certificates

We've added the topic of "Default Allow versus Default Deny" to the F2F agenda. The discussion will take place on Tuesday Nov 5th at 13:15. I encourage everyone participating to review this thread prior to the discussion.

- Wayne

On Fri, Oct 25, 2019 at 8:28 AM Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>> wrote:


On Fri, Oct 25, 2019 at 1:20 AM Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr<mailto:dzacharo at harica.gr>> wrote:
This is still a bit of a misstatement. They're /some/ of the requirements that /some/ Supervisory Bodies are using.

If you have examples of Supervisory Bodies that allow the use of other technologies to claim compliance with the eIDAS regulation and convey the required information from Annex IV, it would be nice to hear about them. Then we might be able to convince the majority of Supervisory Bodies that they should switch to using these alternative technologies.

It's the CABs who set the scheme - e.g. the adoption of eIDAS - and the Supervisory Bodies that determine whether to recognize the CAR for notification. Did you mean to discuss with the CABs in the development of their scheme?

I'm highlighting this, because it's conceptually no different than the many spirited discussions about remote signing in the context of eIDAS, and the many conversations, some of which we've both been a part of, discussing the many approaches being used to demonstrate conformity to the eIDAS Regulation, which utilize a variety of technologies. It's this same flexibility that, for example, allows the use of cloud signing portals, or the use of document signing other than the XAdES/PAdES/CAdES solutions - because they are merely presumed conformant, but that in no way prohibits the use of other technologies with respect to the Supervisory Body.

At the same time, the harmonization problem is real and despite the regulation being technology neutral, the Commission is pushing for harmonization across the EU otherwise the cross-border mandate will fail. Such harmonization currently exists and is reflected in the ETSI standards. Although I don't participate in ETSI, I believe they are receiving specific mandates from the Commission to develop standards aligned with the legal framework.

I mean, yes, but again, none of that conflicts with what I was saying. The example of Commission Implementing Decision (EU) 2015/1506 is a great illustrative example of that point; while it formalizes the recognition (notably, based on the ETSI TS documents rather than the ETSI EN documents) of XAdES/PAdES/CAdES and requires, in the furtherance of the harmonization objective, that these be supported, it in no way limits the use of other forms (to note: Article 2 of that Decision), even though it sets forth a common expectation for certain formats for the purpose of interoperability (Article 1). It obligates the recognition of these, but does not preclude nor exclude other technologies, in keeping with Recital 27.

To the extent the harmonization problem is a thing, it's a question of "What's the minimum bar everyone must support". And that's an entirely reasonable question, in line with every other "Mandatory To Implement" discussion within SDOs. However, the MTI with respect to Member States granting legal recognition to certain signatures does not equal an MTI for TSPs; TSPs can work with their CABs to produce a CAR for the SB, and that SB/Member State can evaluate it as compliant with eIDAS and thus notify appropriately.

From my limited interaction with Supervisory Bodies, their current guidance from FESA<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.fesa.eu%2F&data=02%7C01%7CMike.reilly%40microsoft.com%7Cb24f09a5843142c0550a08d75e1ae7a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637081341980607589&sdata=MJf9dJGTMHvDYPEd5R0Avej6CtDuXiwIBFbs3A%2FSAJE%3D&reserved=0> is to accept ETSI as being in full compliance with eIDAS. And this makes sense to me. If "some" Supervisory Body and "some" TSP claimed compliance for eIDAS by providing subject information via "LDAP services", it would create interoperability issues and fail the cross-border mandate.

That's not correct! You can't suggest the cross-border mandate is implicitly a rejection of technical neutrality; the cross-border mandate with respect to mutual recognition is the technically independent part. The interoperability aspects, such as you see through Implementing Decision (EU) 2015/1506, certainly work to address a common baseline, but it is not to usurp the ability of Member States (SBs) to recognize other schemes.

I mean, let's get to the core: While ETSI represents a series of technical standards, ETSI EN 319 403 is not a scheme in-and-of-itself, it's the requirements set forth for a CAB to develop and implement a scheme, which will then lead to the production of a Conformity Assessment Report, which will then be evaluated with respect to the Supervisory Body as to whether that fulfills the objectives of eIDAS.

I believe the neutrality of the Regulation is more in the spirit of having an open mind for other and better solutions that comply with the entirety of the regulation. If another solution appeared to be compliant with eIDAS and superior to ETSI, then the Commission and FESA would be pushing for that. You must understand that whichever solution claims to be compliant with eIDAS it must not only implement the requirements of Annex IV but all the requirements for interoperability, cross-border, etc.

This is arguing two different things. If we take it at face value, the ostensible argument is that absent Commission Implementing Decisions, XAdES/PAdES/CAdES would have failed to fulfill the obligations of eIDAS, because absent the guaranteed/mandatory recognition, it would have failed the requirements for cross-border, since prior to that, Member States were left to recognize compliant schemes on their own. Yet at the same time, you're seemingly arguing that the existence of XAdES/PAdES/CAdES is a-priori an establishment of the fulfillment of cross-border obligations, since it exists as a document published by ETSI.

I know this sounds like we're deep in the weeds here, but I think it's fundamental to establish at least some baseline of agreement here: Which is that nothing obligates the underlying use of the ETSI ESI standards, and that is entirely good for the market, precisely because it allows the adoption of the right technology to the problem. I would similarly hope that we're in some baseline of agreement here that the ETSI ESI documents do not have an obligation to reach the maturity level of EN to be adopted, as demonstrably shown, and that the ETSI ESI TS documents can easily adopt.

Great info. So if your concern is the size of the Certificate let's make some rules about the maximum acceptable size of Certificates and not whether ST, L or OI will impact the size of the Certificate.

This is exactly what I wanted to avoid, because it demonstrates the fundamentally wrong way to approach the problem.

You're again trying to get to a point of arguing "Why not". I have no patience for that, because it's not answering "Why".

You haven't demonstrated a compelling reason as to why, from the CAs we trust, it is in the interest of our users and the websites they access, why including redundant, outdated, or unnecessary information in the certificate helps them.

The closest we've come here is "It would allow this to interoperate with other non-TLS schemes" (e.g. the S/MIME case), although that's easily shown as not relevant nor necessary (vis-a-vis EKU constraints)
The next closest we've come is "It would make it easier to integrate with the TSL/eIDAS", which, while useful as a statement, isn't an actual explanation as to why that's useful or aligned with the interests.

Again, this is about trying to demonstrate why it's useful.

You are a very hard person to convince, I'm sure you know that already.

I've got a brand to protect - but also a billion users to protect and respect and reflect their interests and to ensure website operators have interoperable choices that are aligned with their needs and interests. Even if it's not perfect for everyone, it's still better for most.

CAs share some of these goals, to protect relying parties and subscribers, respect their privacy, ensure that interoperable trust services are provided.

While I agree we share some, and that's why we continue to trust externally-operated sub-CAs for the provisioning of certificates, in lieu of other approaches that would obviate the need or relevance of such CAs, it's important that the arguments put forth show how and where the proposed changes align with those shared goals.

I don't think we've established where our shared goals are met by including this additional information.

Despite our disagreements about the "soundness" of the arguments, I would very much be in favor of this if only the Commission and the European Regulatory Authorities were notified that other solutions should be equally acceptable. I imagine that these other solutions would need to be standardized so they can be audited according to the requirements for conformity assessment.

There's a lot to unpack here, and I want to be careful as to how it's called out.

You're conflating two different interoperability objectives; interoperability vis-a-vis Member States and notified schemes and interoperability vis-a-vis various vendors' specific products. These aren't equivalent, nor are they fundamentally related.

As to your presumption of a standardized scheme, that too is "How it may work" not "How it must work". There's a whole lot of subtlety there, and I doubt we'll get on the same page via email here because of it. There's no question that, say, Recital 72 of the Regulation, emphasizes the importance and value with respect to delegated or implementing acts as to the recognition of ETSI, CEN, ISO, and ITU. However, that does not preclude Member States themselves have much more flexibility (vis-a-vis Article 12(3)b, for example).

It seems that the eIDAS - ETSI discussion should take place at different venues because I obviously don't have any authority to speak on behalf of ETSI or the Commission. At some point, it would be great if the Commission, ETSI, the Browsers and perhaps a representation of the TSPs could discuss and clarify the expectations of the lawmakers and how should those expectations be translated into technical standards that support harmonization, cross-border and other elements of the regulation in a technologically neutral way.

I think there is relevance here to some very essential discussions, which I think tie to the heart of the purpose of the CA/B Forum and the expectations of Root Programs.

At core question, and the very heart of the disagreement here, is whether or not a single root of trust is desirable. This is contextual both within a single TSP (e.g. should TLS and S/MIME come from the same root?)  and contextual across trust frameworks (e.g. should the Web PKI and eIDAS be required to use the same certificates?). The presumption, and this is not just for the European CAs, but notably across a number of others, has long been that "All products and services a given CA offers should be underneath the same PKI root", and that, as much as possible "All information validated by a CA should go into a single certificate".

This was very much the presumption of the ITU-T model of PKI from the 1980s, with the exception that the PKI was solely limited to authentication certificates, and all other information was to be captured within the X.500 DIT via the DAP. The X.500 model was resoundingly rejected.

The model that followed, the IETF model of PKI reflected within PKIX, and heavily influenced (for better and for worse) by the US government, and which mirrors that model captured by the ABA PAG, was that there may be a unified hierarchy, but policy identifiers and policy mappings would exclusively segment out the various populations. That is, a given Trust Framework Operator would define their own, Trust Framework OID, and then selectively through careful evaluation (and audits that mapped between CP and CPS), decide whether to grant a policy-mapping onto another PKI operator via cross-certification. Whether or not those policy mappings were transitive (i.e. if A offered B a policy mapping between A-ID to B-ID, could B-ID offer a policy mapping to C-ID back onto A-ID) was something contractually determined, but that relying parties would exclusively be looking for "Trust Framework Operator's" policy OID.

This is the model you see readily reflected within the PKIX (RFC 5280) standards, and the model you see throughout the US Federal PKI. There's a whole host of tradeoffs there, but it fully fits within that very American model of "Trust no one, and all the government agencies don't trust eachother, except where they do"

That, however, is still an overly complex model for what is necessary for the Web PKI, which is to say, the set of TLS-using clients that authenticate based on domain names and IPs. They use a much simpler model, replacing Policy OIDs, Policy Constraints, and Policy Mappings with EKU constraints. There are some who loathe the model, and for understandable reasons.

However, this history lesson is not just so I can blathe on, but to highlight that the shift, the model that has been embraced by the Web community, functionally and largely rejects the Grand Unified PKI model of either the DAP or the Policy Constrained/Policy Mapped CAs. It instead says "Different roots for different uses" and uses EKUs within the scope of a single trust framework. The idea of having a bunch of federated islands of PKIs is not the goal - it's fundamentally insecure and tremendously expensive to actually verify - but to have isolated islands of application-specific PKIs, serving a particular need. Browser PKIs aren't about federating between browsers - the Apple PKI cross-signing the Microsoft PKI - but about vendors wanting to ensure interoperability between the distinct and independent PKIs they offer.

I can appreciate that ETSI wants to specify a PKI that interoperates with the Google PKI, the Microsoft PKI, the Apple PKI, the Mozilla PKI, by specifying things in terms of RFC 5280 and trying to model after the set of common requirements and root program expectations. I regret that we encouraged it, for a time (of which I was one of the advocates for it), due to a mistaken understanding about the objectives at the time, and how misaligned our near-term and long-term goals are. However, there's no technical reason to try to encapsulate these very different PKIs, with very different objectives, into using the same Roots and same certificates. The harms outweigh the good.
_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>
http://cabforum.org/mailman/listinfo/servercert-wg<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg&data=02%7C01%7CMike.reilly%40microsoft.com%7Cb24f09a5843142c0550a08d75e1ae7a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637081341980617587&sdata=ifcepDwGzLfLe7aPrFGqkJv7VlOtw9j2E4X%2FzfBlhB4%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191105/276a467b/attachment-0001.html>