<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 10, 2015 at 2:45 PM, Ralf Senderek <span dir="ltr"><<a href="mailto:crypto@senderek.ie" target="_blank">crypto@senderek.ie</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 10 Jul 2015 01:32:55 Phillip Hallam-Baker wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The mesh does not do any cryptography at all, it is just a dropbox<br>
for exchanging small quantities of crypto info. So in the above example, the admin machine pulls the S/MIME and OpenPGP decryption keys<br>
that the device is going to need to read emails and encrypts them under the device key and uploads the profile to the mesh.<br>
</blockquote>
<br></span>
I understand that the mesh is something like a cloud storage for encrypted<br>
keys the user needs on different devices. It just makes the keys available<br>
wherever they might get used. But, doesn't that mean the secret keys must<br>
be stored in the devices in plain text? Or, if you use passwords to protect them, you'd run in all kinds of key management problems, (forgotten passphrases etc.)<br></blockquote><div><br></div><div>There are different levels of secret keys. The master keys are only ever constructed once unless there is a complete catastrophic meltdown requiring recovery. The admin keys would normally be password protected and kept on a few machines.</div><div><br></div><div>Remembering ONE [Singular] password as a second factor without any idiotic pa$$w0rd rules is pretty easy actually. Especially if you can have two words in the password. But since it is only ever used to unlock a private key that is on the user's device, brute force attacks aren't possible until after the user has been breached.</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The administration device at least must store the personal PKI's root<br>
signing key to be able to chain-in all other certificates a user might<br>
need. If you'd use a password for protection here, that'll be entirely<br>
necessary. So, if someone else's email cert has been accepted and<br>
chained, signed and uploaded to the mesh, it is available on all the<br>
devices, but how do you make sure, that the right cert is being<br>
accepted by the personal PKI? </blockquote><div><br></div><div>Actually, I have combined an idea by Brian LaMacchia and Phil Z.</div><div><br></div><div>The certificates for use in the mesh have a particular profile</div><div><br></div><div>1) The Subject key identifier is a UDF fingerprint (i.e. truncated SHA-2-512 digest) of the KeyInfo Block</div><div><br></div><div>2) So is the Authority Key Identifier.</div><div><br></div><div>3) Policy constraints and other PKIX idiocy are utterly ignored as they are utter crap.</div><div><br></div><div>4) Not using PKIX mechanisms for revocation. That is something that only really makes sense in a public PKI. </div><div><br></div><div>5) Each will eventually have a timestamp embedded that has the current integrity value of the mesh when it was created. This provides a method of defeating backdating attacks.</div><div><br></div><div>6) I add my own extension OID allowing me to specify the mesh purpose of the cert.</div><div><br></div><div>Reading through the docs on various chain building engines, I realized that getting them to do what I want would be very hard. Implementing what I want with some profile constraints, much easier.</div><div><br></div><div>A private PKI consists of of more than a dozen or so Certificate Signing Certs. When I read them into my cert collection, I can construct all the cert chains etc. with little difficulty. I verify that each cert is valid according to the profile requirements etc, and check that it chains to the root of the personal PKI.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I suspect you'll run into all the<br>
well-known difficulties that makes key management an unfriendly<br>
task for the ordinary user.</blockquote><div><br></div><div>You would not know you were using it. In use, the entire system is completely frictionless. The only time a user ever needs to be aware of using encrypted mail is when they want to force use of encryption or force use of encryption with a key they have a verified fingerprint of.</div><div> </div></div><br></div></div>