[147250] in cryptography@c2.net mail archive
Re: [Cryptography] Cryptographic mailto: URI
daemon@ATHENA.MIT.EDU (Dirk-Willem van Gulik)
Sat Sep 21 18:17:09 2013
X-Original-To: cryptography@metzdowd.com
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
In-Reply-To: <CAMm+Lwj5+3-D-LjV68oH+sRF3Q5w116eVuwariwm1CPfu6NdBw@mail.gmail.com>
Date: Fri, 20 Sep 2013 10:36:19 +0200
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
Op 19 sep. 2013, om 19:15 heeft Phillip Hallam-Baker <hallam@gmail.com> het volgende geschreven:
> Let us say I want to send an email to alice@example.com securely.
...
> ppid:alice@example.com:example.net:Syd6BMXje5DLqHhYSpQswhPcvDXj+8rK9LaonAfcNWM
...
> example.net is a server which will resolve the reference by means of a simple HTTP query using the pattern http://<host>/.well-known/ppid/<hash>
> "Syd...NWM" is the Base64 hash of OID-SHA256 + SHA256(X)
..
> So to use this as a mechanism for ghetto key distribution receivers would add the URI into their account. Or let their PKI discovery agent do it for them.
We've been experimenting with much the same. With two twists. Basic principle is the same.
We use:
- <namespace>:<id>
as to keep it short. ID is currently a <sha1>; namespace is a 2-3 char identifier. We then construct with this a 'hardcoded' zone name:
<namespace>.fqdn-in-some-tld.
which is to have a (signed) entry for in DNS:
<id>.<ns>.<namespace>.fqdn-in-some-tld.
which is in fact a first-come, first-served secure dynamic dns updatable zone containing the public key.
Which once created allows only updating to those (still) having the private key of the public key that signed the initial claim of that <id>.
We assume that loss of a private key means one simply abandonds that entry in that namespace; and create anew; after which you update your handles in XMPP/messaging land (or in Phillip his example; Linked-In land). Part of the reason is that we thus allow id's which are tied to more anonymous/floating identifiers.
So the two twists we've made (which are not necessarily a good idea!) is that the <id> is really the public key its sha1 (as we're limited to RSASHA1 only throughout); and secondly we hardcode the postfixing 'fqdn-in-some-domain' you add after the <id>.<ns>.
And we're also still somewhat in look-aside validation sort of land - with respect to trust of the fqdn.tld (which is why it is currently hardcoded).
And secondly - we're clearly not protecting the the identifier we add-in without any more revealing communication. We assume a subsequent check of the public key in SIG as a followup.
Dw.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
