[Servercert-wg] Subject name requirements for CA Certificates

[Dimitris Zacharopoulos (HARICA)]

On 2019-10-25 12:34 π.μ., Ryan Sleevi wrote:
>
>
> On Thu, Oct 24, 2019 at 4:55 PM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>     Fixed via the correct reference to Annex IV of the Regulation.
>
>
> I don't think it changes the concerns in any palpable sense?
>
> Annex IV doesn't require the use of X.509 TLS certificates, and 
> there's plenty of compelling reasons not to use X.509 TLS 
> certificates. Whether you view it as intentional or a bug, the absence 
> of validation data being an essential part of a QWAC is incredibly 
> useful for ensuring the technical neutrality AND the robust 
> possibility of using QWACs in a multitude of systems, and that 
> coupling to TLS is explicitly the sort of stuff that Recital 27 is 
> trying to avoid.
>
>>         Forbidding this attribute in CA Certificates will make it
>>         impossible to add the "registration number as stated in the
>>         official records" to the TSP Certificate.
>>
>>
>>     This is categorically not true. Because you stated it's
>>     "impossible", it unfortunately requires me to show why you this
>>     is factually false:
>>     1) The eIDAS Regulation is technology neutral with respect to the
>>     approach, and does not mandate the use of the ETSI standards,
>>     even though in the case of Electronic Seals and Signatures, it
>>     grants a presumption of compliance with the Regulation
>>     2) Within the context of the ETSI profile, one can still issue
>>     such certificates using the profile defined by ETSI, and simply
>>     not doing so from the BR-compliant hierarchy
>>     3) Even absent that, the issue is not that it's impossible,
>>     rather, that it's incompatible with the ETSI-specified profile.
>>     ETSI can, and does, change profiles, and can, and could, do so here.
>
>     This is the real world we are discussing. These are decisions and
>     implementations that are already out there. These are requirements
>     that Supervisory Bodies are using to assess compliance with the
>     Regulation.
>
>
> 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.

>     I understand your arguments and theoretically you are correct. One
>     could include this registration number in an extension, in a
>     ledger, on a public web site URI even in an LDAP server.
>
>
> I'm glad we agree here. There are other options, and you aren't 
> limited, today or in the future.
>
> I think this is important to recognize that the technological 
> neutrality of eIDAS is exactly what makes it useful; there's nothing 
> requiring you to adopt a particular technology to fulfill the 
> requirement, and the whole point of technology neutrality is to 
> recognize particular technical implementations come with tradeoffs.

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.

>     However, all the regulatory authorities have received guidance to
>     follow ETSI's recommendations which currently point to the
>     organizationIdentifier. Why do we have to continue fighting over this?
>
>
> Because hiding behind eIDAS, when the issue is with ETSI, is 
> counter-productive. To the extent that ETSI continues to specify 
> things that are in opposition with the Baseline Requirements, we're 
> going to continue to have issues, and "But ETSI did it this way" isn't 
> a compelling argument. The barriers to participation in ETSI alone are 
> reason to be concerned, but the assumption that it has to be tied to a 
> specific technical implementation only penalizes TSPs unnecessarily. 
> To the extent ETSI presumes that TLS certificates are the idealized 
> form of QWACs is merely a reflection of some CAs' interests and 
> influence; they're completely ignoring the changes in the technology 
> space that 1) benefit from QWACs not being TLS certificates 2) allow 
> QWACs to be used far more widely than they are today, to provide far 
> greater assurances than they do today.
>
> Supervisory Bodies are not obligated to use the ETSI criteria.

 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. 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.


