[Servercert-wg] Subject name requirements for CA Certificates

[Wayne Thayer]

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> wrote:

>
>
> On Fri, Oct 25, 2019 at 1:20 AM Dimitris Zacharopoulos (HARICA) <
> 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 <http://www.fesa.eu/> 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
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191031/d3a6dcc0/attachment-0001.html>