Subject: A good article on S/MIME implementation problems

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 24 Mar 2004 17:36:42 -0800

Greetings again. I wouldn't normally send "here's another S/MIME 
article" messages to the list, but this author has done an excellent 
job of both finding the problem and proposing solutions.

<http://weblog.infoworld.com/udell/2004/03/23.html#a952>

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Russ Housley <[email-masked]>
Date: Thu, 25 Mar 2004 07:45:44 -0500

Paul:

I do not completely agree with your assessment.  I had a short email 
exchange with Jon Udell, and I made the following points.

1.  The article gives the impression is that S/MIME is broken, and this is 
not the case.  I would have been much happier with a title that conveyed 
problems with certificate issuing services and the ramifications of poor 
identity proofing.  S/MIME is not the only security protocol that will 
suffer if the identity in a certificate is bogus.

2.  As far as S/MIME is concerned, the email address is the 
identity.  X.500 Distinguished Names are not helpful to the S/MIME 
application, as there are not any protocol fields that make use of this 
form of identity.

3.  The fact that Outlook hides the only form of identity that is validated 
is the biggest problem.

Now that a script has been posted, maybe we should put some stronger 
language in MSGbis about the user interface.

Russ

At 05:36 PM 3/24/2004 -0800, Paul Hoffman / IMC wrote:

>Greetings again. I wouldn't normally send "here's another S/MIME article" 
>messages to the list, but this author has done an excellent job of both 
>finding the problem and proposing solutions.
>

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 25 Mar 2004 08:17:44 -0800

At 7:45 AM -0500 3/25/04, Russ Housley wrote:
>1.  The article gives the impression is that S/MIME is broken, and 
>this is not the case.  I would have been much happier with a title 
>that conveyed problems with certificate issuing services and the 
>ramifications of poor identity proofing.  S/MIME is not the only 
>security protocol that will suffer if the identity in a certificate 
>is bogus.

We disagree that the article gives the impression that S/MIME is 
broken. Reading it, I came away with the impression that some S/MIME 
implementations are broken. Maybe I've been working with this too 
long and I know that S/MIME isn't broken.

>application, as there are not any protocol fields that make use of 
>this form of identity.

Exactly right. The fact that Thawte asks for, and some S/MIME 
applications use, it shows a disregard for the standard. They are 
blatantly ignoring the SHOULD NOT.

>3.  The fact that Outlook hides the only form of identity that is 
>validated is the biggest problem.

Absolutely true, and pretty clear from the article.

>language in MSGbis about the user interface.

That would be nice.

--Paul Hoffman, Director

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 25 Mar 2004 13:37:29 -0500

Not exactly right.

There is a difference between an RFC822 address as a user identity
and an RFC822 address as routing information to enable message
delivery.  If I have a certificate identifying me as
[email-masked], then S/MIME user agents should display
my identity without rejecting, or even whining, if I send a signed
message from my hotmail account.  And S/MIME user agents should
allow me to encrypt a message to Paul using his imc.org certificate,
but address it to Paul's hotmail account, without rejection or
whining.

Using a different syntax for subject names and email addresses makes
this distinction obvious and would force user agents to operate
correctly.  Using the same RFC822 syntax for both subject names and
email addresses leads to confusion between a user's single identity
and that user's multiple mailboxes.

Mismatch between an identity in a certificate and an unauthenticated
address in a message header is NOT a security vulnerability.
Displaying an unauthenticated message header as if it were an
authenticated identity IS a vulnerability.   Blurring this distinction
by saying "the email address is the identity" is wrong, even if it
is written down in black and white in the RFCs.

Dave

Paul Hoffman / IMC wrote:

>> 2.  As far as S/MIME is concerned, the email address is the identity.  
>> X.500 Distinguished Names are not helpful to the S/MIME application, 
>> as there are not any protocol fields that make use of this form of 
>> identity.
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 25 Mar 2004 12:45:19 -0500

Paul:

>>1.  The article gives the impression is that S/MIME is broken, and this 
>>is not the case.  I would have been much happier with a title that 
>>conveyed problems with certificate issuing services and the ramifications 
>>of poor identity proofing.  S/MIME is not the only security protocol that 
>>will suffer if the identity in a certificate is bogus.
>
>We disagree that the article gives the impression that S/MIME is broken. 
>Reading it, I came away with the impression that some S/MIME 
>implementations are broken. Maybe I've been working with this too long and 
>I know that S/MIME isn't broken.

The title implies that S/MIME is broken.

>Exactly right. The fact that Thawte asks for, and some S/MIME applications 
>use, it shows a disregard for the standard. They are blatantly ignoring 
>the SHOULD NOT.

Agree.

>Absolutely true, and pretty clear from the article.

Yes.  So, the title of the article could have been more descriptive of the 
real issue.

>>language in MSGbis about the user interface.

Maybe the editor can generate some proposed text.

Russ