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

From: Paul Wouters <[email-masked]>
Date: Sun, 1 Mar 2015 21:06:07 -0500 (EST)

On Thu, 26 Feb 2015, Petr Spacek wrote:

> On 20.2.2015 21:30, Warren Kumari wrote:
>> Please review this draft to see if you think it is ready for
>> publication and send comments to the list, clearly stating your view.
>
> IMHO current version *should be rejected* because further clarification to
> keyring format is needed.
>
> See previous discussion on
> http://www.ietf.org/mail-archive/web/dane/current/msg07227.html
>
> As I already said, I believe that -01 version does not define an interoperable
> standard.

It was suggested you would raise this on the openpgp email list. It
seems you have not done so.

The interoperable standard is defined in RFC 4880, the OpenPGP Message
Format. This document references that RFC for the keyring format. If you
think that reference is insufficient, I suggest you take this up on the
ietf openpgp email list and see about writing a 4880bis document that
further clarifies the keyring format.

It is not up to this document to rewrite or update RFC 4880.

> Current format of records can stay as is but it has to be clearly documented
> so we do not rely on current GPG implementation.

In my opinion, it is documented in RFC 4880. Whether or not that is
"clearly" is a subjective matter, and something that should be taken
to the OpenPGP list.

> 'It is beyond the scope of this standard to discuss the details of keyrings or
> other databases.' is simply not sufficient.

I believe it is.

Paul

---

From: Petr Spacek <[email-masked]>
Date: Mon, 02 Mar 2015 14:02:56 +0100

> seems you have not done so.

Right, I did not do so because I do not think it is the right approach.

draft-ietf-dane-openpgpkey does not require general-purpose keyring format
because it is very limited in its scope (no private keys, no secret keys etc.).

I believe that for this reason the draft should not depend on/wait for 4880bis
(which could be a huge effort). IMHO the draft should rather define
stripped-down version of keyring tailored for this particular purpose.

I was hoping that you already defined the format internally in your tool
'openpgpkey' but apparently it is not the case. Looking at the code, it does
basically this (Python pseudo-code follows):

gpgdisk = gnupg.GPG()
disk_keys = gpgdisk.list_keys()
for pgpkey in disk_keys:
    # pick the right key here
ekey = gpgdisk.export_keys(pgpkey["keyid"], ...)

It effectively means that you are going to output anything which was returned
by current version of GnuPG Python bindings.

- Looking at documentation for Python bindings, it does not say any word about
output format.
- Looking into the binding, it basically calls 'gpg --export' and returns what
was returned by gpg binary.
- Looking at 'man gpg', it does not define output format for --export.

Please note that at this point already jumped though 4 hoops to find out the
format of the data and found nothing. That is not what I call interoperable
standard, sorry!

To be constructive, it is possible to examine what GnuPG spitted out using:

$ gpg --list-packets /tmp/what_you_exported_before
:public key packet:
	version 4, algo 1, created 1412325631, expires 0
	pkey[0]: [4096 bits]
	pkey[1]: [17 bits]
	keyid: 10587E881CB2BB71
:user ID packet: "Petr \xc5\xa0pa\xc4\x8dek <[email-masked]>"
:signature packet: algo 1, keyid 10587E881CB2BB71
	version 4, created 1412325631, md5len 0, sigclass 0x13
	digest algo 2, begin of digest d2 11
	hashed subpkt 2 len 4 (sig created 2014-10-03)
	hashed subpkt 27 len 1 (key flags: 03)
	hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
	hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
	hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
	hashed subpkt 30 len 1 (features: 01)
	hashed subpkt 23 len 1 (key server preferences: 80)
	subpkt 16 len 8 (issuer key ID 10587E881CB2BB71)
	data: [4096 bits]
:public sub key packet:
	version 4, algo 1, created 1412325631, expires 0
	pkey[0]: [4096 bits]
	pkey[1]: [17 bits]
	keyid: E52EB436C0C402E3
:signature packet: algo 1, keyid 10587E881CB2BB71
	version 4, created 1412325631, md5len 0, sigclass 0x18
	digest algo 2, begin of digest 22 98
	hashed subpkt 2 len 4 (sig created 2014-10-03)
	hashed subpkt 27 len 1 (key flags: 0C)
	subpkt 16 len 8 (issuer key ID 10587E881CB2BB71)
	data: [4096 bits]

