For the issuing keypair I didn't expect that it must always use a specific signing algorithm in this regard. The leap that I mean is a requirement on signing based off of the algorithm of the keypair. I agree that is what the policy says.
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. 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. On Thursday, May 30, 2024 at 6:13:36 PM UTC+1 Aaron Gable wrote: > On Thu, May 30, 2024 at 9:58 AM Wayne <[email protected]> wrote: > >> Yes the part that threw me off was the jump from the intermediary signing >> key to the signature of an end-user certificate. I didn't expect a leap to >> that extent without requirements on RSA/ECDSA public keys given where the >> chain of trust breaks. > > > I'm not sure I follow; can you clarify what you mean by this? > > There are two requirements here: > - An issuing keypair of a given type (e.g. "RSA 4096", or "ECDSA P-384") > must always use a specific signing algorithm correlated with that key type > (e.g. "RSASSA-PKCS1-v1_5 with SHA-256", or "ECDSA with SHA-384", > respectively); and > - A specific signing algorithm (e.g. "RSASSA-PKCS1-v1_5 with SHA-256", or > "ECDSA with SHA-384") must always have a particular DER encoding (e.g. > "300d06092a864886f70d01010b0500", or "300a06082a8648ce3d040303", > respectively) in the resulting certificate's > signatureAlgorithm.AlgorithmIdentifier field and tbsCertficiate.signature > field. > > This chain of logic -- specific signing keys must use specific signing > algorithms, and specific signing algorithms must be represented with > specific encodings -- doesn't seem to have a "jump" to me, so I think I > must be misunderstanding your statement? > > Thanks, > Aaron > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/6e512f19-4bd2-4945-92bf-fa94c7cdf9a7n%40mozilla.org.
