signing a robot's key - was: Re: Global Directory signatures

[Neil Williams]

On Saturday 01 January 2005 3:34 pm, Jeff Fisher wrote:
> On Sat, Jan 01, 2005 at 01:31:35PM +0000, Neil Williams wrote:
> > But you cannot do that, you cannot prove to me that it is that key. There
> > is no way that I can verify the key because I cannot verify the UID. As
> > David said, it is trivial to create yet another PGP Global Directory
> > Verification Key - how can you prove which one is 'real'?
>
> What you're really saying is that it can't be proven to a level you are
> willing to accept.  Fortunately, PGP/GnuPG doesn't dictate this, so people
> can follow whatever trust model they are willing to accept.

That's true, but there's no harm in putting up reasons for users to *think* 
about the trust model.

> I (and others 
> I've worked with) willing to accept that roles exist, and that roles cannot
> neccessarily be associated to a single person.  You (and others on this
> list) are not.  That's this discussion in a nutshell.

IMHO, you'd be better off with an x.509 Thawte key - their trust model is 
closer to yours.

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.

>
> 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.

> No, it's not the same system, but it has the same concept of trusting keys

Completely the opposite concept of trusting keys. x.509 you/I trust Thawte 
etc. to verify the person. GnuPG I do that myself. The two have different 
models, different uses.

Nothing wrong with either, it just pays to understand which model you will 
follow.

> > 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.

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.

> Yes, you can 
> create a key that looks correct, but you can't use that key in the intended
> role.

If I had time, I probably would. 

> 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????

I can send from any address I like, it's only a case of changing the email 
client config!

Hacking an email account is not exactly hard - depending on the user. A 
dictionary attack will deal with most ordinary users. How many people use 
'password' for their email?

How many people are actually going to wait for email verification of the PGP 
GD key before signing it anyway? The documentation makes no mention of it and 
encourages users to sign without it.

> The real PGP directory key acts in a way 
> consistent with it's name, which (to the people using the directory) proves
> it's identity.

Only if your trust model is x.509.

> 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. 

Before I sign a key, I establish the correctness of the identification of that 
person by examining photo ID, verification of the email address (using CA 
bot) and verify the fingerprint using a print out handed to me by that person 
face-to-face at the time of photo ID verification.

If any stage fails, I don't sign.

> For the toll booth example, do you need to know who built the toll booth to
> verify that it is indeed a toll booth?  Even when travelling in a foreign
> country?  Would you refuse to pay if you could not verify this?

For the last time, I'm verifying a PERSON, not just the key.

x.509 requires you only to verify the key as issued by Thawte etc.
OpenPGP requires you to verify the UID - the PERSON.

>
> 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.

> 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.

> 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.

> > Don't sign it unless you can prove it!
>
> ... to a satisfactory level.

No, unless you can prove it 'beyond a reasonable doubt'.

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.

Yes, passports can be forged - there are limits.

> That you have your idea of verfication and what you are willing to accept
> is fine.  I have a different idea.  You can use yours, and I can use mine. 

As long as you don't make pointless signatures that dilute the trust.

Your signatures can affect my trust model - that is why I'm taking time out to 
reply to the thread.

> 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.

(I am not a number)
:-)

-- 

Neil Williams
=============
http://www.dclug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.williamsleesmill.me.uk/
http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050101/584d87fc/attachment-0001.bin