*This* can be standardized with small effort (in comparison with 4880bis) by
listing expected packet types and by referencing RFC4880: The rough idea is to
say something like this:

The blob contains sequence consisting of
1) Public-Key Packet (Tag 6, section 5.5.1.1)

2) (non-empty?) sequence consisting of
-- User ID Packet (Tag 13, section 5.11) which identifies the previous key
-- Signature Packet (Tag 2, section 5.2)
(+ signature over what with what key - maybe over preceding User ID?)

3) Signature Packet (Tag 2, section 5.2)
(+ signature over what with what key - maybe over whole previous sequence? see
sigclass 0x13)

4) (non-empty?) sequence consisting of
- Public-Subkey Packet (Tag 14, section 5.5.1.2)
-- Signature Packet (Tag 2, section 5.2)
(+ signature over what with what key - maybe sign previous block with master
key? see sigclass 0x18)

You can see that even with current version of GnuPG at hand it is not 100%
obvious what the data actually contain and how it should be interpreted.

Also, please note that I did not try to export a public key with multiple
user-IDs or subkeys but it would certainly be more messy.

> think that reference is insufficient, I suggest you take this up on the

I believe that the example above sufficiently demonstrates that it is hard to
write a client which would interpret content of OPENGPGKEY records without
actually using GnuPG's code.

> further clarifies the keyring format.

As I said above, I do not think we need 4880bis because generic keyring format
is overkill for simple application as OPENPGPKEY.

> It is not up to this document to rewrite or update RFC 4880.

Sure, but I'm not proposing that :-) I'm saying that this draft should clearly
state what RFC 4880 packets are expected in OPENPGPKEY blob, in what order,
and what has to be signed by which key (define expected sigclasses etc.).

> "clearly" is a subjective matter, and something that should be taken

There is no room for subjectivity. Please imagine that you are going to write
a new version of opengpgkey utility - without looking at GnuPG code and in a
way which has to be interoperable with current version of the utility.

You will see if RFC 4880 is sufficient or not.

>> other databases.' is simply not sufficient.

Hmm ... Are you saying that you and others are able to implement equivalent of
'opengpgkey' utility without using existing GnuPG bindings/code? Or a
Thunderbird extension which would import keys and sign emails?

-- 
Petr Spacek  @  Red Hat

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 8 Mar 2015 18:04:25 -0700

On Feb 26, 2015, at 7:23 AM, Petr Spacek <[email-masked]> wrote:
> The main problem is that
> http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-01#section-2.1
> 2.1. The OPENPGPKEY RDATA component
>  The RDATA (or RHS) of an OPENPGPKEY Resource Record contains a single
>  value consisting of a [RFC4880] formatted OpenPGP public keyring.
> 
> references
> 
> http://tools.ietf.org/html/rfc4880#section-3.6
> 3.6. Keyrings
>  A keyring is a collection of one or more keys in a file or database.
>  Traditionally, a keyring is simply a sequential list of keys, but may
>  be any suitable database.  It is beyond the scope of this standard to
>  discuss the details of keyrings or other databases.
> 
> and this definitely is not a definition you could use for implementation.

