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

[Petr Spacek <[e-mail]>]

On 2.3.2015 03:06, Paul Wouters wrote:
> 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.

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 <[e-mail]>"
: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.


> 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

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.

> ietf openpgp email list and see about writing a 4880bis document that
> 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.).

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

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.

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

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