On Mon, Jan 15, 2018 at 4:11 PM, Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> That said, GlobalSign's offer to cut certificate lifetimes down to X months
> during the short-term, and to make sure OneClick is disabled within Y
> months from now, seems like a reasonable compromise that doesn't undercut
> the incentive for GlobalSign or their customers to rapidly transition to
> more secure methods. It seems like there should be a value of X and Y that
> are acceptable.
>

There are a lot of factors to consider, as I tried to highlight, that
contribute to whether or not X can be > 0 and whether Y can be > 0 (e.g. no
issuance, immediate discontinuance) at all. That is, these additional
factors beyond the protocol itself inherently contribute to whether or not
there is a generalizable answer. Factors such as ecosystem impact versus
ecosystem risk, existing practices that can be used as mitigating factors,
the level of trust necessary to ascribe to the issuing CA (and the steps
that are taken to mitigate failures of that trust) - all influence that
calculus.

As worded in the BRs, .9 and .10 do not, in and of themselves, given the
facts, provide sufficient level of interoperable assurance. Their continued
use is a holistic examination not just as to whether or not it is possible
to design methods compliant to the existing language and/or whether to
remove the existing language, but whether or not their usage represents an
immediate risk to the ecosystem.

To some extent, this is a similar discussion to the question of SHA-1
issuance post it being forbidden (due to security reasons), and whether
sufficient information can be determined as to mitigate the limited risk.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to