On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario <[email protected]> wrote:
> if the certificate is usable with PKCS#1 v1.5 signatures, it makes it > vulnerable to attacks like the Bleichenbacher, if it is not usable with > PKCS#1 > v1.5 it's not vulnerable in practice to such attacks > A certificate does not produce signatures - a key does. A certificate carries signatures, but only relevant to verifiers. Your reference to Bleichenbacher again makes it unclear if you're expressing a concern about the protection of the private key or the quality of the signatures, or whether you're conflating with ciphersuite negotiation and encryption. > > It does not do prevent such a signature from being created - that's what > I > > mean. > > now you're being silly > > the Mozilla policy doesn't prohibit the CA from making a service that will > perform RSA private key operation on arbitrary strings either but we would > still revoke trust from CA that would do such a thing, because just the > fact > that such a service _could_ have been used maliciously (to sign arbitrary > certificates) is enough to distrust it! > No, such CAs do exist, and we haven't revoked such trust. Your statement is empirically false. That's why I'm trying to be explicit in the policy here - that the policy is about the keys, not the certificates. > I don't think that it's the act of making the signature that weakens the > key > Great, then we don't need to restrict keys. > If I generate a certificate has RSA-PSS SPKI I won't be able to use it for > PKCS#1 v1.5 signatures - no widely deployed server will use it like that > and > no widely deployed client will accept such use. So a chance that a key > will be > abused like that and will remain abused like that is negligible. > > and that's the whole point - defence in depth - to make it another hurdle > to > jump through if you want to do something stupid > That's an argument often made for unnecessary complexity - or more aptly, the benefits of such defense in depth needs to be weighed against how that cost is distributed. In the case of RSA-PSS, because of the inanity of RFC 4055, that cost is distributed unevenly - it places the burden of such complexity upon the clients, which have repeatedly lead to exploits (and again, NSS has itself been vulnerable to this several times, or deftly avoided it due to Brian Smith's keen rejection of unnecessary complexity). It is a joint we don't need, and whose oiling will be needless toil. It also adds complexity to the CA ecosystem, for CAs who are unfortunately incapable of complying with the RFCs unless their hands are held and they are carefully guided down the happy path. To the extent those CAs should not be trusted is easy to say, but as shown time and time again, it's hard to express "You must be this competent to ride" in an objective policy, and even harder to address the situation where the CA is trusted and then let's all the competent staff go. > > > I understand - but I'm saying that what we're discussing fundamentally > > relates to the key. > > > > If a CA was technically constrained to .com, said they would never issue > > for something not .com, but then issued for .org, it's absolutely grounds > > for concern. > > If it doesn't matter whether a CA issues for .com or .org, and they > simply > > choose to only issue for .com, then it doesn't make sense to require > > clients to support the CA's expression of intent if doing so introduces > > security risk to clients (and it does) and complexity risk. > > so where's the bug that removes support for that in Firefox? Will we get > it in > before the next ESR? /s > You've again misunderstood the argument. But I'm not sure that there's much value in continuing - I've attempted to get you to either outline the value proposition or to outline the risks. We've danced around on semantic games, but we've identified that there is no risk in comingling these hash algorithms, that the only risk in being strict relates to a single software product with an unknown (but understandably miniscule, by virtue of no bugs being filed) number of extant certificates, while we have a profound opportunity to do the Right Thing based on lessons repeatedly learned. you're arguing that machine readable CA policy is a _bad thing_ ? > Yes, when the method of expressing that policy is unnecessary complex, burdensome, and error prone for both clients and servers. RFC 4055 is a bad RFC. It is a host of unnecessary joints and unnecessary complexity that does not, in practice, add any modicum of 'future compatibility' as it tried to do, does not in practice reduce any risks (as it tried to do), and does not provide any tangible value over a sane expression of that via policy. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
