Hi Hal.
On Wed, Jan 28, 2009 at 7:48 PM, "Hal Finney" <hal(_at_)finney(_dot_)org> wrote:
I will answer your questions on the assumption that you are writing
OpenPGP compliant software. You are therefore asking about how you should
implement your software.
Yes and no.
I'm actually thinking about writing an OpenPGP key editor (perhaps
using parts of gnupg as backend) which can do nearly everything that
the RFC allows to give geeks and freaks the opportunity to try out
everything which shouldn't be possible for the average user (that said
I fully like the way gnupg - and probably other implementations -
"guide" the user).
But my discussion here is more about how could the RFC be improved.
Please don't get me wrong, I don't wanna say the RFC is crap or anyone
here did make wrong things or so and I'm fully aware that I'm really a
newbie here.
But what I see is that X.509 based PKIs which are based on a strict
hierarchical trust model are spread more and more. And personally I
dislike it and consider hierarchical trust models inferior to what
OpenPGP allows.
Most governments fully set on X.509 based PKIs and don't consider or
even support OpenPGP and even most technical standards or applications
are only X.509 aware (see SSL/TLS, although we have RFC 5081).
What it all comes down to is: I think there are places where the RFC
and thus OpenPGP could be improved maybe I'm wrong but nevertheless
I'll tell this list my ideas.
Of course some of them would be difficult to implement or even break
compatibility. I'm aware of the time that was needed for this RFC and
fully respect the effort the WG put in it and I'm also aware that a
new RFC won't come up tomorrow, but anyway I'd like to tell you what I
think.
You still can say shut up and go away ;-)
I would certainly encourage you to set the critical bit on these and
other signature subpackets that you view as critical to the security.
Unfortunately I have no idea how to do this with gnupg (my used
implementation)... perhaps David can comment on this. But even if
would do modifications to set the critical bit on them I fear
compatibility issues with other implementations.
You
might also want to require the critical bit to be set on those packets,
although that will impair interoperability.
What do you mean with this? Require it by the RFC?
c) It's nowhere clearly specified if and what meaning these supackets
have on the subkey binding self-signature (0x18)
You should probably not put subpackets into such signatures which do
not have clearly defined meanings.
But this is the point. Which have clearly defined meanings? Hast the
policy URI a meaning on 0x18s (e.g. as the policy for signatures made
by that subkey)?
3) This is probably clear for everybody, but the part on revocation
signatures should perhaps highlight, that all subpackets in revoked
signatures MUST NOT be used, e.g. imagine the key expiration time is
only stored in an 0x1F and not in any 0x10-0x13. If that 0x1F gets
revoked, the key has no longer an expiration time.
I would recommend that your software follow this principle.
Oh my mistake,... an absent key expiration time means unlimited ;-)
Anyway I think the original problem remains,.. what is the semantical
meaning e.g. when there are different key expiration time values on
(perhaps even multiple) 0x13s and a 0x1F?
4) In chapter 5.2.3.3 it is explicitly allowed that the key expiration
time is reset by a user (of course this cannot be prevented as the key
expiration time is no longer part of the key itself). Isn't this
possibility comparable to revoke a revocation?
I mean the creators states: "This key SHOULD NOT be used after <key
expiration>." for example because he thinks an RSA786 key SHOULD no
longer be used in 10 years. An attacker might simply revoke this
(implicit) revocation by issuing a new self-signature with an updated
date.
If the attacker got the private key.
What was the reason that the key expiration time was taken out of the
key itself (I think it was there before?)?
Again, there will be no new RFC, not for many years at least. You must
solve them in your software using the current RFC. If you want to ask
more specific and practically oriented questions, like, what should I
do when I see this kind of key, we can try to give you more specific
advice.
Thanks again for your advices. But if you're interested in and find
the time I'd like to see your comments and ideas about the "issues"
themselves.
Of course it's possible to find and implement a reasonable solution,
which is what you suggested me in most of your comments :-)
At some point the RFC says that it's a little bit "vague". In my
opinion (and I really don't want to offend anybody) this is bad for a
cryptologic. Everything should be exactly defined.
For example I'd like to see those possible (at leas in my opinion)
security critical subpackets to be REQUIRED by an future RFC. Of
course no one can force an implementation to really adhere to the
standard, but that's always the case.
Would be nice if you and perhaps even the other authors of the RFC
(David for example has give me already some very deep insight) could
comment on the "issues" themselves. I promise that I don't request you
to write a new RFC immediately ;-)
Maybe you can persuade David or someone else to change
his software to be more to your liking, or failing that you can write
your own to address your concerns.
Well this would be great,.. I mean the current MAIN implementations of
OpenPGP are probably GnuPG and PGP. I think David and Werner who
represent GnuPG are reading this list and you, are you still at PGP
Corporation?
If some or all of you find suggestions that I made or will make worth
to implement (e.g. that critical bit issues) we could put this in
practice even before having (perhaps at some day) a new RFC.
Thanks for allowing me to ask additional questions, I have "plenty" left ;-)
But I'll start new threads for them.
Best wishes,
Peter