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

[Petr Spacek <[e-mail]>]

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:
> On Sun, 8 Mar 2015, Paul Hoffman 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?
> 
> I'm okay with that. Will put into the -02 version.

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