Over in ietf-openpgp(_at_)imc(_dot_)org on 06/11/2009 11:56 PM, David Shaw
wrote:
The keyserver no-modify flag is effectively a no-op. GPG lets you set
or unset it, but since no keyserver actually looks at it, the flag isn't
all that useful.
Should we try to address this? What would it mean to make this flag
meaningful? Say a keyserver decided to try to respect it: how would it
do so?
let's assume that key server admin can directly tamper with the key
store, and not worry about that part of the RFC directly.
That leaves us with: how does the keyserver know that it was being
updated by the key holder?
One approach would be to use OpenPGP client-side certificates (with
authentication flag set?) for an RFC 5081-compliant TLS connection to
the keyserver. This seems far-fetched with the current state of tools.
It also wouldn't cleanly address keyserver propagation (only the
initial keyserver received and could verify the TLS connections).
Alternately, a keyserver could only append signatures to a key/uid
marked "no-modify" if the new signature arriving is itself wrapped in a
0x50-style "third-party confirmation" signature, where the "third-party"
is in fact the original keyholder (the "third party" == the "first
party", if you will).
Then the workflow for adding certifications to a key in the public
keyservers might look like:
* Alice publishes her key (with the keyserver-no-modify flag set) to
the public keyservers. they accept the primary key, user ID, and
self-sig because the self-sig is validated by the primary key.
* Alice shows Bob her key fingerprint and her identification.
* Bob fetches Alice's key from the keyserver, verifies the fingerprint
and user ID, and signs the UID+key, creating signature X.
* Bob tries to post X to the public keyservers, but they reject it
because the key is set no-modify. Bob's client offers to mail X
directly to Alice instead, and he lets it do so.
* Alice receives X, looks it over, verifies that it was properly made
by Bob, and decides that she wants to publish it.
* Alice creates a 0x50 "third-party" certification over X, creating Y.
* Alice feeds Y to the keyservers, who verify that her signature is
attributed to the key being signed by X, so they accept X.
* when the keyservers propagate new signatures, they propagate not only
X, but Y, allowing other keyservers to verify that X is acceptable to
the original keyholder.
It seems that an architecture like this (if it was the standard for
keyservers) could prevent a lot of bogus signatures from accumulating on
a given key, and could nicely prevent the kind of denial of service
attacks that are possible against a key by loading up millions of bgus
certifications on that key.
Are there other proposed ways one could implement a keyserver which
respects the intent of keyserver no-modify?
--dkg
signature.asc
Description: OpenPGP digital signature