Alex Alten wrote: > At 05:58 AM 3/3/2006 +0000, Ben Laurie wrote: >> [EMAIL PROTECTED] wrote: >> >> [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. > > 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 > (= "[EMAIL PROTECTED]")?
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 [EMAIL PROTECTED]
