UI terminology for calculated validities
2014-667rhzu3dc-lists-groups at riseup.net
Sat Apr 26 14:20:40 CEST 2014
-----BEGIN PGP SIGNED MESSAGE-----
NotDashEscaped: You need GnuPG to verify this message
On Friday 25 April 2014 at 5:47:46 PM, in
<mid:535A91B2.90602 at fifthhorseman.net>, Daniel Kahn Gillmor wrote:
> PS MFPA's original idea of using a notation to link two
> primary keys is interesting, and i see how it could be
> useful, but i don't think it belongs in the public
> keyservers either.
Interesting. Why not?
> Perhaps something like that (using
> full fingerprints, as hauke suggests) could be made by
> a non-exportable certification directly on the primary
> key itself (not over User IDs).
Why non-exportable? If I were making such a declaration about the
relationship between my multiple keys, I would want to declare it to
others. This could be useful for key transitions, but also for an
individual who chooses to use different keys with different email
addresses (so may not have a "identical-valid-user-id" across
Or do you envisage somebody else with my public keys on their keyring
would make that non-exportable certification themselves, in order to
clean up their own WoT calculations? Actually, on thinking about it,
that option also would be useful.
A certification directly on the primary key itself would make sense,
because it is a statement about the key itself, not just the key and
it's current set of UIDs. But having it over the UIDs, so
requiring a re-certification from my other key to cover any new
user-ids, maybe adds a certain amount of security. How do you make a
certification directly on the primary key itself.
> But this should only be done if there is an algorithm in
> place to make use of this information.
Isn't that kind of a "chicken and egg" statement? Would it not be an
idea to discuss a standardised notation, so that if anybody chooses to
put the information out there, it could be interpreted by an algorithm
that might get written in the future.
> Anyone implementing this kind of
> cleanup should probably start simpler and just handle
> the identical-valid-user-id case first.
Maybe "identical" should be expanded to cover such things as different
MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net
Wait. You think I'm right?
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Gnupg-users