On 12.1.2015 16:06, Paul Wouters wrote: > On Mon, 12 Jan 2015, Petr Spacek wrote: > >> I would like to see a clarification for section: >> >> 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. >> >> >> I'm struggling with definition of "formatted OpenPGP public keyring". After a >> quick glance I have found only this: >> >> 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. >> >> I did not read whole RFC 4880 so it is possible that I have missed some >> related definitions but IMHO this reference deserves clarification. >> >> Where is the actual keyring format defined? > > That's it. You're looking at it. There is not a better reference that > I'm aware of. I have been looking for it myself as well.
Ooooh, that is bad. I would say too bad for any implementation which wants to be interoperable. So, what do we do next? I can see three ways: 1) Write a new RFC to standardize keyring format. Is it worth the effort? I'm not sure. 2) We could move forward with some simplified single-purpose definition of keyring based on - Key Material Packet http://tools.ietf.org/html/rfc4880#section-5.5 - User ID Packet http://tools.ietf.org/html/rfc4880#section-5.11 3) Do something in between first two approaches: It seems that it should be relatively simple to define totally simple universal keyring simply as sequence of OpenPGP packets defined on: http://tools.ietf.org/html/rfc4880#section-5.5 That definition would allow us to add revocation data in future or possibly add other extensions. I assume that RFC written today would say: A application MUST ignore all packet types except A,B,C,D. Later, when a new packet format is standardized and new tag assigned to it, we can add this new tag to list of non-ignored tags (and define meaning of it) in separate RFC. -- Petr^2 Spacek _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
