|
Re: Series of minor questions about OpenPGP 6
2009-02-01 22:26:07
On Feb 1, 2009, at 7:25 PM, Peter Thomas wrote:
On Sat, Jan 31, 2009 at 5:04 AM, David Shaw <dshaw(_at_)jabberwocky(_dot_)com>
wrote:
Use the shortest expiration time. If the 0x1F says you have 10
days, and
the 0x13 says you have 5 days, you have 5 days.
Ok,.. but basically this means,... it's left to the implementation by
the RFC, as Jon said, right?
Yes. A lot of the problem and confusion that seems to be coming out
of this thread is that people expect the RFC to specify everything
about OpenPGP semantics.
RFC-4880 (like 2440 before it) is really a format document. Even the
title is telling: "OpenPGP Message Format". The document contains
enough information to understand the message format, and a lot of the
semantics follows directly from that, but you won't really find a lot
of these "what happens if" sort of answers there. It's not that the
OpenPGP community doesn't have an answer for them (the existence of
multiple interoperating implementations shows that), but there is no
RFC that can be pointed to.
Many of the questions you are asking are of that sort, hence the
difficulty answering them. At one point, there was discussion about
writing a second document to cover these sorts of questions. Possibly
it is time to restart that.
Note that the answers I'm giving you are what implementations do, or
what I would advise if someone wanted to do something different. This
is always within the scope what the RFC requires/allows, but may not
be specifically mandated behavior. In other words, it's RFC-4880
compliant, but another implementation could do something else and also
be RFC-4880 compliant. The RFC also doesn't stop you from doing
foolish things (which is a feature, not a bug).
So an implementation could also use the key expiration of the 0x1F
when the key was selected via key ID for example,.. or one of my other
examples from above.
I would advise against changing the expiration time of the key
depending on how it is selected. A key should have one expiration
time, or you're in for a lot of pain when a user sending to one user
ID sees the key as expired, but a user sending to a different user ID
on the same key does not. If that is the goal, you should be expiring
the user IDs differently. Not the key.
But in any case,... if the selected expiration time is reached,.. the
WHOLE key is expired, right?
If you are expiring the whole key, then the whole key - all user IDs,
all subkeys go with it.
If you have preferred algorithms in both the 0x1F and a 0x13, then
you use
the one with the narrowest scope. So, if the key was chosen by a
particular
user ID, you use the preferred algorithms from that user ID's
selfsig. If
that selfsig does not have preferred algorithms, use the one in the
0x1F.
If the key was chosen by key ID (so there is no one particular user
ID) you
use the preferred algorithm from the primary user ID. As before,
if there
is no preferred algorithm there, use the one from the 0x1F. If
there is
preferred algorithms on a 0x18, I think I'd take the union of those
algorithms with the ones from the user ID or 0x1F.
Ok but again,.. this handling is _not_ enforced by the RFC, and an
implementation could also choose to do it by one of my examples,
right? Of course what you've explained here above is probably the most
reasonable :-)
Yes.
Does gnupg do it like that? I mean that you can set kind of a "global"
default via the 0x1F, expect you re-set it on the 0x13s?
No. GPG ignores preferences on a 0x1F. In practice, no
implementation generates 0x1F signatures for anything other than
designated revokers.
- key server preferences / preferred key server / key flags /
features
For them it's also up to the implementation right?
Where can I find how gnupg would choose if I'd have them
a) only in the 0x1F but not the 0x13s
b) in both
"Read the sources!"?! xD
Sure: you want the getkey.c file, in the merge_selfsigs_main() function.
The shorter answer is that GPG will take an expiration, a revocation
key ("designated revoker"), or key flags from an 0x1F.
II) Subpackets on any of the 0x10-0x13 certification signatures:
III) Subpackets on the 0x18 subkey binding signature:
Were my assumptions here correct?
Does it make any sense to have keyserverprefs/preferred
keyserver/features on 0x18 subkey binding signatures?
Features, maybe, but we don't currently have any flags that would be
relevant for subkeys. In any event, not all of the possible
subpackets are meaningful in all possible signature types.
Can anyone here of an example or a semantical meaning, that a
self-signature is a trust-signature?
By definition a self-signature is ultimate trust ("this is me, and I
trust myself always"). A trust signature is a way of limiting trust,
which is not appropriate for a self-signature.
David
|
|