| David Shaw on 7 Feb 2004 19:14:02 -0000 |
|
On Sat, Feb 07, 2004 at 01:13:18PM -0500, gabriel rosenkoetter wrote:
> On Sat, Feb 07, 2004 at 12:19:32PM -0500, David Shaw wrote:
> > It's interesting to me that those people who send out tokens to be
> > signed generally send them encrypted (I do it as well). It doesn't
> > hurt to encrypt, but strictly speaking, there really isn't any need to
> > do it either - the signature they are sending back is issed by the
> > primary, and when you sign a key (well, a OpenPGP key), you're binding
> > the user ID to the same primary key. The whole thing could be in
> > cleartext.
>
> Not really. Enciphering it means that they couldn't even read the
> message without controlling the private key.
Not completely true (at least in OpenPGP). The ability to issue a
signature is distinct from the ability to decrypt a message (say, from
a --export-secret-subkeys type of key). The token challenge needs to
be answered with a signature from the primary key.
I'm a good example of this - let's say that someone stole my computer
and beat my passphrase out of me. They could then decrypt messages
sent to me, but still couldn't answer a signing challenge since my
primary secret key isn't on my computer.
> > Heh, actually 1.3 is already quite a bit slower than 1.2, since 1.3
> > combines --rebuild-keydb-cache with --check-trustdb.
>
> Well, *I* don't care if it takes 30 minutes at this point, since I
> have no-auto-check-trustdb set and I run a --check-trustdb every
> weekday out of cron during my drive to work, but are you sure that's
> a good idea?
No, I'm not. It's something I'm still playing with, and presumably
when 1.3.x gets closer to 1.4 and more people start using it, it'll
become clear whether it is acceptable or not.
There is a significant advantage to doing a sig cache check before
running the trustdb. For one, the internal key cache gets populated,
and that's a minor win. For two, the trustdb check goes faster since
no sigs need to be verified.
The problem is that the two distinct functions are more or less glued
together at this point. A better implementation would update the
trustdb and sig caches at the same time, causing little or no
slowdown. I'm vacillating on whether to do this for 1.4 or 1.6 - if I
do it in 1.4, then 1.4 is going to be delayed. There might be a
middle ground here. I haven't looked too closely at it yet.
> > I'm still working on that and looking for ways to speed it up
> > before 1.4. Linear search is a killer.
>
> Remind me why this HAS to be linear?
It doesn't. It just is in the current implementations (1.2.x, 1.3.x).
1.9 isn't linear. PGP is linear, by the way, but because they have a
completely different trust implementation you don't see the slowness.
> > Eventually, GnuPG is going to need a rethinking of the keyring
> > management. GnuPG 1.9 (will be 2.0 eventually) has a completely
> > different database backed system, but the 1.x branch is going to stay
> > with flat files a la PGP. There are better ways to handle flat files,
> > though.
>
> What are you using? Berkeley DB? (file(1) thinks it's "data"...
> because it's enciphered, I think, eh?)
In 1.9, I'm not sure. The 1.2.x and 1.3.x rings are classic PGP
style, where the key packets are just strung together in order. I
guess file(1) doesn't have an entry for a PGP header in its database.
> > The main reasons it hasn't been done is complexity (social, not code).
> > It would be a significant change to the current trust model which is
> > already barely understood.
>
> At the same time, it would bring the trust model in line with the
> provided UI, which is attractive.
Yes, it is. It is an unfortunate situation. We can't really go back
and remove trust levels, and can't really go forward and put them into
the trustdb. Eventually something will have to give. Even without a
full trust model that incorporates trust levels, a simple lockout
("ignore any signatures of level 1") would be useful.
> > It would also mean that the GnuPG web of
> > trust would differ from PGP, which is also confusing.
>
> Right, well, that's an argument for removing the trust levels
> entirely. Is there anything resembling this in the OpenPGP standard?
Sure, the trust levels actually date back to the PGP 2.x era (PGP 2.x
understands them fine). They're in RFC-1991, and in RFC-2440
(OpenPGP). All versions of PGP and GnuPG understand them, and all
treat them as a generic signature.
> > Despite this, I rather like the idea of anyone using any trust model
> > they like (it's one of the big strengths of OpenPGP, in my book), so
> > rather than implement many trust models, I've started on a system for
> > an "external" trust model in GnuPG.
>
> I like this approach a lot.
>
> > This is about halfway done, and should be in 1.4. I imagine less than
> > a hundred lines of perl could do a trust model that takes into account
> > strength of trust.
>
> What's the API for this look like? That is, what does GnuPG hand
> off for processing? (High level: I'll go look at the code when I'm
> ready to actually do this for myself.)
The user uses whatever they like to generate the trust relationships
(this may include 'gpg --with-colons --list-keys' so the user doesn't
need to parse OpenPGP packets). When ready, they output a text file
that looks something like:
vvv key fingerprint
trust:4366A4AE2A3139B8B3F623820B99158A83118C39
vvv namehash of uid in question
valid:E3209DD7123126AD0F6A2B0A64C8671A7B4E2FB1:full
vvv a different namehash for a different uid
valid:12121233123126123119898864C86711231E2FB2:undefined
Run that file through the "GnuPG trust compiler" program, which spits
out a trustdb.gpg. The nice thing about this is that it doesn't
involve yet more code inside GnuPG. It's virtually all external (in
the compiler program).
David
Attachment:
pgpvTyWKhXHPg.pgp
|
|