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/CAEmnEreLmDpZM55aR1PJZ-MLfKmx1eGmjjo6zwX4Yrk7wxA_HQ%40mail.gmail.com.
