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

Reply via email to