I fully agree on this. In fact, I think I brought the lack of interop up during the discussion leading up to RFC 2440, and was told that it was too late to change. (To be fair, we used the "too late to change" phrase a lot leading up to the spec for S/MIME v2. Ah, those carefree '90s.)

Proposal: this draft should specify that the contents of the RDATA is a single public key, defined in Section 5.5.1.1 of RFC 4880. Are there common cases where this is not sufficient?

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 8 Mar 2015 18:12:10 -0700

Here are some (admittedly late) comments that have not been brought up on earlier threads on this document.

Introduction:
   To
   obtain that public key, two problems need to be solved by the
   sender's email client, MUA or MTA.
An Oxford comma is very much needed in that sentence.

The following will cause problems:
   This trust model is not meant to replace the "web of trust" model.
You either need to define that model (since it is not defined in any other RFC), or delete the sentence. I strongly support the latter action.

In Section 3, item #2 is not really an item, it is a continuation of the preceding item. There are only three steps here, not 4.

--Paul Hoffman

---

From: Lyndon Nerenberg <[email-masked]>
Date: Sun, 8 Mar 2015 18:27:30 -0700

> An Oxford comma is very much needed in that sentence.

If we're copy editing, "email client" and "MUA" are redundant.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 8 Mar 2015 23:10:10 -0400 (EDT)

> Proposal: this draft should specify that the contents of the RDATA is a single public key, defined in Section 5.5.1.1 of RFC 4880. Are there common cases where this is not sufficient?

I'm okay with that. Will put into the -02 version.

Paul

---

From: Jon Callas <[email-masked]>
Date: Sun, 08 Mar 2015 19:58:55 -0700

> On Mar 8, 2015, at 6:04 PM, Paul Hoffman <[email-masked]> wrote:
> 

To be fair here — back in the carefree '90s, we were *forbidden* from being a "PKI" because there already was one, and it was PKIX.

Despite that, if you look at section 3.6 of RFC 4880, you will see in its entirety:

3.6.  Keyrings

The second sentence of that, "...a keyring is simply a sequential list of keys..." is in fact the *exact* definition of a keyring. The sentence adverb in that sentence, "Traditionally," is the weasel word that satisfies the requirement not to be a PKI. If you add in the last sentence of the paragraph, it seals the deal.

All you need else to do is to follow the SHOULD in the Trust Packet section (5.10) and of course interpret a "local" signature as well, local.

Poof, you’re done.

	Jon

---

From: Warren Kumari <[email-masked]>
Date: Mon, 9 Mar 2015 11:43:08 -0400

[ Top post ]

So, we have had a reasonable amount of discussion here, but only from
a limited number of participants. In many cases it is unclear to me if
people are OK with progressing hte document (once their comments are
addressed), or if they dislike the document...

So, I'm extending this till this Friday (Friday the 13th!). Paul W
will also be releasing a new version of this document with many of the
comments integrated. Can people please have a look at the new version
(I think it will be out in a few hours), and let me know if:
A: their comments / issues have been addressed, and
B: are you OK with the general document? A clear "Yes, this is good"
or "No, worst idea ever" would be useful.

I'd really like more then 3 or 4 people commenting.
W

On Fri, Feb 20, 2015 at 3:30 PM, Warren Kumari <[email-masked]> wrote:
> Dear DANE WG,
>
> The author of draft-ietf-dane-openpgpkey has indicated that he
> believes that the document is ready for Working Group Last Call.
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/
>
> This document has been discussed a number of times, to jog your
> memory, here is one slidedeck:
> http://www.ietf.org/proceedings/89/slides/slides-89-dane-2.pdf
> Also, a cute trick: dig type61 $(echo -n pwouters| sha224sum | sed "s/
> .*$//")._openpgpkey.fedoraproject.org |grep TYPE61 | sed
> "s/^.*TYPE61.*\\\#[0-9]* //" | grep -v ";" | sed "s/ //g" | xxd -r -p
> | gpg --import --dry-run
>
>
> This WGLC ends Fri 06-Mar-2015.
>
>
>
> In addition, to satisfy RFC 6702 ("Promoting Compliance with
> Intellectual Property Rights (IPR)"):
> Are you personally aware of any IPR that applies to
> draft-ietf-dane-openpgpkey?  If so, has this IPR been disclosed in
> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378
> for more details.)
>
> Thanks,
> Warren Kumari
> (as DANE WG co-chair)
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Mar 2015 11:59:01 -0400 (EDT)

On Mon, 9 Mar 2015, Warren Kumari wrote:

> comments integrated.

Done, see: http://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/
The changes are roughly:
- Using PaulH's suggested text to address Petr's comment regarding
   OpenPGP public key format.
- Added section about email address variants
- Rewrote 4 item list into 3 item list as per PaulH's suggestion
- Added a security section talking about amplification and what
   servers MAY do to avoid problems (probable controversial, please read!)
- Language fixes, example RRTYPE fixes.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 Mar 2015 09:10:12 -0700

With PaulW's changes in -03, I very much like this document and believe it should be moved to IETF Last Call.

--Paul Hoffman

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Mar 2015 19:13:15 +0000

> I'd really like more then 3 or 4 people commenting.
Late review of the document:

The document looks good to me and I support its publication. Some 
nits/minor things:

2.3.  The OPENPGPKEY RDATA presentation format

    The RDATA Presentation Format, as visible in textual zone files,
    consists of a single OpenPGP public key as defined in
    Section 5.5.1.1. of [RFC4880] encoded in Base64 [RFC4648]

  The base64 section should say "Section 4 of [RFC4648]". Because there 
is also section 5, which uses a diffent alphabet.

In 3.1:

o  Everything after a "+" symbol is dynamc.

Typo: dynamic.

If you want an informative reference here, you can reference RFC 5233.

      [email-masked]
       maps to [email-masked].

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Mar 2015 16:01:11 -0400 (EDT)

On Mon, 9 Mar 2015, Alexey Melnikov wrote:

> The document looks good to me and I support its publication.

Great :)

> Some nits/minor things:
> The base64 section should say "Section 4 of [RFC4648]". Because there is 
> also section 5, which uses a diffent alphabet.

Fixed for -03.

> o  Everything after a "+" symbol is dynamc.

Fixed for -03

> If you want an informative reference here, you can reference RFC 5233.

Added for -03.

Thanks!

Paul

---

From: James Cloos <[email-masked]>
Date: Tue, 10 Mar 2015 11:26:43 -0400

>>>>> "PH" == Paul Hoffman <[email-masked]> writes:

PH> With PaulW's changes in -03, I very much like this document and
PH> believe it should be moved to IETF Last Call.

+1.  It looks ready for Last Call.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: "Rose, Scott W." <[email-masked]>
Date: Tue, 10 Mar 2015 12:20:18 -0400

>> The document looks good to me and I support its publication.

With those edits fixed, I think it is ready for WGLC.  

Scott

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
https://www.had-pilot.com/
===================================

---

From: Pieter Lexis <[email-masked]>
Date: Fri, 13 Mar 2015 14:09:40 +0100

Hi all,

Late to the party, but here are some nits/things on
draft-ietf-dane-openpgpkey-02. I have not read my huge backlog of the
DANE mailinglist, so please correct me if I'm beating a dead horse.

Nearly all issues I have are mentioned in
draft-ietf-dane-openpgpkey-usage-01.

> or "No, worst idea ever" would be useful.

I'm very much on the "Yes, this is good"-side of things.

3.1:
The MAY in the last sentence is much too weak. We can’t have
interoperability without some stronger rules. Suggest moving this whole
section into -usage or mentioning that these will be specified in a
later document (-usage in this case).

5.1:
Singling out one RRTYPE to push DNS-COOKIES feels weird. I'm just
mentioning it, but as this section is merely a suggestion, it is fine.

Appendix A:
Two things: I suggest moving this to -usage and adding pseudocode
examples. The latter mostly to encourage more implementations.

-- 
Pieter Lexis

---

From: Paul Wouters <[email-masked]>
Date: Fri, 13 Mar 2015 14:10:09 -0400 (EDT)

On Fri, 13 Mar 2015, Pieter Lexis wrote:

Thanks for the review Pieter,

> later document (-usage in this case).

I'm happy to add a much larger recommendation advise in the -usage
document, but I did want to mention it in the record format document
because it _does_ affect the lookup mechanism that implementors might
need or want to support.

> mentioning it, but as this section is merely a suggestion, it is fine.

I would gladly generalise it, but this document is not allowed to update
the core DNS protocol. But I would like implementors to look at this
and possibly put that restriction in. I'm actually worried about this,
especially since using old software with the generic record syntax would
actually not have any such limitation implemented.

> examples. The latter mostly to encourage more implementations.

I thought about keeping it software agnostic, but in the end figured
since gnupg has been around for over a decade, it is kind of similar
to using openssl commands as example. But I have no problems making
this software agnostic if the WG thinks that is more appropriate.

Paul

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 14 Mar 2015 10:38:40 +0000

Hi,

On 13 Mar 2015, at 18:10, Paul Wouters <[email-masked]> wrote:

> to using openssl commands as example.

I agree. Some real world usage is good.

> But I have no problems making

More examples are always better :-). (I am not suggesting you change anything, if you can't think of any).

---

From: Warren Kumari <[email-masked]>
Date: Sat, 14 Mar 2015 11:37:22 +0100

Thanks everyone for your feedback and comments, the WGLC is now closed.

I think that it looks like there is strong consensus for publishing,
but I'm hoping to re-read all the comments on my flight home
(currently sitting in TXL) to see if I've missed anything obvious...

W

On Sat, Mar 14, 2015 at 11:38 AM, Alexey Melnikov
<[email-masked]> wrote:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: "John Levine" <[email-masked]>
Date: 14 Mar 2015 16:36:35 -0000

>(currently sitting in TXL) to see if I've missed anything obvious...

I am fairly sure that the current text in section 3.1 will never get
through the IESG.  Telling people to guess e-mail addresses is, well,
just wrong.

The draft is fixable, but it's a fairly significant change.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Sat, 14 Mar 2015 14:40:20 -0400 (EDT)

> The draft is fixable, but it's a fairly significant change.

Section 3.1 was never meant to dictate processing. It was only meant to
warn about email address mapping services out in the wild that we know
about. I can try and come up with better text if that solved this issue
for you.

Paul

---

From: Warren Kumari <[email-masked]>
Date: Sat, 14 Mar 2015 20:27:51 +0100

Oh yeah. I sent this all in a bit of a rush (while waiting for a cab).
I'm also writing this in a bit of a rush, but I'm still going to have
to chat with Olafur to try and figure out what we do with the whole
"many trees" / DNAME issues.
W

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 14 Mar 2015 19:48:25 +0000

> "many trees" / DNAME issues.

I hope this is a reference to the _prefix issue.  That is, whether
SMIMEA and OPENPGPKEY, ... should share the same _prefix:

    <hash>._<shared-prefix>.example.com. <SMIMEA|OPENPGPKEY|...> ...

so that all DANE records related to a given mailbox are collocated
in DNS.

Perhaps this discussion should continue...  Having one such prefix
is sufficient for separating such data from other data for the
domain.

Having many such prefixes, (at least one each for SMIMEA and
OPENPGPKEY) seems to me to be unnecessary and inelegant.  That is
I think one such prefix is enough for both, and for any other
closely related DANE records.

-- 
	Viktor.

---

From: Petr Spacek <[email-masked]>
Date: Tue, 17 Mar 2015 21:11:37 +0100

Hello!

I'm sorry for being very late, I had to do some $DAILYJOB.

First of all, thank you for incorporating the feedback!

On 9.3.2015 04:10, Paul Wouters wrote:
>> Proposal: this draft should specify that the contents of the RDATA is a
>> single public key, defined in Section 5.5.1.1 of RFC 4880. Are there common
>> cases where this is not sufficient?
> 

Finally I had some time to review -02 version of the text and I think that it
would deserve some more attention:

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).

