[Servercert-wg] Subject name requirements for CA Certificates

[Ryan Sleevi]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191025/5c1b2e0e/attachment-0001.html>