I think there's still some confusion here. On Thu, May 30, 2024 at 10:23 AM Wayne <rdaurn...@gmail.com> wrote:
> That is also why the censys queries are crafted as you saw, I expected any > algorithm choices to be more constrained, i.e. RSA intermediary must issue > RSA certs, ECDSA intermediary must issue ECDSA certs. There there isn't a > limitation that but an explicit choice in signing makes me wonder what the > security guarantees were intended to be. > There is no choice in signing[1]. The signing algorithm used by the CA is determined by that CA's keypair. What there *is* is a choice (made by the subscriber, not by the CA!) of what kind of public key to submit in the CSR. Imagine a classic, very simple CA. They have one RSA 4096 root <https://crt.sh/?id=9314791>, and one RSA 2048 intermediate <https://crt.sh/?id=3334561879>. Every signature they produce <https://crt.sh/?id=12576487857> will be sha256WithRSAEncryption, and every certificate they issue will encode that signatureAlgorithm using OID 1.2.840.113549.1.1.11. What should they do when an applicant submits an ECDSA P-384 public key in a CSR? Should they be forbidden from issuing that certificate <https://crt.sh/?id=13234399746>? What security benefit would there be to refusing such a request? Footnote [1]: Yes, there is some choice in the signing algorithm for RSA issuers, but that choice is still limited and there is no choice for ECDSA issuers. We currently have RSA-2048 intermediaries that are publishing P-384 > certificates that are held to a lower standard than a P-256 intermediary > doing the same. You can understand my surprise here I hope? I simply didn't > expect the keypair and signing algorithm to apply to child certificates in > this manner. > Allow me to expand this sentence a little bit: "We currently have RSA-2048 intermediates using the sha256WithRSAEncryption signature algorithm to sign certificates containing ECDSA P-384 public keys. These certificates have lower cryptographic security than if they were issued from an ECDSA P-384 intermediate using the ecdsa-with-SHA384 algorithm." Is that an accurate understanding of what you mean by "held to a lower standard"? But then I could say something similar: "These certificates have lower cryptographic security than if they were issued from an RSA 4096 intermediate using the sha512WithRSAEncryption signature algorithm." There's nothing special about the switch from RSA to ECDSA in your example; there are always ways in which the security could be improved, but they all come with tradeoffs such as certificate size or validation time. At the end of the day, the public key submitted by the applicant/subscriber in their CSR *doesn't matter*. Yes, CAs are required to do a number of checks on that key -- ensuring it isn't known to be compromised or easily factored, for example -- but there is no security benefit to correlating the subscriber's keypair type with the issuer's keypair type (and therefore the issuer's signing algorithm). Aaron -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErcwb1yAPcTi3MepVu_sWzaLWSYeEiV2__A6t0hmKs7ocg%40mail.gmail.com.
