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 <[email protected]> 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 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
