IMO the problem is worse if considered from the perspective of the user. There is no visual distinction that the chain of trust goes back to a local admin managed store and that the admin can arbitrarily trust certificates outside their proprietary domain.
It should be perfectly reasonable and probably required for an employee to be able to order reimbursed things like travel arraingements with a credit card on their org provided device, but that org may MITM any trust chain for some administrative convenience.
The org itself could cross sign with name constraints if they opt to be good, but would probably end up filing a lot of bugs in various software that can't handle it and their being good is the kind of selfless act that rarely happens without a regulatory requirement to pay for consequences of doing a MITM of your employees on the Internet.
To me, this seems like a solid tradeoff of authority.
In practice, complexity and customizability breeds ossification, because "safe" becomes the tiny sunset of common configuration.
I could definitely see network appliance vendors, IT network security admins, endpoint security vendors, etc. rapidly fucking up everything.
At least with delegation to browser vendors + certificate transparency logs, we have a semi standard path for a detrust like this to be forced without exploding the ecosystem.
Additionally, if there were more wiggle room, you'd alter the balance of power between browsers and CAs, which seems decently calibrated now.
The local admin means "the user's employer's IT department", which, for the sake of a work laptop, they implicitly trust way more than Mozilla/Microsoft/Google/Apple etc who managed the public root stores.
I don't think a lot of people have the ability to prioritize employer with an IT department in the top percentile over other factors like location, pay and willingness to hire.
Whether CA/B is good or bad at what it does, it puts about a thousand times more effort into the question of whether to install a CA certificate in the browser than a company that just bought the cheapest solution to one of its problems and wants to install the corresponding vendor certs.
How many things could be wrong with that system and cause user's traffic to be compromised web wide? What community is checking transparency logs and threatening Cisco to revoke their authority to sell that product? What would that even mean?
I can imagine an organization wanting to run a CA for all kinds of reasons, and wanting to ignore some CA/B forum rules for all kinds of reasons. And, if that organization owns name.com and wants its employees to use ordinary web browsers (on corporate devices) to access resources protected by those certificates, then it seems entirely reasonable to have a *.name.com name constraint. The only problem is that browsers don’t support this.
If they understand that they are bound to respect this, why don't they add the name constraints to their CA certificate?
The problem as I see it is that whatever method used is optional and insufficient to protect users until the browser highlights the source is not real public trust. Google knows this and started with the claim they prioritize user security while ending with the work around to prioritizing user security. (And without the slightest warning that sending your users to a bunch of financial institutions using improper trust chains is ethically dubious and requires more consideration than the time it takes to click the settings.)
Name constraints have not been supported by browsers for very long. And they can’t solve this problem for private CA certificates that already exist. (Hmm, I wonder if issuing a new CA certificate with name constraints using an existing private key could be made to work.)
Comments
Exactly. I’d also like to be able to trust a certificate for a limited set of domains. This would be extremely valuable for all kinds of use cases.
IMO the problem is worse if considered from the perspective of the user. There is no visual distinction that the chain of trust goes back to a local admin managed store and that the admin can arbitrarily trust certificates outside their proprietary domain.
It should be perfectly reasonable and probably required for an employee to be able to order reimbursed things like travel arraingements with a credit card on their org provided device, but that org may MITM any trust chain for some administrative convenience.
The org itself could cross sign with name constraints if they opt to be good, but would probably end up filing a lot of bugs in various software that can't handle it and their being good is the kind of selfless act that rarely happens without a regulatory requirement to pay for consequences of doing a MITM of your employees on the Internet.
To me, this seems like a solid tradeoff of authority.
In practice, complexity and customizability breeds ossification, because "safe" becomes the tiny sunset of common configuration.
I could definitely see network appliance vendors, IT network security admins, endpoint security vendors, etc. rapidly fucking up everything.
At least with delegation to browser vendors + certificate transparency logs, we have a semi standard path for a detrust like this to be forced without exploding the ecosystem.
Additionally, if there were more wiggle room, you'd alter the balance of power between browsers and CAs, which seems decently calibrated now.
The local admin means "the user's employer's IT department", which, for the sake of a work laptop, they implicitly trust way more than Mozilla/Microsoft/Google/Apple etc who managed the public root stores.
I don't think a lot of people have the ability to prioritize employer with an IT department in the top percentile over other factors like location, pay and willingness to hire.
Whether CA/B is good or bad at what it does, it puts about a thousand times more effort into the question of whether to install a CA certificate in the browser than a company that just bought the cheapest solution to one of its problems and wants to install the corresponding vendor certs.
For example: https://docs.umbrella.com/deployment-umbrella/docs/install-c...
How many things could be wrong with that system and cause user's traffic to be compromised web wide? What community is checking transparency logs and threatening Cisco to revoke their authority to sell that product? What would that even mean?
That sounds like a problem for the IT department, not the end user?
Sure, their proactive attitude is why credit card fraud is referred to as "organization theft".
I can imagine an organization wanting to run a CA for all kinds of reasons, and wanting to ignore some CA/B forum rules for all kinds of reasons. And, if that organization owns name.com and wants its employees to use ordinary web browsers (on corporate devices) to access resources protected by those certificates, then it seems entirely reasonable to have a *.name.com name constraint. The only problem is that browsers don’t support this.
If they understand that they are bound to respect this, why don't they add the name constraints to their CA certificate?
The problem as I see it is that whatever method used is optional and insufficient to protect users until the browser highlights the source is not real public trust. Google knows this and started with the claim they prioritize user security while ending with the work around to prioritizing user security. (And without the slightest warning that sending your users to a bunch of financial institutions using improper trust chains is ethically dubious and requires more consideration than the time it takes to click the settings.)
Name constraints have not been supported by browsers for very long. And they can’t solve this problem for private CA certificates that already exist. (Hmm, I wonder if issuing a new CA certificate with name constraints using an existing private key could be made to work.)