PKA

[Jeroen Massar]

Werner Koch wrote:
> On Tue, 27 Dec 2005 03:44:29 +0300, Pawel Shajdo said:
> 
>> What is PKA? Just have found in manual unknown words...
> 
> Public Key Association
> 
> Yeah, I know that I should write a paper on this.  There is only a
> simplepresentation on what PKA tries to solve
> (ftp://ftp.g10code.com/people/werner/talks/pka-intro.ps.gz)

I just have to mention that I like this idea a *LOT*.
It also aligns quite well with what I had in mind for it.
Of course repudiation folks will not like PGP signed messages at all as
they can't say anymore that they didn't write it ;)

I thought a bit about the deployment, fingerprints fortunately don't
change (much), (DNS) caching is thus not a problem either. The uri=
field is only used to get the key when one doesn't have it yet. Thus a
single TXT lookup per the single source address is efficient and gets
cached. Thus this should work pretty well. DNS folks will not like it
though as DNS will be used as a generic directory and they claim it to
not be one, though there are numerous examples that it is.

One concern though is for folks who can't configure their dns and having
providers of this system not wanting to do it, for various reasons.
Would it be a good thing to have, say ._pka.verified.gnupg.org where
these folks can register eg user.example.org._pka.verified.gnupg.org ?
gpg could then check first if the domain itself has records, if it
doesn't have _pka.<domain> at all it can be configured to fall back to
the verified domain. The latter can be automated quite well with a
webinterface that mails folks with a unique code to verify them, similar
to biglumber. DNS + Web resource is the only issue here though, but I
guess there will be enough offers to host such a dns server to overcome
this. This service can then also be a public code which allows folks to
have a reference to how they can set it up for their own domain. Using
PowerDNS to interface directly with SQL comes to my mind.

What values can be stuck in the uri field? hkp and http seem to map both
to hkp. Both don't support HTTP/1.1's Host: header, which would limit
running a HKP/HTTP keyserver for only one virtual host, thus excluding
most simple hosts. Another idea here would be to support https, then one
also knows that the server one fetches the key from is really
authoritative, DNS, with DNSSEC, points to the server and the server has
a valid certificate, thus the key must be valid (unless the box is
compromised).

Having a non-TXT record for this would also be very useful, though the
difference with a TXT record won't be too much I guess. I would suggest
changing the format of the TXT record though for this purpose into:
"1;A4D94E92B0986AB5EE9DCD755DE249965B0358A2;finger:wk at example.com"
(64 bytes)
Skipping the 'tags', if there are new tags to be added, upgrade the
version number or make the fourth field contain a tag to do so. The
difference then with a special DNS RR is almost gone:
[version] [fingerprint-length] [fingerprint] [uri-length] [uri]
01 28 A4 D9 4E 92 B0 98 6A B5 EE 9D CD 75 5D E2 49 96 5B 03 58 A2 15
finger:wk at example.com
which is a total of 63 bytes (did I count correctly?) he length fields,
making parsing easier, where formerly the separator tags. The version
number can also be skipped entirely if there is a decision that this is
all we need. Which most likely is the case for the purpose of this
record. Any additional data can be fetched from the URI.

BTW is there a more "static" version of PKA documentation available than
the http://lists.gnupg.org/pipermail/gnupg-devel/2005-August/022254.html
 message? A "How to set it up and use it" document would be nice, I
think I get & understand most of the concept thus if you want me to
submit something just yell.

BTW2, someone should update
http://www.gnupg.org/(en)/download/cvs_access.html to not point to CVS
but the subversion repos...

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 238 bytes
Desc: OpenPGP digital signature
Url : /pipermail/attachments/20060102/9e1d7147/signature-0001.pgp