One of the reasons that SSL works is that there is a convention that a https: url is resolved over SSL transport. I have been thinking about something similar for email.
Where I am at with the code at the moment is that I can generate keys and throw them at a gateway to some PKI which is currently TBS. This allows someone to configure their email client to accept encrypted email. The hard part is how to decide whether the email should be encrypted and if so under which key. As a pro-tem solution I plan to code up a simple SMTP/SUBMIT proxy which the user points their outbound email at (using TLS of course). This allows all the 'research stuff' to be isolated from the email client. One problem with this approach is that there is no way for the sender to force use of encryption or to force encryption to a key validated under a particular trust anchor. Which had me thinking about a convention similar to https for email. It turns out that the question mark is actually a valid RFC822 address and is actually supported by a few MUAs. It is however rejected by plenty of MTAs. Which is actually perfect for my purposes. What I propose is the following: ?<user>@<domain> : Force encryption of the email message <key-identifier>?<user>@<domain> : Force encryption of the email message under a key that is chained under the specified <key-identifier> The <key-identifier> here would be a base32 encoded one of the following: * If it is 20 bytes, a PGP v4 sha1 fingerprint * Otherwise, it a key identifier computed as a hash over the ASN.1 public key info block that uses new, stronger hashes. Note that this still requires the gateway to convert from either the email address or the key identifier to a public key for encryption. But it does place control in the hands of the user in a reasonably intelligible fashion without needing to rewrite the email client. An aware email client would of course have a handy button for this. But I rather prefer it when the handy button is connected to something I can relate to under the hood. The key-identifier might specify the encryption key itself or there might be a personal or enterprise hierarchy. Consider the case that alice works for example.com. Example Inc. has a corporate PKI and a key fingerprint X [email protected] has a personal key fingerprint Y which she has used to endorse her email encryption key issued under the example.com PKI. Depending on how well I know Alice and the nature of my message, I might want to specify X or Y. [I guess people might even want to allow for requiring the key to be endorsed under X and Y] Note that this approach still leaves open some research questions: If the Key-Identifier is specified then we have a trust path Discovery problem. If the Key-Identifier is not specified then we have a trust path discovery and validation problem. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