> There's presently no presumptive assumption of compliance with eIDAS 
> with respect to QWACs as there is with QSeals/QSigs, as Supervisory 
> Bodies make that determination and the Implementation Decisions and 
> Acts define. From speaking with various CABs and NABs (I promise you, 
> I care deeply about eIDAS and have done my homework), there is a vast 
> variety of schemes out there, which while they may use some or most of 
> ETSI with variants, means this isn't the dire straits you pose it as. 
> The flexibility you have in the selection of your CAB - and the 
> flexibility the CAB has with respect to the selection of the scheme 
> used in the production of the CAR for the SB - means you really aren't 
> as hamstrung as being suggested.
>
> This continues to be a challenge to the extent that some members 
> continue to promote melding multiple PKIs, with substantially 
> different objectives, into a unified hierarchy. That's neither good 
> nor necessary. Recall that some of the most significantly 
> disurptive misuses of PKI - DigiNotar and Flame - were the direct 
> result of unified PKIs. A number of CA members of this Forum have 
> taken that lesson to heart - I can point to alt-Roots used for a 
> variety of specialized services - and that's exactly the lessons we 
> should be taking.
>
> Continuing to cultivate the Gros Michel of PKIs is only leaving 
> greater exposure to the Panama disease of PKI, and we need to better 
> diversify, not simply saying "Well, Cavendish will do". It's learning 
> all the wrong lessons.
>
>     Let me rephrase:
>
>     "This community has not reported to have seen any harm (let alone
>     "ample") caused all these years by having organizationUnitName,
>     stateOrProvinceName or localityName subject attributes in CA
>     Certificates. HARICA has seen not seen errors or warnings or has
>     had any complains about delays or other problems from Relying
>     Parties or Subscribers. I am sure other CAs would confirm the same
>     thing".
>
>
> I'm not sure who you're defining as "community", but this is 
> definitely something that the technical standards bodies have run 
> into. You simply need look at CoAP or Delegated Credentials or the 
> amplification attack factors of QUIC, or the DoS factors of TLS 1.3, 
> to see that SDOs have been grappling with the issues here for quite 
> some time. I realize that many members don't attend IETF, and are not 
> familiar with the technical developments there, but you can simply 
> look through the presentations to see how many are concerned about 
> ensure that certificates are minimally sized, in the context of the 
> Web PKI. And that's not even touching on other PKIs that have not had 
> to deal with the historic baggage of the Web PKI and CAs' entrenched 
> behaviours, like Vehicle-to-Vehicle or Wireless Power Consortium or 
> mFI or USB-certified or FIDO.
>
>     If you search crt.sh you will find hundreds of Root CA and subCA
>     Certificates that include organizationUnitName,
>     stateOrProvinceName or localityName in the subjectDN. If there was
>     ample harm I can safely assume it would have been detected by now
>     and the ecosystem would have problems.
>
>
> My dude, the system has problems, and people are cobbling together 
> solutions, some of which would functionally exclude HARICA from 
> competing with other members in this Forum due to the practical 
> technical implications. For example, some proposals for certificate 
> compression noted that significantly better compression was achieved 
> by constructing a dictionary from the top N most popular websites. 
> This means if you used a certificate from the CAs responsible for 
> those websites, your site would be faster than if you used a 
> certificate from HARICA, or any other CA not in the top-N. It also 
> would functionally ossify profiles, imbuing better speed to the most 
> popular.
>
> And this is why I say that CAs don't really have any insight into 
> this: You don't see the data from users' having trouble checking OCSP; 
> you may see the requests, you don't see the sluggishness. You don't 
> see the impact to time-to-first-byte that affects your customers' 
> websites. You don't see the impact of having overtly large OCSP 
> responses, including unecessary certificates. And, in many cases, your 
> customers, the website operators, don't either. Nor do they see any 
> benefit from the added inclusion of LogoTypes in the CA certificate, 
> or the added locality data, or the cpsText rivaling Moby Dick. But the 
> users do and the browsers and the OS do, and they see the harm.
>
> All of this information does tie back to the Issuer, and the fields in 
> it. This isn't hyperbole, this are real problems that real engineers 
> are trying to solve for the majority of the Internet. The niche focus 
> doesn't help, and actively harms. User's don't have much choice here.

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.

