keyserver spam

Jerome Baum jerome at jeromebaum.com
Sat Dec 17 17:58:28 CET 2011


On 2011-12-17 17:04, MFPA wrote:
> On Saturday 17 December 2011 at 3:25:56 PM, in
> <mid:4EECB484.6080701 at jeromebaum.com>, Jerome Baum wrote:
>> I doubt the validity of those automated checks and
>> checks on the email anyway. What constitutes "owning"
>> foo at example.com?
> 
> As far as that server's checking is concerned, being able to receive
> the email they send out to that address and respond to it or click a
> link.

Okay so we're assuming that "ownership" means being able to read mail
there. Given an attacker that cannot read mail for foo at example.com, if
that attacker uploads a key with UID foo at example.com, what value does
this verification have? If I don't verify the key, and send an encrypted
email to foo at example.com, the attacker presumably cannot read the
message anyway. So then I wouldn't even need to encrypt it. So then the
key is useless for encryption. So is the check also.

For signing, well I don't usually care that "some person who was at a
point or currently is able to receive or intercept emails sent to
foo at example.com signed this message", I usually care that "John Smith
signed it". But let's assume I care whether something really originated
with a person that was or is able to read email to foo at example.com, how
is this more useful than just emailing them to confirm?

i.e. IMO emails on UIDs are bullshit. So are certification policies that
say (or don't say but enforce anyway) that you must have an email on
your UID. Why refuse to certify _less_ information?

Jerome

Disclaimer: Of course everyone can make their own choices. I am
expressing my viewpoint. My viewpoint may not necessarily be that of the
company or companies I work or have worked or will work for. Trademarks
are those of their respective owners. Copyrights are those of their
respective owners. Database copyrights are those of their respective
owners. Someone's name is also theirs. Blue means blue, red means red.
The law applies. Do not break the law. Do not read this email if it is
not intended for you. If you cannot tell that it is not intended for
you, that's your fault. I reserve the right to sue your ass anyway.
"Apple" and "i<Anything>" are trademarks of Apple Inc., co., or
something like that. "Orange" is probably a trademark of someone else as
well. "Peach" is probably the trademark of the guys who trademarked
"Orange", or maybe it's Apple's trademark. Who's in for a bet that
"T-<anything>", "z<Anything>", "y<Anything>" and "x<Anything>" are also
all trademarked? DO NOT USE THIS DISCLAIMER TO OPERATE NUCLEAR POWER
PLANTS OR WEAP... DEFENSE TECHNOLOGY. OH SHIT I LEFT MY CAPSLOCK ON ...
Do not operate this disclaimer if you are prohibited from doing so.
Operate it only when you are not prohibited from operating it.

Have a great Christmas (if you celebrate it)!

-- 
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
--
nameserver 217.79.186.148
nameserver 178.63.26.172
http://opennicproject.org/
--
No situation is so dire that panic cannot make it worse.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 878 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20111217/c6875b65/attachment.pgp>


More information about the Gnupg-users mailing list