Re: [openpgp] Fwd: New Version Notification for draft-wouters-dane-openpgp-00.txt (fwd)

[Paul Wouters <[e-mail]>]

On Mon, 15 Jul 2013, Andrey Jivsov wrote:

> A few quick comments follow.

Thanks for the comments.

> This ignores prior work in this area. https://keyserver.pgp.com is known to 
> solve exactly the problems you described for many years now.

Ahh, yet another different webgui? I see the howto also states "You can
only remove your own key and the email address must match exactly". I
had one of my email addresses yanked two years ago with zero notice. I
would not have been able to remove my key. But even so, many (most?)
people still seem to use other more well known, non-commercial,
keyservers, such as pgp.mit.edu and pgp.surfnet.nl. Even if I use very
secure key servers, if people look for my key on crappy old key servers,
the risk remains.

> 2. Given that the size of the record is very important when stored in DNS 
> records, it's odd to see that ECC OpenPGP keys are not even mentioned.

I specifically did not want to limit the record to any particular type.
I just wanted it to support RFC OpenPGP compliant keys. Some people
don't want to use ECC (for legal other other reasons). Others don't
want to use ElGamal, DSA, RSA, etc. There is no reason for this draft
to distinguish and force people to pick a specific key type.

> In 
> fact, given that we are talking about a new format here, one can see many 
> benefits of standardizing *only* on ECC keys or at least 
> preferring/encouraging ECC keys.

There is no new format of public key. Only a base32 encoding for an
existing format. The base32 is there only not cause problems with DNS
(and the LHS needs to use base32, so it seemed prudent to make the RHS
also use base32)

> I think you raise a valid concern that keys placed in DNS records should be 
> "cleaned". A 4096 bit RSA key with 10 subkeys and 3d party signatures seems 
> excessive.

Though still doable. DNSSEC has forced a lot of cleanup of the port 53
TCP path. While I think it is still better to try and keep things small,
I don't think it poses a big problem anymore.

> 3. I suspect that "4.6. Subject: line encryption" is prone to bugs for 
> complex messages with multiple MIME parts. It probably needs more work to be 
> acceptable.

I do feel it is a little out of place, but it's such a simple thing to
do, I wonder why this isn't being done by existing PGP clients and
plugins already. Perhaps it can be rewritten as more of an "informative
hint".

Paul