Mr. zxzxzx66669,
The "real" risk, which is illustrated through an adversary,
vulnerability, impact probability, risk mitigation strategy and the
residual risk doesn't matter. Hence is not discussed. I've yet to see a
comprehensive risk assessment on this matter.
The primary reason there is no real discussion is all the CAs have
chickened out due to the "distrust" flag from Mr. Sleevi. This is
supposed to be a community to freely discuss but he essentially
mentioned arguing = distrust. "Distrust" is equivalent to a death
sentence to a CA. So...can't really blame em chickening out.
As an individual observing this whole situation, I'm wondering too.
You are not alone.
Best regards,
T.K.
On 7/10/2020 7:35 PM, zxzxzx66669--- via dev-security-policy wrote:
On Wednesday, July 8, 2020 at 6:02:56 AM UTC+3, Ryan Sleevi wrote:
The question is simply whether or not user agents will accept the risk of
needing to remove the root suddenly, and with significant (e.g. active)
attack, or whether they would, as I suggest, take steps to remove the root
beforehand, to mitigate the risk. The cost of issuance plus the cost of
revocation are a fixed cost: it's either pay now or pay later. And it seems
like if one needs to contemplate revoking roots, it's better to do it
sooner, than wait for it to be an inconvenient or inopportune time. This is
why I meant earlier, when I said a solution that tries to wait until the
'last possible minute' is just shifting the cost of misissuance onto
RPs/Browsers, by leaving them to clean up the mess. And a CA that tries to
shift costs onto the ecosystem like that seems like it's not a CA that can
be trusted to, well, be trustworthy.
This assumes that the private key of these intermediate CAs will inevitably get
compromised.
Why such an assumption?
Following the same argument we can assume that the private key of any root CA
will inevitably get compromised and suggest all CAs to revoke their roots
already today. Does not seem to make sense.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
