On Thursday, 30 November 2017 18:46:12 CET Ryan Sleevi wrote: > On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario <hka...@redhat.com> 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.
and verifiers are who enforces if the signatures are sane and for verifiers only the certificate is visible, not private key and certificate for the user of the key is essentially a blob, not something he or she can edit, so it is a commitment (even for CA, as that self signed one is no longer in control of it) > 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. key with rsaEncryption SPKI can be used for both signatures and encryption, key with RSA-PSS SPKI can't be used for encryption if at least one party is standards compliant and the only way the other party can tell if the key is a rsa or a rsa-pss key is by looking at the certificate so if the _private_ key is rsa or rsa-pss type is of purely philosophical concern > > > 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. but the private keys are invisible and they should be invisible to anyone but the owner! the only way to check if they are used according to their intention is to look at the corresponding certificate! it's fully an implementation's detail whether implementation stores the rsa- pss params with the private key or derives them from associated certificate - it doesn't matter > > 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. that's cherry picking and taking sentences out of context... > > > 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. the only risk you're bringing up again and again is a nebulous "but it's hard to do, so we may make mistakes" guess what: that's the case for all of crypto, all of network protocols, that's why we repeat the mantra of "don't implement crypto yourself", it's silly to bring it up in the first place > We've danced around on semantic games, And how am I supposed to answer to that without invoking an ad hominem? > but we've identified that there is no risk in comingling these hash > algorithms, no, there is risk, we just can't quantify it > 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. that's about RSA-PSS parameters in SPKI or about RSA-PSS OID in SPKI? > > 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. I already said I'm ok with the hardcoded encoding of the RSA-PSS params, with salt sizes assigned to hash sizes, and I started by saying that I'm ok with forbidding RSA-PSS params in EE certificate SPKI, that's not enough for you? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