>>     I'm not trying to convince you it's bad. I need you to convince
>>     me it's good.
>
>     Trust me, I'm an engineer! :) If that doesn't work, then I guess
>     the only good arguments I have to support this case are the following:
>
>     A) CAs must comply with the eIDAS regulation and the legal mandate
>     to create Certificates for website authentication that should be
>     able to convey the CA information (and its registration number)
>     within the end-entity certificates. The currently acceptable
>     solution to comply with this legal requirement is to follow the
>     ETSI profile and that's what Regulatory Authorities are looking
>     for. I don't need to explain further that following the law and
>     regulatory authorities is good.
>
>
> The eIDAS Regulation doesn't require the adoption of the ETSI 
> Profiles, particularly with respect to Annex IV.
>
> The ETSI profile has a number of significantly questionable 
> limitations, least of all being the forbidding of automatic cert 
> issuance due to the requirements imposed (not on the BRs), even in the 
> case of 319 411-1 (i.e. non-Qualified certificates using the PTC 
> profiles). I am not suggesting this was malice on ETSI's part, but I 
> would say the misalignment of objectives is significant enough that it 
> warrants re-evaluating the view of those technical criteria, and how 
> well they're aligned with browser objectives.
>
> The argument here boils down to "We should do it because we want to do 
> it because that's how we were doing it", when as you admit, there are 
> real and viable technical alternatives, readily deployable, that do 
> not require this.

This is definitely not the argument. It is "This is expected from TSPs 
to deliver and this expectation is set from Regulatory Authorities 
because this is their current guidance from the EU as the only existing 
fully-eIDAS compatible technical solution".

>     B) State and Locality information is useful information for
>     Relying Parties that want to lookup a certain Legal Entity and
>     want to narrow down their search.
>
>
> This is exactly what CCADB is for, which is made freely available.
>
> There is no need for this information to be expressed within the 
> Certificate itself. If you want to further make this argument, then 
> you're functionally arguing that what we should do is fully remove the 
> C and O fields, require an organizationIdentifier that is an LEI, and 
> then add a monotonically increasing number to the DN (or, 
> functionally, to the dnQualifier). This would meet your functional 
> example and the technical requirements, namely:
>
> 1) Unambiguous information about the operating entity
> 2) Unique DN
>
> Of course, in saying that, it should be obvious that 1 still isn't 
> /actually/ met. You can similarly look through crt.sh and see how 
> frequently the O field is a brand name, or a former brand name, of 
> some now-defunct organization or some entity who has no relationship 
> to the CA or its operation. And if we expect that CAs will continue 
> that trend, which we invariably need to in the continued M&A spree we 
> see, then we have to acknowledge that this information is dynamic, and 
> thus placing it within the certificate itself is nonsense for this use 
> case. Even an LEI doesn't tell you who controls the key.
>
> So really, we just need a unique ID per CA. Which is what I said 
> originally :) That's all we technically need, and for your use case 
> here, that's also all we functionally need.
>
>     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.

>     I believe one of the main reasons for recent disagreements you
>     have raised in various discussions (including the LEI ballot) is
>     that you see harm and you are against solutions that are useful
>     for "some" and only promote and accept solutions that are useful
>     for "all". For example, in this post you could argue that A) is
>     limited to CAs operating in EU territory, and that B) is limited
>     to a small set of Relying Parties. I hope in this case you will at
>     least accept the legal arguments about the rules that the EU
>     people have voted and described through their technical standards,
>     which were not considered in conflict or violation of the Baseline
>     Requirements at the time of writing, and at least agree on the
>     need to allow the organizationIdentifier field in CA Certificates
>     going forward.
>
>
> I don't agree on the inherent need. The argument as to both legal or 
> technical requirements are unsound.
>
> I'm extremely sympathetic to a desire for a transition, as I've 
> suggested, if there's a reasonable one.
>
> For example, allowing CAs to issue subCAs for one year with certain 
> added fields (e.g. organizationIdentifier), provided that sub-CA is 
> limited in lifetime (e.g. to two years). This would ensure that within 
> three years (functionally), things have transitioned off. That's an 
> age in Internet time, but that's more than sufficient time to adopt 
> other technical practices.

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.

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.


Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191025/58542b2f/attachment-0001.html>