NPR : E-Mail Encryption Rare in Everyday Use

[Ben Laurie]

Alex Alten wrote:
> At 05:58 AM 3/3/2006 +0000, Ben Laurie wrote:
>> alex at alten.org wrote:
>> >> alex at alten.org wrote:
>> >>>> Alex Alten wrote:
>> >>>>> At 05:12 PM 2/26/2006 +0000, Ben Laurie wrote:
>> >>>>>> Alex Alten wrote:
>> >>>>>>> At 02:59 PM 2/24/2006 +0000, Ben Laurie wrote:
>> >>>>>>>> Ed Gerck wrote: We have keyservers for this (my chosen
>> >>>>>>>> technology was PGP). If you liken their use to looking up an
>> >>>>>>>> address in an address book, this isn't hard for users to grasp.
>> >>>>>>>>
>> >>>>>>> I used PGP (Enterprise edition?) to encrypt my work emails to
>> >>>>>>> a distributed set of members last year.  We all had each
>> >>>>>>> other's
>> >>>>>>> public keys (about a dozen or so).
>> >>>>>>>
>> >>>>>>> What I really hated about it was that when fred at company.com sent
>> >>>>>>> me an email often I couldn't decrypt it.  Why?  Because his
>> >>>>>>> firm's email server decided to put in the FROM field
>> >>>>>>> "fred at server.company.com". Since it didn't match the email name
>> >>>>>>> in his X.509 certificate's DN it wouldn't decrypt the S/MIME
>> >>>>>>> attachment. This also caused problems with replying to his email.
>> >>>>>>> It took us hours, with several experimental emails sent back and
>> >>>>>>> forth, to figure out the root of the problem.
>> >>>>>>>
>> >>>>>>> No wonder PKI has died commercially and encrypted email is on the
>> >>>>>>>  endangered species list.
>> >>>>>> I trust you don't think this is a problem with PKI, right? Since
>> >>>>>> clearly the issue is with the s/w you were using.
>> >>>>> I place the blame squarely on X.509 PKI.  The identity aspect of it
>> >>>>> is all screwed up. No software implementation can overcome such a
>> >>>>> fundamental architectural flaw.
>> >>>> OK - I'll bite - why does the sender's identity have any impact
>> on the
>> >>>> recipient's ability to decrypt?
>> >>>>
>> >>> Because the software needs a unique ID/name to find the correct
>> >>> key to use. In practice (corporate) users can have multiple email
>> >>> names, see my reply to Peter Gutman.  This is not the fault of
>> >>> the email architecture, which has been working fine for 30-40
>> >>> years, but the fault
>> >>> of the X.509 architecture trying to piggyback on an address/name
>> >>> space that is not designed with security/cryptography
>> >>> considerations in mind.
>> >> I have to admit to not being familiar with S/MIME, but the usual
>> >> practice is to identify the signing key in the signature. Certainly
>> this
>> >> is what OpenPGP does. Its also kinda weird to refuse to decrypt just
>> >> because the signature can't be verified.
>> >>
>> >
>> > How does OpenPGP identify the signing key in the incoming email's
>> signature?
>>
>> Here's the output of one of the example programs in OpenPGP:SDK
>> (http://openpgp.nominet.org.uk/), showing the structure of an OpenPGP
>> signed file. I trust it is self-explanatory.
> 
> Assuming this file is attached to an incoming email message, how does the
> receiver's email software match the Signer ID (= 0x8337FE6485F4ED64) to
> a X.509 cert in his local cache that is associated with the email
> sender's name
> (= "fred at company.com")?

It is _OpenPGP_ so it does not match it to an X.509 cert. It matches it
to an OpenPGP key.

-- 
http://www.links.org/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com