Well, formulation 'starts a series of packets that forms an OpenPGP key' is
not very informative and contradicts Paul's assumption about 'single public
key' mentioned above. Series of what?

Let's see what OpenPGP 1.4.19 exports. It is sequence of:
:public key packet:
:user ID packet:
:signature packet:
:public sub key packet:
:signature packet:

which is pretty convoluted sequence of packets.

Also, http://tools.ietf.org/html/rfc4880#section-5.5.1.2 says this:
> ... By convention, the top-level key
>    provides signature services, and the subkeys provide encryption
>    services.

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.

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.

Also, I would like to see clarification to the actual rdata encoding.

Having said all that, I would like to discuss this variant of section 2.2:

2.2. The OPENPGPKEY RDATA wire format

The RDATA Wire Format consists of a single OpenPGP public-subkey packet as
defined in Section 5.5.1.2 of [RFC4880]. The rdata MUST NOT contain any other
packets. Tools generating rdata must respect Key Flags as specified in section
5.2.3.21 of [RFC4880] and export only keys with flags appropriate for e-mail
encryption communication.

Rdata MUST be encoded according to Section 4 of [RFC4880], including the full
packet header. Note that this format is without ASCII armor or base64 encoding.

The open question is if really should strip all the signature packets as it
discards all the keyflags, algorithm preferences etc.

