signing a robot's key - was: Re: Global Directory signatures
jeff+gnupg at jeffenstein.dyndns.org
Sat Jan 1 22:40:35 CET 2005
-----BEGIN PGP SIGNED MESSAGE-----
On Sat, Jan 01, 2005 at 04:47:21PM +0000, Neil Williams wrote:
> IMHO, you'd be better off with an x.509 Thawte key - their trust model is
> closer to yours.
I also don't put too much stock in them verifying the identity for me either.
There have been too many cases of certificates issued based on false
> You are willing to trust a key only on the say so of a corporate entity -
> that's a Thawte and x.509 model, not GnuPG.
Fortunately GnuPG can work with my trust model, which is that I trust myself,
friends, and (for work stuff) others at my company. Works like a champ for
> > To use the X.509/SSL model,
> GnuPG doesn't use the x.509 model - that's the entire point. The two models
> cannot be reconciled, the fundamentals are different and comparisons are
> void. This is the flaw in the PGP GD - they are trying to square a circle.
GnuPG (and PGP in general) can work with either model. In effect, the X.509
model is only a more limited version of the PGP model, where only a certain type
of key can be trusted. The difference is that the pgp way lets the user choose
the model, and X.509 does not (easily).
> > > As it would be my own key,
> > > created under false pretences, I could introduce it to PGP GD and sign
> > > whatever I wanted with it.
> > But you couldn't put it on the PGP web site, or sign every key that is
> > submitted to the PGP global directory,
> Why not? It's a simple matter of programming. (bash/cron in this case) and a
> decent connection. There'd be no need to set a passphrase on the false key so
> my system could sign maybe 1,000 a minute? i.e. I'd be creating a second
> robot - a false one. Just as capable as the one on the site already.
But that still won't erase the original signatures on the key. It will now
have two signatures from different key ID's, which would most likely quickly
be noticed by the maintainers.
You also didn't answer how you would get it behind all of those links on the
> Any software method of signing can be copied and reimplemented elsewhere.
> > and modify the keys in the directory
> > to remove the valid signature, making yours look correct.
> No need - with all keys signed twice, who can tell which is genuine? You're
> now reduced to checking only a fingerprint - the keyid can easily be
> duplicated. Just run a script on --gen-key until /dev/random provides the
> right input to output the required 8 characters. Duplicate keyid's already
> exist - 0xDEADBEEF is almost common.
Only 5 keys on the key servers. Apparently not too common. Could be done,
but it wouldn't go unnoticed for long, and once the key was removed from the
keyserver, you have to start from zero. I haven't tried it, but I'm guessing
it takes a while to generate the neccessary ~2 billion key pairs on average to
have a collision. It's certainly not the low hanging fruit in this model.
> > Anybody can create a president at whitehouse.gov key. However, nobody
> > will trust it because that key does not sign messages coming from
> > president at whitehouse.gov or respond to messages encrypted to
> > president at whitehouse.gov.
> So you are trusting your entire verification to whether someone can hack an
> email account or forge the From: address????
For anything I would trust in normal e-mail, yes.
> > Ok, if the definition of verify is not 'prove that something is what it
> > claims to be', please fill me in. Oxford lists, "establish the truth or
> > correctness of by examination." How would you verify a toll booth is what
> > it says it is? It's identity is it's function. It's identity is not who is
> > in the booth.
> Wrong model. A signature verifies a PERSON.
A singature verifies a user-id, which may or may not correspond to a single
person. Do a keysearch on 'corporate', or go to most computer security sites
(including microsft, hp, etc), and you will find PGP keys that to not have a
person's name on them, and do not correspond to a person, yet they are in
daily use, and trusted with the security of (possibly) hundreds of thousands
of computer system's security. Whether or not you personally trust it enough
to sign it, you have to agreee that a user-id can correspond to a role, and
that hundreds, or possibly thousands of people have enough trust in this to
publicly sign user-ids that correspond to a role.
> > On to another example, SSH.
> Still the same model as x.509. Please get your head around the OpenPGP trust
> model - it's not about corporate bodies or material objects, it's about one
> individual trusting another individual.
SSH does not have the same model as X.509. Not even close. There is no
concept of certification in SSH, there is only host and unix user key pairs.
It can rely on keys put in place by the administrator, but this is rarely used
because it is difficult to maintain, can be overriden by the user, and is
almost impossible to cross administrative domains. It does use the OpenSSL
libraries, but only for the cryptographic primitives, not for the protocol
level. OpenPGP verification of keys has recently been added, so it could be
said (very loosely) that it corresponds more to the pgp model than to the
> > You're forgetting that not everybody wants the same level of verification,
> > or has the same ideas about what verification means.
> Doesn't mean I can't help inform those people of an alternative viewpoint.
That I don't have a problem with, but you're putting forth your system as the
only valid alternative. This just isn't the case.
> > In the two instances where I've helped set up PGP to be used in a corporate
> > environment (for payroll and customer billing info), the verfication
> > process was:
> > 1) Received key on disk via fedex.
> > 2) Made a test transaction.
> > 3) Called the contact at the remote company to verify that the transaction
> > did indeed arrive and they were able to process it.
> > In either of these cases, the management would never have accepted, 'person
> > x signed the key, so we can trust it', regardless of the identity of person
> You should consider using x.509 for those situations - GnuPG is built on a
> PERSONAL WoT.
X.509 is very painful to use for files transferred by anything but SSL.
Non-interactive secure SSL more difficult to setup than PGP for the same
purpose. PGP lets the file reside on unsecure medium in the middle without
being comprimised (for example, mail servers or ftp servers). PGP can be more
easily adapted to secure non-interactive use, though the gap is closing on
> > > Don't sign it unless you can prove it!
> > ... to a satisfactory level.
> No, unless you can prove it 'beyond a reasonable doubt'.
Again, subjective. If it wasn't, most trials would be a lot shorter.
> Again, people want to be able to RELY on your signatures. This is why GnuPG
> has a trust level that the user has to set themselves - when I meet someone
> for a keysigning, I make an assessment of how well they verify my key, how
> they take care of their own key and set my trust accordingly.
> Your signatures can affect my trust model - that is why I'm taking time out to
> reply to the thread.
In this respect, the WoT is working. With my attitude towards keysinging, I
would never have enough signatures on my key from keys you trust to make it to
trusted status on your keyring. If I could, then there is something wrong
with the concept.
You can use the keyparty model; I don't have any problem with that. However, I
won't participate in it. PGP works with a web of trust, but it does not
define the size of the web, or how to build it; that is up to the user. My
web looks very different than yours, but I'm willing to live with that.
> > All this means is that I don't trust your signatures and you don't trust my
> > signatures, and life goes on.
> I really think you should look at Thawte - you've entirely missed the personal
> aspect of the GnuPG trust model.
> It's about Bob trusting Neil who trusts Anne. It's about Bob assessing how
> carefully Neil verifies keys so that he can decide whether he should set
> Neil's key to fully trusted and therefore trust Anne's key.
Yes, this works for as much as you would trust Bob's trust. Me, I would only
trust Bob to introduce me to Neil. I'm more paranoid and don't trust Neil
unless I know him, and GnuPG works just fine for me that way also, with only a
single option changed from the default. I've _personalized_ it to my trust
preferences, which are not far from the default.
The X.509 examples were just to point out that most people on the list have
probably used a system where they have implicitly stated their trust (backing
it up with money; more trusting than just signing a key) in a
not-personally-known third party, but refuse to do so in this case.
Regardless of the system in use, it is effectively the same leap of faith;
trusting 'Bob' - the browser authors, who trust 'Neil' - the CA, to introduce
you to someone else who will take your money. Only in this case, 'Bob' is the
role of browser author, and 'Neil' is the role-based key of Thawte, or
Verisign, or ABA.ECOM.
In any case, I'm not trying to tell people they should trust role based keys,
I'm just trying to point out that some people do, and are willing to tell the
world that this is the case. Whether you are willing to do so is up to you,
and whether I am willing to do so is entirely up to me.
Me - jeff at jeffenstein.dyndns.org
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Gnupg-users