<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 26, 2021 at 3:22 AM Howard Chu <<a href="mailto:hyc@symas.com">hyc@symas.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Phillip Hallam-Baker wrote:<br>
> On Sun, Oct 24, 2021 at 8:40 AM Howard Chu <<a href="mailto:hyc@symas.com" target="_blank">hyc@symas.com</a> <mailto:<a href="mailto:hyc@symas.com" target="_blank">hyc@symas.com</a>>> wrote:<br>
> <br>
>     Phillip Hallam-Baker wrote:<br>
>     > April King started a thread on Twitter about how to use SSH in the enterprise: Why aren't people using the SSH PKI, why do people roll their own key<br>
>     > provisioning scripts knowing these are almost certain to be disaster areas?<br>
> <br>
>     Good question. Pretty much every pain point you outline here is already solved in enterprises by LDAP.<br>
>     Rolling any other solutions just sounds like pointless protocol proliferation.<br>
> <br>
> <br>
> Since a major concern I raised was insider threat and since LDAP is a single point of trust, I fail to see how LDAP is remotely relevant.<br>
<br>
You cannot eliminate that central point. You have to give someone authority to terminate<br>
or disable an employee's access. Anyone who can do so can also reset their credentials.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Yet the Mesh does exactly that. It is a Threshold Key Infrastructure.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">LDAP was a less bad version of X.500 (mostly) developed by Netscape in the 1990s. I am very familiar with it. But it's primary function was to support the enterprise X.509/PKIX systems being developed by VeriSign and Entrust. And even then, it was more of a liability than an asset.</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> LDAP does not address the private key management either. All it does is provide one means of distributing certs.<br>
<br>
That is false. It can also be used to securely distribute the private keys. Painlessly,<br>
as demonstrated here <a href="https://twitter.com/hyc_symas/status/851170944345407488" rel="noreferrer" target="_blank"><span class="gmail_default" style="font-size:small"></span>https://twitter.com/hyc_symas/status/851170944345407488</a></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">So now you are generating private keys and distributing them to devices. What is the security model here? How do you authenticate the requests?</div><br></div><div><div class="gmail_default" style="font-size:small">If your answer is 'plaintext password to the LDAP directory' then all you have managed is a downgrade attack reducing a public key authentication system to a password based one.</div><div class="gmail_default" style="font-size:small"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I have never understood what advantage LDAP was<br>
> supposed to have over some HTTP scheme for that.<br>
<br>
The simple fact that LDAP implementations already come with mature security models with<br>
fine grained authorization and distributed administration makes it far more suitable than<br>
an arbitrary scheme cooked up over HTTP.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">So we should give up on computer security research, the problem is already solved. The fact there is a major breach every week must be an illusion.</div><br></div></div></div>