I'm attaching output from pgpdump below so you can see what information is in
which packets of typical public key export. For pure encryption we need only
Public Subkey Packet (tag 14) and nothing else.

Old: Public Key Packet(tag 6)(269 bytes)
	Ver 4 - new
	Public key creation time - Fri Feb 15 09:25:33 CET 2013
	Pub alg - RSA Encrypt or Sign(pub 1)
	RSA n(2048 bits) - ...
	RSA e(17 bits) - ...
Old: User ID Packet(tag 13)(32 bytes)
	User ID - Petr Spacek <[email-masked]>
Old: Signature Packet(tag 2)(318 bytes)
	Ver 4 - new
	Sig type - Positive certification of a User ID and Public Key packet(0x13).
	Pub alg - RSA Encrypt or Sign(pub 1)
	Hash alg - SHA1(hash 2)
	Hashed Sub: signature creation time(sub 2)(4 bytes)
		Time - Fri Feb 15 09:25:33 CET 2013
	Hashed Sub: key flags(sub 27)(1 bytes)
		Flag - This key may be used to certify other keys
		Flag - This key may be used to sign data
	Hashed Sub: key expiration time(sub 9)(4 bytes)
		Time - Sun Mar 17 09:25:33 CET 2013
	Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes)
		Sym alg - AES with 256-bit key(sym 9)
		Sym alg - AES with 192-bit key(sym 8)
		Sym alg - AES with 128-bit key(sym 7)
		Sym alg - CAST5(sym 3)
		Sym alg - Triple-DES(sym 2)
	Hashed Sub: preferred hash algorithms(sub 21)(5 bytes)
		Hash alg - SHA256(hash 8)
		Hash alg - SHA1(hash 2)
		Hash alg - SHA384(hash 9)
		Hash alg - SHA512(hash 10)
		Hash alg - SHA224(hash 11)
	Hashed Sub: preferred compression algorithms(sub 22)(3 bytes)
		Comp alg - ZLIB <RFC1950>(comp 2)
		Comp alg - BZip2(comp 3)
		Comp alg - ZIP <RFC1951>(comp 1)
	Hashed Sub: features(sub 30)(1 bytes)
		Flag - Modification detection (packets 18 and 19)
	Hashed Sub: key server preferences(sub 23)(1 bytes)
		Flag - No-modify
	Sub: issuer key ID(sub 16)(8 bytes)
		Key ID - 0x3F8A1B3A9A7C8D08
	Hash left 2 bytes - 27 b1
	RSA m^d mod n(2048 bits) - ...
		-> PKCS-1
