On 20.3.2015 22:49, Paul Wouters wrote: > On Fri, 20 Mar 2015, Viktor Dukhovni wrote: > >>> seems like a major problem to me: Please see >>> http://www.ietf.org/mail-archive/web/dane/current/msg07390.html >> >> Thanks for the reminder. I think we should at least explore the >> question of what exactly does go into the RRDATA. > > IMHO, we already state that clearly in the latest text proposed to > this list, referencing the exact section of the openpgp RFC. The > latest proposed text was: > > 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] > >> What parts of >> a PGP public key should publishers include or exclude? Will stating >> a more precise definition improve interoperability? > > Why should we decide any of this? As long as it is a valid openpgp > Public-Key Packet (Tag 6)
I'm not convinced that RFC4880 section 5.5.1.1. clearly defines what clients should expect. The RFC 4880 section 5.5.1.1. in its entirety follows: """ 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). """ >> Should the interchange form for such "out of band" PGP public keys >> be defined in some other document. > > gpg and other tools have managed to do fine with openpgp public key > rings all over the place. In files, on key servers, via hpk or http. > The interchange format is called RFC 4880. That is an important but kind of invalid point: Of course you can implement an interoperable OpenPGP implementation if you can read what GnuPG does. Still, I'm not convinced that RDATA format specification should be 'do what GnuPG did back in 2015'. Maybe I'm wrong and RFC 4880 defines exactly what packets client should expect - in that case it would be nice to add a reference to particular section in RFC 4880 so implementors have clear entry point and are not confused as I am. >> I've seen messages to the >> effect that there's some interest in re-chartering the PGP working >> group... > > All the more reason for us not to cherry-pick items of the public > key ring packet and leave it up to a new RFC updating 4880 to > reflect updates for modern openpgp use. By referencing RFC 4880, > we will get those updates by the new RFC that updates 4880. That is certainly an option if WG is okay with issuing RDATA format definition which will be unclear at the time of issue. -- Petr Spacek @ Red Hat _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
