On Thu, Nov 30, 2017 at 3:23 PM, Hubert Kario <[email protected]> wrote:
> On Thursday, 30 November 2017 18:46:12 CET Ryan Sleevi wrote: > > 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. > > 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 > Then I think this is an incredibly convoluted concern. If I'm understanding correctly - and I hope you can correct me if I'm not - the view is that it is valuable to limit a public key via an unnecessary complex encoding scheme so that it does not get used for encryption (in what protocol? Obviously not X.509 - so presumably certificates) so that it is robust against CCA like Bleichenbacher? It feels like I just spewed out words writing that out, because it does not seem like it fits a consistent or coherent threat model, and so surely I must be missing something. It does feel like again the argument is The CA/EE should say 'I won't do X' so that a client won't accept a signature if the CA does X, except it doesn't change the security properties at all if the CA/EE does actually do X, and the only places it does affect the security properties are either already addressed (e.g. digitalSignature EKU) or themselves not protected by the proposed mechanism. This doesn't make sense. It's not good policy. > > > 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! > I thought I already demonstrated that this was false, because the statement of capability is n capabilities to 1 key, and who makes those statements is not the private key. And that intention can be expressed through means other than the inanity of RFC 4055 to begin with, or that intention is an unnecessary option imposed on clients to satisfy the whims of the signature producer, and we should favor clients over producers. > 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 > And this is where I disagree - the fact that deriving them from the associated certificate imposes a significant cost upon clients is something to be concerned about and worthy of prohibition. There's no need to outsource the implementation cost upon the ecosystem for what can and ostensibly should be the CA's ability to control. > > > 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 don't think it is. There has been a constant conflation between a desire to: 1) Ensure that a sufficient level of security is afforded all clients against known risks 2) Allow producers flexibility to implement their arbitrary security policies I disagree that 2 should be a consideration, unless it comes without client cost. In the case of RFC 4055, it comes with substantial client cost (as already demonstrated by the missteps made by NSS, past and present), and so such flexibility is unreasonably complex. We've also seemingly reached agreement that, with respect to 1, it's either a matter of client policy (to accept or reject a given 'weak' signature) or that it's a matter of cross-algorithm attacks (which we've agreed doesn't undermine security) So 1 doesn't apply, 2 is too costly, and clients matter more than producers. > 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 also have the mantra "Have one joint, and keep it oiled". The lessons we saw from the conversion of TLS 1.2 to TLS 1.3 repeatedly underscore the need to pursue simplicitly over unnecessary flexibility. You have yet to articulate any argument in favor of that flexibility either than "someone might want it" and "a mostly unused for this case system started using it". Those are poor arguments. Meanwhile, we have identified past security bugs and present compatibility bugs from such flexibility, we've taken intentional steps in the past to curtail such flexibility (c.f. the change in how NSS validates RSA-PKCS#1v1.5 signatures to be memcmp based rather than decodebased), and yet, seemingly, somehow, this time we'll get it right - even though it's already been done wrong. > that's about RSA-PSS parameters in SPKI or about RSA-PSS OID in SPKI? > Both! I think the 'correct' solution from a policy perspective, given these constraints, is: - rsaEncryption as SPKI is perfectly fine (and, indeed, the only one that interoperates) - I would even go as far as to say rsaEncryption as SPKI should be *required*, as anything else is merely an expression of intent that only matters if the private key control has been lost or confused - The policy itself should express that while the certificate may not express the intent, any other use of the associated private key is a fundamental trust violation, regardless of whether or not clients will accept it (again, because it means you've lost control of the key / cannot keep it constrained as you intended to) - If allowed, it should be fully absent or byte-for-byte identical to the signature - rsaPSS as the signature - It should have byte-for-byte encodings of the blessed forms for PSS + SHA-256/384/512 - This means no salt size variability as an unnecessary complexity that imposes decoding costs upon the client - It should be byte-for-byte matched with the SPKI if PSS-in-SPKI is permitted and present - Any violation of that (tbsCert.signature / tbsCertList.signature != issuer.SPKI) is misissuance. Regardless of whether a 4055 client would accept/reject it _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