Old: Public Subkey Packet(tag 14)(269 bytes)
	Ver 4 - new
	Public key creation time - Fri Feb 15 09:25:33 CET 2013
	Pub alg - RSA Encrypt or Sign(pub 1)
	RSA n(2048 bits) - ...
	RSA e(17 bits) - ...
Old: Signature Packet(tag 2)(293 bytes)
	Ver 4 - new
	Sig type - Subkey Binding Signature(0x18).
	Pub alg - RSA Encrypt or Sign(pub 1)
	Hash alg - SHA1(hash 2)
	Hashed Sub: signature creation time(sub 2)(4 bytes)
		Time - Fri Feb 15 09:25:33 CET 2013
	Hashed Sub: key flags(sub 27)(1 bytes)
		Flag - This key may be used to encrypt communications
		Flag - This key may be used to encrypt storage
	Hashed Sub: key expiration time(sub 9)(4 bytes)
		Time - Sun Mar 17 09:25:33 CET 2013
	Sub: issuer key ID(sub 16)(8 bytes)
		Key ID - 0x3F8A1B3A9A7C8D08
	Hash left 2 bytes - 0f f1
	RSA m^d mod n(2047 bits) - ...
		-> PKCS-1

-- 
Petr Spacek  @  Red Hat

---

From: Brian Dickson <[email-masked]>
Date: Tue, 17 Mar 2015 14:03:26 -0700

> 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.)

> 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