Via twitter I noticed this draft:
https://tools.ietf.org/html/draft-mccain-keylist-02
I have some comments on the draft. I've added the authors to the CC:
since I'm not sure if they are on this list.
First a procedural item. Section 1.3 states:
1.3. Note to Readers
RFC Editor: please remove this section prior to publication.
Development of this Internet draft takes place on GitHub at Keylist-
RFC [1].
A mailing list is available for discussion at Keylists mailing list
[2].
I just wanted to share with the authors that this is not the way one
writes RFCs. RFC's and the IETF are covered by rules, such as the Note
Well. Please see https://www.ietf.org/about/note-well/
This is important because everyone discussing this draft on this list is
expected to fall under the rules of the Note Well, meaning they cannot
go out and get a patent and not mention anything until this document is
an RFC, and then start charging money. And discussion at an external
site as the draft authors suggest, is not protected by this mechanism.
Furthermore, IETF carefully archives all mailinglist messages which can
later also be used in discovery but also for late-comers to the
discussion. If an outside website suddenly vanishes, all this
information is lost. Finally, IETF has Chairs and a Sergant-at-arms to
guide any on-list discussion. elsewhere, we fall under other possibly
arbitrary rules. I'm not saying your suggested locations are (I didn't
go there) but as a rule discussions on internet drafts happen on
internet lists. Work elsewhere is brought back to the IETF. Eg you can
make a pull request on github but you discuss this on an IETF list.
Now to the draft itself,
Section 2 talks about subscribing to "key lists", where a "key list" is
defined as an URI to something and a fingerprint of a public key that is
authorative for this list.
Section 2.2 talks about regularly updating the key list, and performing
daily checks at the URI. I think this could be a privacy issue, and one
could track a traveling journalist based on their key list sync checks.
section 3.
The key list is a JSON format that can contain a reference to an
external key server. This also sounds a bit dangerous to me. Instead of
all clients forking out to possibly many key server locations, why isn't
the "key list" simply an openpgp format public keyring, with trust
attributes set properly by the "management key" ? Clients can HEAD the
file and if there is an update, GET the file via HTTP and import the
updates. I don't understand why there is indirection allowed or required
in this idea.
Because no openpg keyring format is used, this "key list" needs to be
separately signed by the management pgp key. It adds another level of
indirection that could be avoided. If I have sufficient "trust" set
in my personal keyring to trust updates from the manager key, then
I can get the updated in openpgp format without further new protocols
already.
The "key list" contains comments such as an signature_uri that allows
the key list URI and the signature to be located on different systems?
Why would that ever be useful or more secure than doing a cleartext
signature on the file itself hosted on the same server as the key
list file itself?
A key list entry contains a fingerprint, name and email field? So in
essence, this becomes a meta key-server. Why give participants all
these indirections, instead of just providing the openpgp keyring
itself?
Why is the key list not optionally (but hopefully) encryped to the
participants to avoid a privacy leak to anyone who obtains the key list
URI ?
A key list entry has concept of a last updated time stamp. Does this
mean that every "sync" I go out to all individual key servers to get
keys from all participants just in case they might have updated their
keys on the keyserver / fileserver of their choice? It seems this
process is an ideal process for the centralized manager key to perform,
instead of all participants?
Section 4.
The "in practise" section is usually called the Impliementation Status
section. Please see https://tools.ietf.org/html/rfc7942 on how to write
these. (for example, to avoid publishing it in the final RFC)
Section 5.
The security considerations usually does not contain the benefits. Those
are the features offered and described in the document itself. This
section deals more with the concerns or practical issues or general
safe practises one has to keep in mind. Usually with a focus on
implementors more than endusers. For guidelines on how to write a
Security Consideration section, see https://tools.ietf.org/html/rfc3552
The three benefits listed do not convey to me why this solution with a
level on indirection is better suited that using a openpgp keyring
at the location.
I would rewrite 5.2 a bit. Yes the security of this system is only as
strong as the security of the manager key. But how does one convey this
management key? How is this key verified? What to do when the key IDs
are different? What to do when the key list can be obtained but not
the individual key servers listed for some participants. How often to
retry? when to warn the user? How does one recover from a management
key loss or compromise? How does the manager / key talk to its users
about anything?
The biggest problem though is that I see no attempt at providing
confidentiality for a key list. Anyone with the URI can get the list
of participants.
Why not introduce a .well-known location that any organisation can
use, so we could try and find key lists for organisations we never
talked to before. Perhaps specify a mechanism on how to verify an
organisational management key?
What to do when the email on the key list points to a key lacking that
key ID ?
Why not use https://wiki.gnupg.org/WKD ?
Why not use OPENPGPKEY DNS records?
While automatic sync is a nice feature, over-syncing is a privacy risk,
especially for people who are trying to remain anonymous.
All in all, this seems like an interesting application, and worth
further discussion (on this list). I am not yet convinced this is
an protocol issue and not an application issue.
Paul
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp