UI terminology for calculated validities

MFPA 2014-667rhzu3dc-lists-groups at riseup.net
Sat Apr 26 14:20:40 CEST 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
NotDashEscaped: You need GnuPG to verify this message

Hi


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
different keys).

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
capitalisation, etc.




--
Best regards

MFPA                    mailto:2014-667rhzu3dc-lists-groups at riseup.net

Wait. You think I'm right?
-----BEGIN PGP SIGNATURE-----

iPQEAQEKAF4FAlNbpKZXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0
N0VDQTAzAAoJEKipC46tDG5poy8D/iBRy/gc7I+DMsiazPQ/504twN9MT8wO96wG
rEEV5P3r6lqT5zVfjNXSz4IuWR6xy3iflMDpTpyzZrmz067Rr8PcLZXrYt9CmuSf
Jm9wYX8Z5hCiIRBtkYh6VJ6Jeut5sPEq+mRi3RQOHDFgy8Fs2AKUAYq97DmXqT9P
vvEQ4CDo
=cgbe
-----END PGP SIGNATURE-----




More information about the Gnupg-users mailing list