<div dir="ltr">Does anyone know what the Dark Mail Alliance specs might look like?<div><br></div><div>I have been trying to contact the principals with no success.</div><div><br></div><div>Its no secret that I am working on a secure email scheme based on PGP and S/MIME and have proposed a series of drafts to the IETF. It would be nice if this time round we could end up with one specification rather than two.</div>
<div><br></div><div>The rest of this message is a heads up for folk who are interested in working on this problem that there are code projects they might consider. Given all the crap I have done with government agencies over the past two decades I don't think people would be well advised to place absolute reliance on my code even if it is open source. I also don't want to rely on just one crypto stack.</div>
<div><br></div><div>The good news for folk wanting to do that is that since I work in C#, anyone else who wants to write an implementation of one or both of the tools has a free choice of any of the crypto libraries in C or even Java/python/etc.</div>
<div><br></div><div><br></div><div>The scheme I am working on allows people to exchange secure email using 99% of the already deployed MUAs without any updates, plug ins or patches. The basic idea is to decouple the problem of trust management from the question of message formats.</div>
<div><br></div><div>As far as message formats go, S/MIME has completely won the battle. Virtually every mail client that supports secure mail supports S/MIME and virtually everyone who uses an MUA rather than WebMail uses one that has S/MIME built in.</div>
<div><br></div><div><br></div><div>On the trust side I think that people have been thinking about the problem in a very unhelpful way. PGP's Web of trust is better for some groups of people and S/MIME's CA managed trust is better for other groups of people. </div>
<div><br></div><div>If I am sending mail on Comodo business people are going to be asking 'is this mail from Comodo' at least as often as 'is this mail from PHB'.</div><div><br></div><div>Why did we get the idea that there was no room for both approaches? Why not have a scheme that allows people to make use of any trust model they find works for them?</div>
<div><br></div><div><div><br></div><div>I see a need for at least three distinct trust exchange models:</div><div><br></div><div>1) Direct out of band trust.</div><div>2) Peer-to-Peer Endorsement</div><div>3) CA managed certificates</div>
<div><br></div><div>Plus (0) Self endorsement of short term keys from longer term keys.<br></div><div><br></div><div><br></div><div>The way I support direct out of band trust is through a 'Strong email address' which is essentially just a fingerprint prepended to a KeyIdentifier.</div>
<div><br></div><div>To enable backward compatibility with PGP there is a convention that if the KeyID has a : separator in it then it is a PGP fingerprint in hex. So people will be able to use the toolset to send mail to PGP users in PGP format.</div>
<div><br></div><div><br></div><div>The first tool is almost working now and generates a keypair for the user:</div><div><br></div><div><div>Generating Key</div><div>Writing to file Alice.keyfile</div><div>Key Identifier is ADAEXA-G4UKAN-UADASXA-JQAGBS-XAA</div>
<div>Strong email address is ADAEXA-G4UKAN-UADASXA-JQAGBS-XAA?<a href="mailto:alice@hallambaker.com">alice@hallambaker.com</a></div></div><div><br></div><div>Right now I only generate one keypair for encryption use only. But the long term plan is to generate a master keypair that has no predefined expiry time and then use that to sign temporary keys for signing and encryption.</div>
<div><br></div><div><br></div><div>The second tool is a simple mail proxy which I am working on. The idea is that you redirect your outbound mail through the proxy. The idea is that this will perform enhancement of mail as follows:</div>
<div><br></div><div>1) If the email address contains a ?, the mail will not be sent unless it can be sent under a security policy acceptable to the sender. This typically means end to end encryption using S/MIME or PGP.</div>
<div><br></div><div>2) If the email address contains a ? and has a fingerprint, the mail will only be sent if it can ALSO be encrypted under a policy that has been signed under a key that is accredited under the specified public key.</div>
<div><br></div><div>3) Otherwise the proxy will attempt to locate a sending policy for the domain from a policy service. If the receiver has specified a receiving policy with a preference for end to end encryption, the message is encrypted opportunistically.</div>
<div><br></div><div><br></div><div>Based on my calculations and simulations, I believe that the design using only direct out of band trust can scale to an arbitrary number of users but it only provides reliable trust when there is an opportunity for direct exchange. </div>
<div><br></div><div>Which is a lot better than where we are now but not where I want to stop. But that is the fun part of the project where there is room for lots of ideas and innovation. Right now we have to fix the plumbing.</div>
<div><br></div><div><br></div><div>As far as wireline formats go my approach is:</div><div><br></div><div>1) All the crypto in ASN.1 (yuk!)</div><div>2) Everything else in JSON or simple extensions thereof (e.g. JSON-ABC)</div>
<div>3) All Web services over HTTPS with client authentication at the HTTP layer.</div><div><br></div><div>A bare bones scheme does not require any web service at all. The public key and policy files can be fetched from a HTTP URL places at a .well-known location.</div>
<div><br></div><div>The next step up requires two very simple Web services to support key publication to the trust infrastructure(s) and key discovery/validation.</div><div><br></div><div>Allowing people to use multiple devices requires another two Web services, an account establishment/management service and the confirmation service I proposed earlier.</div>
<div><br></div><div>Once we get beyond that into trust infrastructures it will get a lot more complicated as what we are doing is essentially research. But I don't think we will need to be there for 18 months even by a very optimistic adoption curve.</div>
<div><br></div><div><br></div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>