[EMAIL PROTECTED] wrote: >> ----- Original Message ----- >> From: "Ben Laurie" <[EMAIL PROTECTED]> >> To: [EMAIL PROTECTED] >> Subject: Re: NPR : E-Mail Encryption Rare in Everyday Use >> Date: Thu, 02 Mar 2006 10:16:55 +0000 >> >> >> [EMAIL PROTECTED] 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 [EMAIL PROTECTED] sent >>>>>>> me an email often I couldn't decrypt it. Why? Because his >>>>>>> firm's email server decided to put in the FROM field >>>>>>> "[EMAIL PROTECTED]". 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. ==== ptag new_format=0 content_tag=8 length_type=3 length=0x0 (0) position=0x0 (0) COMPRESSED packet Compressed Data Type: 1 ==== ptag new_format=0 content_tag=4 length_type=0 length=0xd (13) position=0x0 (0) ONE PASS SIGNATURE packet Version: 3 Signature Type: Signature of a binary document (0x0) Hash Algorithm: SHA1 (0x2) Public Key Algorithm: RSA (Encrypt or Sign) (0x1) Signer ID: 0x8337FE6485F4ED64 Nested: 1 ==== ptag new_format=0 content_tag=11 length_type=0 length=0x22 (34) position=0xf (15) LITERAL DATA HEADER packet literal data header format=b filename='to-be-signed' modification time=1141297085 (Thu Mar 2 10:58:05 2006) LITERAL DATA BODY packet literal data body length=16 data= To Be Signed. ==== ptag new_format=0 content_tag=2 length_type=1 length=0x95 (149) position=0x33 (51) SIGNATURE packet Signature Version: 3 Signature Creation Time: time=1141297085 (Thu Mar 2 10:58:05 2006) Signature Type: Signature of a binary document (0x0) Signer ID: 0x8337FE6485F4ED64 Public Key Algorithm: RSA (Encrypt or Sign) (0x1) Hash Algorithm: SHA1 (0x2) hash2: 0xBF33 sig=7344970C0DF62B089E79FFF024137E9D7D8919B6B1F1F29F3CCE8CD34625759EC181452C1A17858E418BA838FD3FED6AD013E7562F0B4E87BCA81D82D22B825A3ED6447E0F31F14DE0321554D558CEDCC339424ADA01B7C7374BBC59DE54E6BE4670D9D9E6FAC6412E927545DF1D2F0A373BFE6D058893CF675554F2DF8BE079 -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
