On 11/01/2019 13:04, Peter Gutmann wrote: > Jason via dev-security-policy <dev-security-policy@lists.mozilla.org> writes: > >> I would say that the problem here would be that a child certificate can't use >> a higher cryptography level than the issuer > > Why not? If the issuer uses strong-enough crypto, what difference does it > make what the child uses? > > Peter. >
Really? If the CA key is weaker than the child key, an attacker can break the CA key and sign a fake certificate with less effort than breaking the child key directly (for modern crypto that "easier" is the difference between degrees of resistance to future cryptanalytic attacks, thus often involving some guesswork). This obviously is less effective for encryption public keys than signature public keys, as faking a new certificate doesn't provide access to data encrypted to the real certificate. It is also ineffective if the certificate is checked against additional criteria than the CA signatures, such as a strong Merkle hash tree or non-cryptographic proof of the certificate contents. Thus signing stronger child keys from weaker CA keys is often allowed as a transition mechanism when a trusted root with strength n has been widely distributed, yet there is a desire to introduce new keys with strength m > n . The typical way (at least in the past) is for the strength n CA key to cross sign a strength m CA key, which is also made available as its own root cert for future deployment, thus eventually removing the reliance on the strength n key to validate the strength m keys. This was seen a lot during the long transition from RSA-SHA1 to RSA-SHA256, and some CAs may wish to prepare early for future transitions from RSA-SHA256 and ECDSA-SHA256 to stronger algorithms. Similarly, some users obtained end certificates based on 2048 bit RSA back when 1024 bit RSA was the norm. Similarly situated users today may wish to get ECDSA-P-521 or EdDSA-488 keys at a time when half as long keys are the norm. While getting such certificates from a weaker CA is obviously vulnerable to future attacks on the CA key, at least this provides a safety margin where the mitigations mentioned above are likely to be available. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
