EV Certificates
igoralferov opened this issue · comments
Static lists and signed assertions for UA Policy seem to require substantial implementation work.
It make sense to consider EV Certificates as an acceptable equivalent to signed assertions.
EV Certificates are issued on the basis of standardised vetting process performed by certificate authorities and confirm the fact that specific legal entity has control over specific domain name.
EV Certificate contain mandatory fields subject:organisationName, subject:jurisdictionLocalityName and subject:serialNumber, which jointly can be used as unique identifier of the legal entity. If present, optional field subject:organisationIdentifier can be used for the same purpose. If every domain in the declared first-party set will present EV Certificate for HTTPS connection, user agent can easily verify if all of them are controlled by the same legal entity based on these fields.
Browser vendors may consider to recognise the fact of having same legal controller for domain names in EV Certificates as sufficient to accept first-party sets.
As EV Certificates are widely supported, for site owners it will enable straightforward mechanism to work with first-party sets.
Would be good to hear your thoughts.
Hi Igor, basing this on EV (and/or OV) certs was one of our first thoughts and it certainly has some nice properties in that a lot of the verification infrastructure already exists. What changed my mind at least when it comes to this approach is the effects on certificate revocation. Right now, if a cert were to get popped or a CA compromised, CAs can generally issue new DV certs quickly and follow on with replacement EV certs in a matter of weeks. Practically this is a workable situation because sites can continue to operate with the DV certs, just without the extended validation information attached and presented to the user. If EV certs were to underpin FPS, they would no longer have the FPS association, which would trigger the data clearing activities nessesary when a domain leaves an FPS. This would be quite disruptive and runs counter to the security goals of making the CA infrastructure capable of reacting quickly to compromises.
Thanks, Brad! Valid point. My thought is that certificate revocation risk is more in the scope of first parties, they can issue two certificates from different CAs to tolerate CA compromise. If I'm right, HTTPS presents only one certificate during handshake, so to ensure that domain data won't be cleared in UA in case of revocation, sites will have to present backup certificate using some alternative access mechanism. Similarly to FPS manifest, it may be done via well-known location. Basically, idea is to consider EV certs as a special form of signed assertion, which is managed by CAs and do not require separate verification infrastructure & policies setup.
It make sense to consider EV Certificates as an acceptable equivalent to signed assertions.
EV Certificates are issued on the basis of standardised vetting process performed by certificate authorities and confirm the fact that specific legal entity has control over specific domain name.
Hi @igoralferov ! I represent Google in the CA/Browser Forum, and it sounds like there's some confusion :)
I think, first and foremost, our primary concern is that coupling identity information to the TLS handshake is actually bad for users. Coupling identity to encryption makes encryption much harder to manage over its lifetime. If features are restricted to EV certificates, it actually becomes harder for a site to deploy TLS, because it naturally becomes harder (or, in many cases, impossible) to get a certificate. That's bad for users, who need and expect HTTPS, so that's already a hard sell.
However, there's also some confusion here about what CAs do. I think "standardized" may be a generous interpretation. As it is, the "standard" is just that the CA has a self-determined process for doing this. They truly get to make up their own rules, and for those existing rules, make up their own interpretations. This ends up with a whole lot of inconsistency. To give you a taste of how bad things are, check out some of the issues we've seen. This is an area Google's interested in helping correct, but I think it's a big stretch to suggest it's in a good place.
Unfortunately, revocation isn't just the scope of the first party. The lack of agility really translates to a lack of encryption, and that directly affects end users. It's also a "hidden" cost that few plan for, so while in theory, multiple certificates can be obtained, that doesn't mean in practice.
It's also important to understand that the same organization, applying to two different CAs, can and almost certainly will have their certificate information encoded differently. The "standards" are not uniform in unambiguously identifying a globally unique organization, and subject to all sorts of whim and whimsy. This is true even within a Single CA. For example, during the sunset of the Symantec PKI, we discovered that just within Symantec, the British Broadcast Corporation (BBC) had over 65 different forms of encoded Subjects! There's no way to semantically bind to that information.
Perhaps more importantly, however, major browsers are already proposing an approach more aligned with the first-party-sets approach outlined here, of moving identity information out of the TLS handshake. You can read a joint document from Mozilla, Microsoft, Apple, and Google summarizing the past 5 years(!!!) of collaboration with the European Commission, ETSI, and ENISA regarding legal identities, and proposed alternatives to TLS-based expression.
That's a big list of "Why not", but that's not all. One of the focus areas and challenges has been complex corporate legal structures. The way EV certificates are designed, there's a lot of opportunity here for malicious, colluding actors to arrange legal havens in such a way that EV certificates "appear" to be the same organization. So, rather than getting an easy bootstrap, you actually end up with a complex, user-harmful approach (making TLS and encryption hard to deploy and manage), with a bunch of glaring opaque loopholes that can be exploited.
As @bslassey mentioned, EV certificates were definitely one of the things the team considered. On behalf of Google Chrome's PKI team, we raised serious concerns with the approach failing to meet the goals for transparency, consistency, and security. The current approach, while understandably challenging in its own right, definitely brings significant improvements over EV certificates - and more equitably, transparently, and open for site operators.
Hope that helps!
@sleevi Thank you for comprehensive answer!
Indeed, under these practical considerations it truly makes sense to decouple processes for TLS encryption infrastructure from legal identities and FPS.
In the context of FPS it is interesting to get more guidance or examples on how assertion signers are supposed to be reviewing & updating assertions and what is the bootstrap strategy.
Is it expected that signers will verify legal entities of domain name owners to establish affiliation?
If so, would it make sense to standardise and decentralise this process to companies operating CAs and TSPs, assuming that they will be interested to support new feature/cert type?
I can imagine that FPS can play some role in achieving broader adoption of website legal entity authentication, which is valuable for accountability and other web security controls.
I don’t want to speak for @bslassey , but I think the concerns of legal identity are largely orthogonal to the FPS problem.
Put differently, any problems you have for an FPS without a binding to a legal identity largely still remain when you have an FPS that is bound to a legal identity, because there are a myriad of ways you can structure a legal identity in order to evade technical controls coupled to legal identity. This is true for binding most features or control to legal identities, and is sort of the corporate equivalent to Falsehoods Programmers Believe About Names.
That said, the current design seems to support a variety of approaches, determined by assertion signers. They might choose to verify directly, given the tangible concerns around delegating trust (e.g. the large number of OV/EV certificates issued to companies in “Default City” of “Some-State” 😅). They might chose to delegate to a CA/TSP, or they might delegate to another third-party, like GLIEF. Or they could chose to ignore the legal identity aspect and focus on other forms of relationship, such as offline-proof-of-mutual-relationship. I don’t think the current design prescribes any particular solution, because there are definitely a variety of approaches.
That said, it doesn’t seem necessary, or even necessarily desirable, to use FPS as a means of promoting or encouraging legal identity. That’s largely orthogonal, and much like how encoding legal identity in TLS certificates can make encryption difficult, requiring legal identity for FPS can make FPS deployment harder, rather than easier. Legal identity may be complimentary, and may be useful for some degree of challenges or to aid transparency, but that seems like it might be premature?
In any event, that’s mostly for @bslassey to drive, but hopefully the above is helpful for some insight into the possibilities :)
Thanks, that's really helpful!
As I understand from discussion in https://github.com/krgovind/first-party-sets/issues/6 policy component is not in the scope of this proposal and left for individual UAs to define and enforce. At the same time, some degree of synchronisation of UA FPS policies will be a great outcome to manage expectations to website owners.
It would be really interesting to see progress on that. FPS signers implementation may be shaped depending on whether domain name legal entities are considered as a complimentary component of the policy checks or as a requirement.
I think it's helpful to include the main points from this discussion in the alternative designs section of the README, since the EV question keeps coming up and to be able to close the issue. I'll try to do that.
Everyone is explaining was does not work in the current infrastructure under EV.
And yes, that system seems not perfect at the moment, but it's still in use, although browsers do not show this EV status anymore.
But the question stays, what are the requirements for a safe, legal entity check (ownership check), and does it make sense to build up a body or a third party trustee to take that role to produce proof of ownership? In FPS subsets, ownership requirements still seem much lower than the business ownership proof. Sounds a bit strange to me. I´m not sure if the public suffix list process for example, is so safe and governed correctly.
I believe there is a need for trusted legal entity ownership in many of these processes.