On Wed, 13 Feb 2019, Micah Lee wrote:
I'm adding Miles McCain to this email, who is one of the authors you
left out.
Oops. sorry about that.
It's good to understand how RFCs are supposed to get discussed and
written. I, as well as the other two authors, are new to the IETF
process. However I don't see how the Note Well is especially relevant to
this draft RFC, as there has been no talk about patents.
Can you point to a document that describes the policy you're referencing
about where discussion of the RFC should take place, and also where
collaboration of writing the actual document should take place? We
definitely want to be transparent about the whole process.
An overview can be found at https://www6.ietf.org/tao
See also:
https://datatracker.ietf.org/meeting/103/materials/slides-103-edu-sessj-newcomers-overview-for-ietf-103-00
It's true that there's a potential privacy issue with regularly fetching
updates, but it's the same issue that all subscription systems have,
such as Atom feeds (RFC 4287). It's also the same issue if you configure
gpg to refresh your keyring on a regularly interval.
This privacy issue is more of a fundamental problem with how networking
works than with any specific standard that relies on subscribing to a
regularly-changing document, so I don't think it's in scope for this
specific RFC to tackle.
If one would implement the RFC, what advise would you have to
implementors to reduce this risk? That's the text I'm looking for.
However, GPG Sync, software that already implements the draft keylist
RFC, supports an option mitigate this issue by making it simple to fetch
updates over Tor:
So that would be good to mention in the draft!
The relevant standard you're probably thinking of is RFC 4880 which
defines the OpenPGP message format, basically the "-----BEGIN PGP PUBLIC
KEY BLOCK-----"-type blocks. But that format isn't appropriate for
keylist subscriptions.
Yeah I was thinking of that.
Keylists don't include full public keys, they only include fingerprints.
I guess that was a big point of my confusion. I was thinking of the
keylist having keys, not key pointers. So perhaps the term "key list" is
not the right term for this?
Information in public keys themselves change frequently -- the owner of
the key might add a UID, update their expiration date, or otherwise
modify their key. If keylists included actual full public keys, then the
person maintaining the keylist would have to update it not just when a
new key is added, but every single time anyone in the the organization
modifies their key.
But what scales better? An automated central way of pulling those
updates, and everyone else mirroring that, or everyone pulling all
these updates themselves? From a privacy point of view, the first would
be better. From an operational point of view I think the first would
give the best results too. But of course, there is a management issue
on how or what is responsible for this.
One of the main purposes of keylists is to reduce the amount of work
required to ensure that everyone in an organization (or anyone who
wishes to communicate with members of that organization) has the correct
public key for everyone else.
Just a note, when you say organization, I mapped that in my mind to be
within a single (DNS) domain, or at least within the same administrative
control group. After reading your email, I understand things are meant
to work a lot more informal or scattered over dozens of domains.
Including full public keys in the keylist would be counterproductive.
The keylist that my company relies on currently has 228 fingerprints on
it, and it would add a ridiculous amount of pointless work to maintain
it if we had to keep track of minor changes in each key (and get copies
of those changed public keys from their owners), when instead we can
just keep track of fingerprints.
But wouldn't it be a simple cron job to refresh those keys every day?
And for your members to pull it all from the same location daily? The
additional burden you say you want to avoid is exactly te burden you
put on everyone who wants to use the key list?
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.
Keylists are public documents, and anyone can subscribe to them even if
they're not a member of the organization.
I did not realise all keylists are public. Especially not reading the
opening sentence of the abstract:
This document specifies a system by which an OpenPGP client may
subscribe to an organization's keylist to keep its internal keystore
up-to-date.
Note it specifically says "internal keystore". It would be better to
rephrase that to be the organisations public keystore?
It might be worth considering the case where people wish to have private
keylists, but it's not something we have considered yet.
That's worth mentioning somewhere then, possibly the Security
Considerations section.
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?
We considered introducing a .well-known location, but, as described in
the draft:
To subscribe to a keylist, the client must be aware of the keylist
URI (see [RFC3986]), and the fingerprint of the authority key used to
sign the keylist.
A client must have both the keylist URI and the fingerprint of the
authority key to subscribe to it -- just the keylist URI is not enough,
which means a .well-known location would have to also include the
authority key fingerprint. Doing this would ultimately make the trust of
the entire system rely on the security of the organization's web server,
and on HTTPS, as opposed to on the authority key.
So that is an important point. It would be great if we can somehow make
it so they keylists can be trusted via some way. So that if I want to
contact a journalist at firstmedia, I don't need to first somehow
contact the owner of the key that signed the keylist to confirm this is
the real key list (especially with references on members outside of the
actual domain name used by the organization).
We recently had a very similar discussion in SAAG about security.txt,
see:
https://tools.ietf.org/html/draft-foudil-securitytxt-05
https://mailarchive.ietf.org/arch/msg/saag/WoVRqcqmWdbE4mZo42XHBCKb9vg
Note that I'm myself not in favour of the current security.txt proposal,
but it seems that it might be worthwhile to see if your key list idea
and their universal pointer to contact information could work together.
As described in the draft, only the "fingerprint" field of the key is
required, and all other fields (name, email, comments, and any other
arbitrary metadata) are optional, and only there for the sake of the
organization maintaining the keylist. Clients simply fetch the fingerprint.
Ahh fair point. I'm still a little uneasy at keys changing and getting
new IDs and implying trust, but I guess that's out of scope for this.
Could you mention that fingerprints must be only in the long form, and
not the old short form that is no longer secure enough?
Why not use https://wiki.gnupg.org/WKD ?
Why not use OPENPGPKEY DNS records?
The members of an organization frequently don't have email addresses at
the same domain name.
This is another important point that I completely missed after reading
the text. I assumed "an organisation" meant that only a very few number
of domains were involved. Perhaps clarify that in the draft?
A keylist contains a list of fingerprints for public keys everyone in
the organization should have.
To be fair here, you don't just want them to have a keylist. You want
them to have the public keys. And the keylist is a directory service to
get them. And I still think it might as well do the work and present it
all together.
It would add more pointless work to
maintain this system if we chose to arbitrarily require that they all
keys contain UIDs with email addresses for the same domain name.
I agree. As I mentioned I hadn't thought of that scenario.
While automatic sync is a nice feature, over-syncing is a privacy risk,
especially for people who are trying to remain anonymous.
This is outside the scope of this RFC. Like I described above, Atom
feeds, and existing automated use of key servers, have always had this
problem.
But the point of a Privacy Considerations section is to give important
information to implementors on issues that could pose a privacy risk,
and might be partially mitigated. So, instead of waving it out of scope,
try to give advise to implementors on how to mitigate this as much as
possible.
(Also, people trying to remain anonymous need to do quite a bit more
than just not automatically fetch PGP keys. It requires using an
operating system designed for such a use-case, like Tails, in which case
subscribing to keylists would be perfect fine, and would not compromise
anonymity.)
I don't believe it would be fine. Better sure, but there would still be
risks. A dissident could be announcing their presence as a coffee shop
if _any_ IP address queries for the updated key list. Tor does not
help that. Now I agree some of this is out of scope for your document,
but again think about what you'd want to advise implementors.
It's true that we could bootstrap a system like `gpg --refresh-keys`
combined with cron (or more realistically launchd on macOS) to keep keys
up-to-date. But 1) Not all OpenPGP users use gpg and cron, and 2) we
don't necessarily want to update all keys in every user's keychain, only
the keys on the keylists they're subscribed to.
That sounds like an argument for the key list to have the updated keys
for easy import by subscribers :)
Only refreshing keys
listed on a keylist leaks less information to key servers than
refreshing all keys -- it leaks what keylists you're subscribed to.
Sure, though let's hope that people only fetch keys over TLS so that at
least it is not known which keys are fetched?
But, most importantly, and in fact the reason we developed GPG Sync to
begin with (which ultimately lead to writing this draft RFC), what isn't
possible with existing tools is to get everyone in an organization to
automatically fetch *new* keys that they otherwise wouldn't be aware of.
Right. But wouldn't a non-gpg specific standards based keyring format
not be a better and more universal solution?
Paul
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp