I did not state the point well. "Scary example" as I used it above was merely because it was a reference to StartCom at all (given the history, etc.) -- not particularly in the context of this practice.
I concur that I see no risk in leaf certificates issued with signatures over public keys for which neither ownership or control of the corresponding private key have been established. I merely wished to add an example case to the discussion in which it was presumably possible to have leaf certificates issued over a public key for which the control of private key had not been proven. On Mon, May 18, 2020 at 12:44 PM Ryan Sleevi <r...@sleevi.com> wrote: > On Mon, May 18, 2020 at 11:40 AM Matthew Hardeman via > dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > > A scary example, I know, but StartCom's original system was once > described > > as taking the public key data (and they emphasized _only_ the public key > > data) from the CSR. Everything else was populated out-of-band of any PKI > > protocols via the website. > > > > Frankly, I don't see how anyone permitting signature over a third party > > public key without proof of control of the matching private key creates a > > risk. I think if there are relying-party systems where this creates a > > problem, the error is in those relying-party systems and their respective > > validation logic. > > Why would StartCom's system be "A scary example" when you acknowledge > that you don't see how it creates a risk? The scenario you ascribe to > StartCom is exactly what is recommended, of CAs, in numerous CA > incident bugs where the failure to apply that restrictive model has > lead to misissuance. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
