[Cryptography] The Mesh

[Phillip Hallam-Baker]

On Sat, Jul 11, 2015 at 8:38 AM, Ralf Senderek <crypto at senderek.ie> wrote:

> On Sat, 11 Jul 2015 05:37:18 Phillip Hallam-Baker wrote:
>
>  A private PKI consists of [no] 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.
>>
>
> That raises the question how the decision to include any particular
> Signing Cert is reached. If for a frictionless use case the user
> has nothing to do with this decision, how should he gain any trust
> in the validity of his own personal PKI?


Making trust decisions in a personal PKI is trivial. Either it chains up to
the personal root of trust that has his personal fingerprint or it does
not. The only way that a certificate can chain to her personal root is if

1) Alice signed it
2) Alice lost control of her key
3) The algorithm has been broken

I don't try to stop (2) beyond keeping the master keys offline and locking
the online admin signing keys to specific devices, instead I provide a way
to recover if there is a disaster.


 In use, the entire system is completely frictionless.
>>
>
> That's your most important selling point.


Yes and that goal comes before perfecting the security. This is pretty good
security, not perfect.




>
>  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.
>>
>
> How did this verification happen? Why is it secure?
>

Using strong email addresses, the fingerprint of the root of trust for the
receiver is embedded in the email address. So if you send an email message
to:

MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ?phb at hallambaker.com


The email address is legal rfc822 and can be stored in a contacts directory
but the username isn't legal on any operating system or sensible webmail
system (injection error city).

If the message is sent through the prismproof.org email proxy, it will
strip out the fingerprint, try to pull an email profile with the specified
fingerprint from the mesh and extract an S/MIME key that chains to that
root.

[OK so right now it is doing that without actually doing the path math to
validate the chain but that is just a matter of coding]


Again, I think the scheme does not answer the most important question of
> how a user can be sure he's using the correct correspondent's key, if
> all decisions regarding the validity of keys are done on his behalf by
> "the mesh" and "a tool".


The mesh isn't a trust infrastructure. That is a separate problem. I have
written a paper on the problem but before I can work on the trust problem I
need to solve the distribution problem.

One layer of security is provided by having a CA issue a cert using an
email loopback challenge.


I am also looking into doing a peer to peer loopback automation scheme.
This is a consequence of working out how to automate S/MIME cert issue
(same approach works for OpenPGP of course).

Alice sends an email to Carol (who may or may not be a CA). It contains
headers:

ACME: MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ?alice at example.com;
   challenge=VGhpcyB3YXMgb2J2aW91c2x5IGFuIGV4YW1wbGUu

Carol responds:

ACME: MOF3W-K23MN-BYWY2-3FNJT?carol at example.com;
   challenge=cXdsa2VrbHF3amhlZmxranFoZGZsa2poYWRsa2ZqaGFsc2Rsa2pobA0K
ACME-Response: MOF3W-K23MN-BYWY2-3FNJT?carol at example.com;
   by=MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ?alice at example.com;
   challenge=VGhpcyB3YXMgb2J2aW91c2x5IGFuIGV4YW1wbGUu;
   nonce=d2xrZWpmaGFsa3NqZGZobGtzYWpoZGZsa2phaHN;
   result=kZmtsamhrbGFzZGtsZmtsYWpzZGhma2xqaAYUxLZXJ5M28

[Alice will now respond in like form in their next interaction]

So if the response is valid Carol has demonstrated:
 1) The ability to read email sent to carol at example.com.
 2) Control of a private key trusted in the personal pki with the root
MOF3W-K23MN-BYWY2-3FNJT
that is authorized to respond to challenges.


This is a pretty good starting point for Alice and Carol to start
exchanging messages that are encrypted by default.

Of course, it is really desirable for any mail exploder or the like to
strip out the headers and responses should be ignored if there is an
exploder header in the response. Otherwise some mailing lists will get lots
of encrypted mail. But at this point there aren't many mailing lists that
are that broken.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150711/83d3f6c0/attachment.html>