Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey: objection about keyring format documentation

[Brian Dickson <[e-mail]>]

On Tue, Mar 17, 2015 at 1:11 PM, Petr Spacek <[e-mail]> wrote:

> Hello!
>
> Currently we have:
>
> > 2.2. The OPENPGPKEY RDATA wire format
> >    The RDATA Wire Format consists of a single OpenPGP public key as
> >    defined in Section 5.5.1.1 of [RFC4880].  Note that this format is
> >    without ASCII armor or base64 encoding.
>
> http://tools.ietf.org/html/rfc4880#section-5.5.1.1 says:
> > 5.5.1.1. Public-Key Packet (Tag 6)
> >    A Public-Key packet starts a series of packets that forms an OpenPGP
> >    key (sometimes called an OpenPGP certificate).
>
> Blindly using top-level key from first public key packet would violate
> crypto
> protocol enforced by PGP (and doing so could have undesired effects as you
> should never ever use one key to do encryption/decryption and signing...).
>
> I would say that for the purpose of OPENPGPKEY we do not need user IDs
> because, after all, we are going to use DNS for user id -> key mapping.


Maybe yes, maybe no.
Do "people" (a generalization for sure) use their PGP/GPG keys as a defacto
mapping of mailboxes, via their user IDs?

If so, then maybe this is at least a partial solution to the "mailbox
aliases / case-folding" problem.

Perhaps stripping out IDs which do not fall in the parent domain's
namespace, and publishing the OPENPGPKEY at all owner names corresponding
to the hash(LHS(user id)), would be a useful thing?

(This is analogous to the in-addr.arpa/ip6.arpa PTRs vs A/AAAA records, and
loose name-based validation. Except with added crypto goop.)



> The next problem is that by stripping all the 'signature' packets we would
> lose preferences like preferred hashing algorithms, key flags etc. which
> are
> stored in signature packet.
>

I think the question of what to include/exclude ties to the general PGP
usage questions:
Is the need/intent to have these PGP keys operate entirely stand-alone?
Do these DANE keys only augment, or entirely duplicate, keys published in
public key sites?
Does stripping some content out, in the DANE context, cause conflicts or
breakage, compared to other key sources (such as a local keyring with
signatures etc.)?
Would there be some "fluff" that can be stripped without breaking things?
If the same key is found in multiple DANE locations, but each partially
stripped, to what degree would simply merging the keys' "packets" result in
"correct" keys?
If the same key is found in its entirety, but maybe some components differ
(like sigs), because of different publication dates,  would a blind merge
be okay?

I think these might need to be answered to be sure the right RDATA choices
are made.

Thanks,
Brian