On 2017-04-11 17:54, Ryan Sleevi wrote:
On Tue, Apr 11, 2017 at 11:44 AM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
The reply indicated that it was a non-browser application. So I understand
that a browser should never see that certificate.
There's no way to objectively quantify or assess that, however. My question
still remains - what are the criteria for determining this, and what
process is in place for disagreement about this risk?
The question is, can that certificate be used for authenticating something
it shouldn't? And I guess that's not the case.
No. That is not the question.
The problem with 1024 keys is that someone with enough resources can
find the private key. I assume there are no other (new) certificates
with the same key. So I think there are 3 potential problems:
1) The subscriber itself can be attacked
2) The rest can't enforce the 2048 limit, so we can't be sure we're not
attacked.
3) The certificate could be used to authenticate something else
He said "we believed that issuance of this cert didn't impose risk on
anyone but this specific customer", which would be 1).
I don't think 2) applies. It's only their software, that obviously can't
be updated yet, and so won't enforce such limit. That doesn't prevent
the rest of us to set such limit.
Which would only leave 3)
Kurt
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
