Keyservers and the future

[Neil Williams]

On Thursday 19 May 2005 8:15 pm, Radu Hociung wrote:
> Depending on proposal, email authentication would require between 1
> key/domain owner

Is that a completely different key to another domain used by the same owner?

I've got many domains but I only want one main key.

If someone trusts codehelp.co.uk does that mean they also trust dcglug.org.uk 
just because I've got both in the UID's of my key?

There are lots of keys with multiple UID's across disparate domains - like 
debian.org.

Are you proposing a completely new key per domain that is "less secure" than 
the personal key because it's per domain and not per user? Who controls such 
domain keys? Is this just another "corporate" key?

What about domains that have millions of users (like aol.com)?

I may trust one or two individuals with AOL accounts, there is NO way I'm 
going to trust everything from AOL!

> If email authentication was implemented, the majority of mail traffic
> would be signed and verified.

You're just verifying that the signature is good, not that the key is trusted? 
That's reasonable.

How do you guarantee that From: cannot be spoofed - it sounds like you are 
delegating that to the individual ISP / domain holder. I'm concerned that the 
domain is too blunt as an instrument against spam and that it will remain 
easy to send spam from: aol.com and hotmail.com. Even if someone does 
compromise the AOL terms and conditions, users cannot ignore all email from 
that domain - it's simply too large - so I could not set the aol.com key to 
be untrusted or unwanted.

This could prejudice small domains, userspace domains, unfairly. The big 
domains would trivialise the signature because you could not discriminate 
between your AOL friends and the AOL spammers. If a particular domain holder 
with lots of accounts is tardy or just inefficient in booting off people who 
abuse their terms, the user is left with a useless "validation" because the 
user cannot distinguish between users at the domain.

> DomainKeys, for instance, works at the transport level. Somewhat like
> SSH, where the client and server use one key to encrypt the datastream,
> but a different key is used by the user to actually authenticate and log
> in. DomainKeys does not encrypt the channel, but it only signs it (it
> signs a subset of the message headers as well as the body of the
> message). If a recipient domain trusts Yahoo's keys, he can assert that
> the mail really came from the Yahoo domain. This is a per-domain
> signature, not per-user.

Where does the secret key reside?

Who controls the signing?

What happens with the existing signature?

Are you using MIME to achieve this - what are you going to do about broken 
email clients like OE that hide the message when receiving PGP/MIME - the 
message body is displayed as an attachment.

What about other clients (like some webmail) that cannot yet cope with 
PGP/MIME?

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050520/33e9bbc8/attachment.pgp