On 16 Apr 2015, Werner Koch wrote:
Assume you use the same key for home and work. You have two user
ids but at home you use an implementation and preferences you like
while at work you have to comply with company policies and thus
different preferences.
The solution to this problem should be two keyrings. Different
encryption settings per user id like this are completely out of scope
for everyone who isn't familiar with the inner workings of RFC4880.
Even assuming this was a useful feature, it is underspecified to a point
where trying to figure out what an other implementation meant by some
constellation of preferences in user ids or direct key signatures is
little more than guesswork.
Remember that you anyway need to implement a policy on how to work
with multipe self-signatures on the same user id, or with multiple
direct key signatures.
Just like gpg, we use the latest signature. Is there a reason this
isn't specified? While I agree that the trust model should not be
specified, leaving this kind of thing open just leads to confusion,
unintended behavior which isn't even really a bug but just different
interpretations by different developers, and complexity in an attempt to
be compatible with de facto standards.
I remember several discussions about this kind of thing between me and
Dominik which went like "how's it specified?" - "it isn't." - "well,
just look at gpg's source and do what they do".
A dedicated revoker certificate also allows to create a revocation
certificate with a valid reason code and not just a catch-all reason
code.
That's a valid reason. It still means my import routine can't decide by
the data of a keyring whether it's revoked or not, but may need another
key lookup (and verification, ...) for it, reducing reliability of this
kind of recovation.
- V
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp