[Cryptography] Dark Mail Alliance specs?

[Phillip Hallam-Baker]

Does anyone know what the Dark Mail Alliance specs might look like?

I have been trying to contact the principals with no success.

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.

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.

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.


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.

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.


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.

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'.

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?


I see a need for at least three distinct trust exchange models:

1) Direct out of band trust.
2) Peer-to-Peer Endorsement
3) CA managed certificates

Plus (0) Self endorsement of short term keys from longer term keys.


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.

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.


The first tool is almost working now and generates a keypair for the user:

Generating Key
Writing to file Alice.keyfile
Key Identifier is ADAEXA-G4UKAN-UADASXA-JQAGBS-XAA
Strong email address is ADAEXA-G4UKAN-UADASXA-JQAGBS-XAA?
alice at hallambaker.com

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.


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:

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.

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.

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.


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.

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.


As far as wireline formats go my approach is:

1) All the crypto in ASN.1 (yuk!)
2) Everything else in JSON or simple extensions thereof (e.g. JSON-ABC)
3) All Web services over HTTPS with client authentication at the HTTP layer.

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.

The next step up requires two very simple Web services to support key
publication to the trust infrastructure(s) and key discovery/validation.

Allowing people to use multiple devices requires another two Web services,
an account establishment/management service and the confirmation service I
proposed earlier.

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.



-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131122/ed72aecd/attachment.html>