Subject: Re: draft-ietf-smime-idea

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 24 Feb 2000 23:21:13 -0700

"The wonderful thing about standards is that there are so many to choose from."

I strongly agree with Paul.  I am not aware of ANY kind of a significant ground swell 
for IDEA, especially with the relaxation of the US export regulations and the wider 
availability of triple-DES and the forthcoming AES algorithm(s).  In fact, I think there 
are already FAR too many algorithms, variations, etc., in the S/MIME standard as 
it is, and to virtually no good purpose that I can see.

Unless a particular algorithm is obviously off the wall, the tendency is for every 
implementation to include every algorithm, regardless of the actual number of users. 
Some Program Manager somewhere will say, "But what if customer B want to use 
algorithm X, and we don't support it. Then customer A would not be able to 
communicate with him, and we might lose sales."

And pretty soon, the product is up to 60 megabytes in size, chock full of unused 
options, and everyone wonders why the product is so bloated and hard to use, not
to mention all of the interoperability problems caused for the customers.

It's high time to say ENOUGH, and to kill off this sort of useless nonsense while it is 
still budding, without consuming useless cycles debating the format of the document, 
the IPR issues, etc., etc.

Bob

>>> Paul Hoffman / IMC <[email-masked]> 02/23/00 10:58AM >>>
[snip]   To be frank, I've never 
heard of anyone wanting to use IDEA for anything other than old PGP. The 
folks who wrote PGP had their reasons for choosing IDEA when they did, but 
they dropped IDEA as a required algorithm for OpenPGP and that doesn't 
appear to have negatively affected them. The IETF shouldn't codify this 
kind of marketing hype, even in an Informational RFC. 
[snip]

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 24 Feb 2000 23:21:13 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-smime-idea
Sender: [email-masked]

"The wonderful thing about standards is that there are so many to choose from."

I strongly agree with Paul.  I am not aware of ANY kind of a significant ground swell 
for IDEA, especially with the relaxation of the US export regulations and the wider 
availability of triple-DES and the forthcoming AES algorithm(s).  In fact, I think there 
are already FAR too many algorithms, variations, etc., in the S/MIME standard as 
it is, and to virtually no good purpose that I can see.

Unless a particular algorithm is obviously off the wall, the tendency is for every 
implementation to include every algorithm, regardless of the actual number of users. 
Some Program Manager somewhere will say, "But what if customer B want to use 
algorithm X, and we don't support it. Then customer A would not be able to 
communicate with him, and we might lose sales."

And pretty soon, the product is up to 60 megabytes in size, chock full of unused 
options, and everyone wonders why the product is so bloated and hard to use, not
to mention all of the interoperability problems caused for the customers.

It's high time to say ENOUGH, and to kill off this sort of useless nonsense while it is 
still budding, without consuming useless cycles debating the format of the document, 
the IPR issues, etc., etc.

Bob

>>> Paul Hoffman / IMC <[email-masked]> 02/23/00 10:58AM >>>
[snip]   To be frank, I've never 
heard of anyone wanting to use IDEA for anything other than old PGP. The 
folks who wrote PGP had their reasons for choosing IDEA when they did, but 
they dropped IDEA as a required algorithm for OpenPGP and that doesn't 
appear to have negatively affected them. The IETF shouldn't codify this 
kind of marketing hype, even in an Informational RFC. 
[snip]

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 24 Feb 2000 16:29:08 -0500
To: Aram Perez <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft-ietf-smime-idea
Cc: [email-masked]
Sender: [email-masked]

Aram:

The subsection within section 6 of RFC 2630 are a good start.  It really 
depends what kind of algorithm is being specified: encryption, hash, key 
management, signature, or key wrap.

Russ

At 08:56 AM 02/24/2000 -0500, Aram Perez wrote:
>Hi Russ, Paul and others,
>
>Is it possible to create a "template" RFC for using algorithms with S/MIME?
>The CAST-128 document might be a good starting point.
>
>Regards,
>Aram Perez
>
>
>-----Original Message-----
>From: Russ Housley [mailto:[email-masked]]
>Sent: Wednesday, February 23, 2000 2:20 PM
>To: [email-masked]
>Subject: Re: draft-ietf-smime-idea
>
>
>All:
>
>Paul raises some very important points.  Let me share my view as the S/MIME
>Working Group Chair.
>
>1.  We must have an IPR statement for this document to progress to an RFC.
>
>2.  I do not mind some justification text.  Something like: "Organization
>who make already use of IDEA for other applications also want to use IDEA
>in S/MIME."  But, in my opinion, the marketing hype needs to be
>significantly reduced.  The CAST-128 document does not try to convince
>anyone that CAST-128 is appropriate or inappropriate for any particular
>group of users.  The IDEA document should have a similar tone.
>
>3.  I would like this document to become a Standards Track document.  The
>document should state the one and only way that IDEA is used with
>CMS.  Clearly, IDEA will not be mandatory to implement, but if IDEA is
>implemented, then it MUST be done in the manner specified in this
>document.  I cannot recommend that this document become a Standards Track
>RFC until items 1 and 2 are repaired.
>
>Russ
>
>
>At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote:
> >There are a few things in this document that should raise concern.
> >
> >Appendix C states clearly that this is a patented algorithm for which
> >licensing is available. However, it appears that no one has let the IETF
> >Secretariat know that. Nothing about IDEA is listed on
> ><http://www.ietf.org/ipr.html>. This draft should not be considered until
> >there is a formal statement to the IETF.
> >
> >Parts of the document sounds like a marketing brochure. "Today, IDEA is
> >widely applied in electronic business applications." "Especially for those
> >organization who make already use of IDEA on a wide scale it is of high
> >interest that IDEA is also available in S/MIME." "Experts in cryptography
> >consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on.
> >
> >These seem particularly inappropriate for an RFC. To be frank, I've never
> >heard of anyone wanting to use IDEA for anything other than old PGP. The
> >folks who wrote PGP had their reasons for choosing IDEA when they did, but
> >they dropped IDEA as a required algorithm for OpenPGP and that doesn't
> >appear to have negatively affected them. The IETF shouldn't codify this
> >kind of marketing hype, even in an Informational RFC. To move forwards
> >with this, it would be nice if the authors went through the draft and took
> >out the marketing fluff.
> >
> >--Paul Hoffman, Director
> >--Internet Mail Consortium

Date: Thu, 24 Feb 2000 13:45:51 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: draft-ietf-smime-idea
Sender: [email-masked]

At 03:14 PM 2/24/00 -0500, Russ Housley wrote:
>Take a look at the cipher suite definitions associated with TLS.  Only one 
>cipher suite is mandatory to implement, but all of the cipher suite 
>documents are on standards track.

If Johnny jumped off a bridge, would you do it? :-) Other WGs are putting 
things like this on standards track; I don't think that is necessarily a 
good idea. This can probably be deferred until you talk with the ADs about 
what they think.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 24 Feb 2000 15:14:39 -0500
To: Paul Hoffman / IMC <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-smime-idea
Cc: [email-masked]
Sender: [email-masked]

Paul:

Take a look at the cipher suite definitions associated with TLS.  Only one 
cipher suite is mandatory to implement, but all of the cipher suite 
documents are on standards track.

The SKIPJACK and KEA document is an exception.  The algorithm to wrap one 
SKIPJACK key with another SKIPJACK key is not specified in a publicly 
available document. For this reason, it is not appropriate for the document 
to be on standards track.  All of the information to implement is not 
provided....

Russ

At 01:16 PM 02/23/2000 -0800, Paul Hoffman / IMC wrote:

>>3.  I would like this document to become a Standards Track document.
>
>Not to disagree with the WG chair, but it is unclear why this should be on 
>standards track. It is protocol information for the community about a 
>non-mandatory algorithm that, as far as we can tell, is barely used. 
>Because of that, isn't it much better qualified for Informational RFC?
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

From: Aram Perez <[email-masked]>
To: [email-masked]
Subject: RE: draft-ietf-smime-idea
Date: Thu, 24 Feb 2000 08:56:42 -0500
Sender: [email-masked]

Hi Russ, Paul and others,

Is it possible to create a "template" RFC for using algorithms with S/MIME?
The CAST-128 document might be a good starting point.

Regards,
Aram Perez

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Wednesday, February 23, 2000 2:20 PM
To: [email-masked]
Subject: Re: draft-ietf-smime-idea

All:

Paul raises some very important points.  Let me share my view as the S/MIME 
Working Group Chair.

1.  We must have an IPR statement for this document to progress to an RFC.

2.  I do not mind some justification text.  Something like: "Organization 
who make already use of IDEA for other applications also want to use IDEA 
in S/MIME."  But, in my opinion, the marketing hype needs to be 
significantly reduced.  The CAST-128 document does not try to convince 
anyone that CAST-128 is appropriate or inappropriate for any particular 
group of users.  The IDEA document should have a similar tone.

3.  I would like this document to become a Standards Track document.  The 
document should state the one and only way that IDEA is used with 
CMS.  Clearly, IDEA will not be mandatory to implement, but if IDEA is 
implemented, then it MUST be done in the manner specified in this 
document.  I cannot recommend that this document become a Standards Track 
RFC until items 1 and 2 are repaired.

Russ

At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote:
>There are a few things in this document that should raise concern.
>
>Appendix C states clearly that this is a patented algorithm for which 
>licensing is available. However, it appears that no one has let the IETF 
>Secretariat know that. Nothing about IDEA is listed on 
><http://www.ietf.org/ipr.html>. This draft should not be considered until 
>there is a formal statement to the IETF.
>
>Parts of the document sounds like a marketing brochure. "Today, IDEA is 
>widely applied in electronic business applications." "Especially for those 
>organization who make already use of IDEA on a wide scale it is of high 
>interest that IDEA is also available in S/MIME." "Experts in cryptography 
>consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on.
>
>These seem particularly inappropriate for an RFC. To be frank, I've never 
>heard of anyone wanting to use IDEA for anything other than old PGP. The 
>folks who wrote PGP had their reasons for choosing IDEA when they did, but 
>they dropped IDEA as a required algorithm for OpenPGP and that doesn't 
>appear to have negatively affected them. The IETF shouldn't codify this 
>kind of marketing hype, even in an Informational RFC. To move forwards 
>with this, it would be nice if the authors went through the draft and took 
>out the marketing fluff.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

Date: Wed, 23 Feb 2000 13:16:05 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: draft-ietf-smime-idea
Sender: [email-masked]

>3.  I would like this document to become a Standards Track document.

Not to disagree with the WG chair, but it is unclear why this should be on 
standards track. It is protocol information for the community about a 
non-mandatory algorithm that, as far as we can tell, is barely used. 
Because of that, isn't it much better qualified for Informational RFC?

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 23 Feb 2000 14:20:11 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-smime-idea
Sender: [email-masked]

All:

Paul raises some very important points.  Let me share my view as the S/MIME 
Working Group Chair.

1.  We must have an IPR statement for this document to progress to an RFC.

2.  I do not mind some justification text.  Something like: "Organization 
who make already use of IDEA for other applications also want to use IDEA 
in S/MIME."  But, in my opinion, the marketing hype needs to be 
significantly reduced.  The CAST-128 document does not try to convince 
anyone that CAST-128 is appropriate or inappropriate for any particular 
group of users.  The IDEA document should have a similar tone.

3.  I would like this document to become a Standards Track document.  The 
document should state the one and only way that IDEA is used with 
CMS.  Clearly, IDEA will not be mandatory to implement, but if IDEA is 
implemented, then it MUST be done in the manner specified in this 
document.  I cannot recommend that this document become a Standards Track 
RFC until items 1 and 2 are repaired.

Russ

At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote:
>There are a few things in this document that should raise concern.
>
>Appendix C states clearly that this is a patented algorithm for which 
>licensing is available. However, it appears that no one has let the IETF 
>Secretariat know that. Nothing about IDEA is listed on 
><http://www.ietf.org/ipr.html>. This draft should not be considered until 
>there is a formal statement to the IETF.
>
>Parts of the document sounds like a marketing brochure. "Today, IDEA is 
>widely applied in electronic business applications." "Especially for those 
>organization who make already use of IDEA on a wide scale it is of high 
>interest that IDEA is also available in S/MIME." "Experts in cryptography 
>consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on.
>
>These seem particularly inappropriate for an RFC. To be frank, I've never 
>heard of anyone wanting to use IDEA for anything other than old PGP. The 
>folks who wrote PGP had their reasons for choosing IDEA when they did, but 
>they dropped IDEA as a required algorithm for OpenPGP and that doesn't 
>appear to have negatively affected them. The IETF shouldn't codify this 
>kind of marketing hype, even in an Informational RFC. To move forwards 
>with this, it would be nice if the authors went through the draft and took 
>out the marketing fluff.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

Date: Wed, 23 Feb 2000 09:58:46 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: draft-ietf-smime-idea
Sender: [email-masked]

There are a few things in this document that should raise concern.

Appendix C states clearly that this is a patented algorithm for which 
licensing is available. However, it appears that no one has let the IETF 
Secretariat know that. Nothing about IDEA is listed on 
<http://www.ietf.org/ipr.html>. This draft should not be considered until 
there is a formal statement to the IETF.

Parts of the document sounds like a marketing brochure. "Today, IDEA is 
widely applied in electronic business applications." "Especially for those 
organization who make already use of IDEA on a wide scale it is of high 
interest that IDEA is also available in S/MIME." "Experts in cryptography 
consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on.

These seem particularly inappropriate for an RFC. To be frank, I've never 
heard of anyone wanting to use IDEA for anything other than old PGP. The 
folks who wrote PGP had their reasons for choosing IDEA when they did, but 
they dropped IDEA as a required algorithm for OpenPGP and that doesn't 
appear to have negatively affected them. The IETF shouldn't codify this 
kind of marketing hype, even in an Informational RFC. To move forwards with 
this, it would be nice if the authors went through the draft and took out 
the marketing fluff.

--Paul Hoffman, Director
--Internet Mail Consortium

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-idea-02.txt
Date: Wed, 23 Feb 2000 06:23:10 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Incorporation of IDEA Encryption Algorithm in S/MIME
	Author(s)	: S. Teiwes, P. Hartmann, D. Kuenzi
	Filename	: draft-ietf-smime-idea-02.txt
	Pages		: 6
	Date		: 22-Feb-00
	
This memo specifies how to incorporate IDEA (International Data
Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as an 
additional algorithm for symmetric encryption. Today, IDEA is widely 
applied in electronic business applications. But it is not
considered in the specification [SMIME3]. Encryption algorithms are 
part of an organizations' security policy. Typically, organizations
like to have their own preferences in this respect. Therefore, it is 
beneficial to have the choice between different well-known encryption 
algorithms. Especially for those organization who make already use 
of IDEA on a wide scale it is of high interest that IDEA is also 
available in S/MIME. It is the intention of this memo to provide the
OIDs and algorithms required to include IDEA in S/MIME for symmetric
content and key encryption.   
The general functional capabilities and preferences of S/MIME are 
specified by the registered list of S/MIME object identifiers (OIDs). 
This list of OIDs is maintained by the Internet Mail Consortium at 
<http://www.imc.org/ietf-smime/oids.html>. 
The set of S/MIME functions provided by a client is expressed by the 
S/MIME capabilities attribute. This attribute contains a list of OIDs 
of supported cryptographic functions.
This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to:
[email-masked]
with the single word
subscribe
in the body of the message. There is a Web site for the mailing list 
at <http://www.imc.org/ietf-smime/>

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-idea-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-idea-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-idea-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-idea-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "De Clercq, Jan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: S/MIME and disclaimer
Date: Thu, 17 Feb 2000 13:53:52 -0000
Sender: [email-masked]

Is there a way to add a generic disclaimer to S/MIME mail messages after the
message has been encrypted / signed?
This could happen e.g. on the gateway level...
Is there a way to extend multipart MIME messages? 
Is there a way to add scoping to an S/MIME MIME type? Otherwise text added
after the S/MIME operations would invalidate the signature.
Would a disclaimer added after signing be readable on the receiver side?

Tx,

Jan

From: "George Da'Costa" <[email-masked]>
To: <[email-masked]>
Subject: wanted help on fletchers checksum urgently !
Date: Thu, 17 Feb 2000 01:34:37 +0530
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0125_01BF78E7.26CB9D40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hi !!!
well i would be glad if i could get some help on fletchers checksum =
algorithm.
when checking the checksum for ospf lsa header template which bytes of =
the
packet need to be considered
=20
Any help and references are welcome. Thanx in advance.
=20
Regards,
George
=20
=20
=20

------=_NextPart_000_0125_01BF78E7.26CB9D40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>hi !!!<BR>well i would be glad if i =
could get some=20
help on fletchers checksum algorithm.<BR>when checking the checksum for =
ospf lsa=20
header template which bytes of the<BR>packet need to be=20
considered<BR>&nbsp;<BR>Any help and references are welcome. Thanx in=20
advance.<BR>&nbsp;<BR>Regards,<BR>George<BR>&nbsp;<BR>&nbsp;<BR>&nbsp;<BR=
></FONT></DIV></BODY></HTML>

------=_NextPart_000_0125_01BF78E7.26CB9D40--

Date: Wed, 16 Feb 2000 13:07:59 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: E-mail address validation
Sender: [email-masked]

Piers, I certainly agree that the IETF is primarily concerned with protocols, 
and not APIs and even less issues of look and feel.

However, what we are trying to do is to establish an infrastructure for _secure_
communications, and to a very large extent that security is quite literally in 
the eye of the beholder.

To my mind, S/MIME today 'works" but is not "workable", in part because of the 
difficulty in setting up the infrastructure, but in part because of trying to get these kinds
of nuances right.

it could be argued that address verification isn't even necessary -- the user 
could check the certificate whenever it seemed necessary.

But what I really don't want to see is a case where a naive user is tricked into 
accepting a signed message from "President William C. Clinton" ..............<[email-masked]> 
just because [email-masked] had previously been validated in a different context.

So, I believe, the human factors issue is important, and at least as relevant to
this WG as any other standards issue where the word "SHOULD" is used.

Obviously Novell could go off and do its own thing in this space -- the Internet
police aren't going to prevent it if we support an additional user name in a subjectAltName
in the certificate, and choose to display it in GroupWise.  But I'm trying to raise all of the
boats, by making sure that the PKI and S/MIME products not only interoperate, but
actually do something useful, and don't mislead people.

My two cents, anyway.

Bob

>>> "Piers Chivers" <[email-masked]> 02/16/00 03:27AM >>>
Bob,
I thought this group was concerned about protocol whereas what you are
describing is largely human-machine-interface issues.  If we are going to
get into that arena I could argue that all signed receipts should be
displayed as green.  I expect that suggestion would be unacceptable to those
who like red!

Having said that, I think the addressing issues need to be clarified.  We
have the added complication of combining SMIME and X.400 where there are
both P1 and P2 addresses.

I mostly agree with your suggestions below but think they need to be worked
upon to become definitive.  I'm not sure if this WG is the right forum for
that discussion?

The most difficult approach is to educate users that who routed the message
(the envelope addressees) is not necessarily the same as who generated the
content.  Perhaps our UIs should improve to make this distinction more
explicit.

Piers

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On 
Behalf Of Bob Jueneman
Sent: 16 February 2000 00:53
To: [email-masked] 
Subject: E-mail address validation

Paul and Bartley make a good point regarding who the reply should be sent
to.
Although this a second order problem, it still appears to be a problem.

The first issue is what should be displayed as the confirmed
originator/signer
of the message. and I think we are beginning to get a handle on that
problem.

The second issue is one of routing the reply, and here there are so many
differences in the way replies are handled that I'm not even sure I
understand
all of the problems, much less the solutions.

I do know that mail lists frequently mangle the From address, putting the
address
of the mail list in the cc list, etc., etc.

Likewise, people that have multiple accounts for a number of different
reasons
often use a single Reply-To address to consolidate responses.

And if the reply is encrypted, it seems a bit much to ask the sender to
somehow
read my mind as to which processor containing which certificate/key I am
going
to use to decrypt the response.

And finally, if this is a really serious security issue, which I'm not quite
convinced
that it is, what should be done about all of the other To, Cc, and Bcc
addressees?

So let me take a stab at a revised solution that includes both problems,
although this may turn out to be only half-baked.

1.  The UI for a signed message SHOULD display the originator's "real"
common
name, which may be further qualified, if desired.  The originator's RFC822
address
from the certificate should also be displayed, and the DN as well, in that
order of
preference if those fields are all supplied, but it must be recognized that
some
may be missing.

2.  The UI SHOULD attempt to match the originator's RFC822 addr-spec address
from
the certificate to the From address of the message, and SHOULD flag a
mismatch,
but MUST NOT require that the RFC822 name be present in the certificate.

3.  In the event of an encrypted message, including a reply to a From or
Reply-to
address, the To, Cc, and Bcc addresses SHOULD all be matched against the
RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE
WAS SELECTED, and SHOULD flag any mismatch with a warning message.

Does this take care of the problem?  Do we need to say something about
checking the outgoing From or Reply-to addresses in the case of a signed
message
to make sure they conform to the user's certificate?  If so, which
certificate -- the
signing certificate, or the encryption certificate?

Hmm. This gets more and more complicated.

Bob

>>> <[email-masked]> 02/15/00 03:29AM >>>
Just to play Devils advocate...
There is a third address to be considered, the Reply-to. This is a specific
request from the originator of the message to reply to another address. If
it
is present we ought not reply to either of the other 2 addresses.

Regards,

Bartley O'Malley
Citibank NA
Lewisham House
25 Molesworth Street
London
SE13 7EX
England

Tel +44-020-7500-6473
Fax +44-020-7500-8880

-----Original Message-----
From: phoffman [SMTP:[email-masked]] 
Sent: Tuesday, February 15, 2000 12:01 AM
To: ietf-smime
Cc: phoffman
Subject: Re: Problem for public CAs

At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote:
>Instead, in the case of a signed message the From address should be viewed
>as secondary, and the certificate contents the primary information.

 From a security standpoint, this is right. From a UI standpoint, it might
not be. Assume I have a different email address in my cert than in the
From: header of a message I send you, that your S/MIME client has informed
you of that, and you agreed. Now you want to reply to my message. You
probably don't want to reply to the email address in my cert, but you
might. There are essentially two From vales: the certificate one and the
insecure-and-possibly-altered one.

>Of course, we have to face the fact that NEITHER the DN nor the RFC822
address
>may be particularly relevant or informative.

Exactly right.

And, no, I'm not proposing a solution here.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 16 Feb 2000 12:55:52 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: E-mail address validation
Sender: [email-masked]

David, the syntax for subjectAltName already includes directoryName,
so no architectural extension is required.  And multiple subjectAltNames
are also allowed, explicitly, so no extension is required there either.

Now, how many of the existing mail clients support this is a different 
question, as is the issue of how many CAs support it. Probably none, in
fact.

But that's to be expected, especially in a standards group. We are trying to 
decide where we need to go -- if we limit ourselves to existing products and 
procurement questions, the game is already over.

Naturally, I would like to see CIOs change their directory structure to be more 
accommodating to what certificates need in terms of conveying useful information
to relying parties.

The problem is, having observed this phenomenon for nearly 10 years now, I 
haven't seen any movement in that direction at all, and it isn't just
intransigence -- there are copious real reasons why directory schemas are 
what they are, and they aren't terribly likely to change, I'm afraid.

So I'm not trying to reinvent the wheel, just trying to take advantage of the
wheels that already exist.

Your point about message enveloping is quite valid, and tends to make the 
address comparison issue even more complicated.

Bob

>>> "David P. Kemp" <[email-masked]> 02/16/00 08:37AM >>>

> From: "Bob Jueneman" <[email-masked]>
>
>  [...]
> 
> So let me take a stab at a revised solution that includes both problems, 
> although this may turn out to be only half-baked.
> 
> 1.  The UI for a signed message SHOULD display the originator's "real" common 
> name, which may be further qualified, if desired.  The originator's RFC822 address
> from the certificate should also be displayed, and the DN as well, in that order of 
> preference if those fields are all supplied, but it must be recognized that some 
> may be missing.

Bob,

I'm unconvinced that X.509/PKIX/SMIME should define an extension or
GeneralName field to contain a "real" common name.  That would create
more problems than it solves.  Yes, there are unusual directory schemas
out there, including within the DoD, and they have a substantial amount
of inertia.  But if there is a corporate policy determination that the
"real" common name should be contained in PKI certificates, then it
unquestionably would be easier to place it in the CN field of the DN
than to procure CAs, directories, and applications with support for an
as-yet-undefined field or extension.

My stab is that by default the UI should display the Subject CN
(always) and the rfc822 address (if present in the cert), with a way
for the user to display the full Subject DN or the full cert.  If the
CN is a bit cryptic, it's up to the organization's CIO to change the
schema or leave it as is.  Regardless of whether the DN is cryptic or
clear, the address book nickname for that cert will always be displayed.

> 2.  The UI SHOULD attempt to match the originator's RFC822 addr-spec address from
> the certificate to the From address of the message, and SHOULD flag a mismatch,
> but MUST NOT require that the RFC822 name be present in the certificate.
> 
> 3.  In the event of an encrypted message, including a reply to a From or Reply-to 
> address, the To, Cc, and Bcc addresses SHOULD all be matched against the 
> RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE
> WAS SELECTED, and SHOULD flag any mismatch with a warning message.
> 
> Does this take care of the problem?  Do we need to say something about 
> checking the outgoing From or Reply-to addresses in the case of a signed message
> to make sure they conform to the user's certificate?  If so, which certificate -- the 
> signing certificate, or the encryption certificate?
> 
> Hmm. This gets more and more complicated.
> 
> Bob

Don't forget that a single S/MIME message can have multiple nested
encryptedData and signedData layers, and that a single signedData can
have multiple SignerInfos.  Makes the Reply-to, CC, and BCC questions
sound simple :-).

Paul makes a distinction between the "security standpoint" and the
"UI standpoint".  I agree with Paul that from the UI standpoint a cert
address is not the primary source of return address information.  I
don't agree that the "security standpoint" is different - if you want a
secure Reply-to field, then use signed rfc822 headers, not the contents
of the signing cert.

My bank will accept a check with my signature without caring whether it
entered the postal system from my home address, even though the address
is imprinted.  The imprinted address serves to identify me, but doesn't
limit where I can send or receive snail mail.

Date: Wed, 16 Feb 2000 10:37:01 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: E-mail address validation
To: [email-masked]
Content-MD5: RO+Ll7cTaa/hytNUToLY+w==
Sender: [email-masked]

> From: "Bob Jueneman" <[email-masked]>
>
>  [...]
> 
> So let me take a stab at a revised solution that includes both problems, 
> although this may turn out to be only half-baked.
> 
> 1.  The UI for a signed message SHOULD display the originator's "real" common 
> name, which may be further qualified, if desired.  The originator's RFC822 address
> from the certificate should also be displayed, and the DN as well, in that order of 
> preference if those fields are all supplied, but it must be recognized that some 
> may be missing.

Bob,

I'm unconvinced that X.509/PKIX/SMIME should define an extension or
GeneralName field to contain a "real" common name.  That would create
more problems than it solves.  Yes, there are unusual directory schemas
out there, including within the DoD, and they have a substantial amount
of inertia.  But if there is a corporate policy determination that the
"real" common name should be contained in PKI certificates, then it
unquestionably would be easier to place it in the CN field of the DN
than to procure CAs, directories, and applications with support for an
as-yet-undefined field or extension.

My stab is that by default the UI should display the Subject CN
(always) and the rfc822 address (if present in the cert), with a way
for the user to display the full Subject DN or the full cert.  If the
CN is a bit cryptic, it's up to the organization's CIO to change the
schema or leave it as is.  Regardless of whether the DN is cryptic or
clear, the address book nickname for that cert will always be displayed.

> 2.  The UI SHOULD attempt to match the originator's RFC822 addr-spec address from
> the certificate to the From address of the message, and SHOULD flag a mismatch,
> but MUST NOT require that the RFC822 name be present in the certificate.
> 
> 3.  In the event of an encrypted message, including a reply to a From or Reply-to 
> address, the To, Cc, and Bcc addresses SHOULD all be matched against the 
> RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE
> WAS SELECTED, and SHOULD flag any mismatch with a warning message.
> 
> Does this take care of the problem?  Do we need to say something about 
> checking the outgoing From or Reply-to addresses in the case of a signed message
> to make sure they conform to the user's certificate?  If so, which certificate -- the 
> signing certificate, or the encryption certificate?
> 
> Hmm. This gets more and more complicated.
> 
> Bob

Don't forget that a single S/MIME message can have multiple nested
encryptedData and signedData layers, and that a single signedData can
have multiple SignerInfos.  Makes the Reply-to, CC, and BCC questions
sound simple :-).

Paul makes a distinction between the "security standpoint" and the
"UI standpoint".  I agree with Paul that from the UI standpoint a cert
address is not the primary source of return address information.  I
don't agree that the "security standpoint" is different - if you want a
secure Reply-to field, then use signed rfc822 headers, not the contents
of the signing cert.

My bank will accept a check with my signature without caring whether it
entered the postal system from my home address, even though the address
is imprinted.  The imprinted address serves to identify me, but doesn't
limit where I can send or receive snail mail.

Reply-to: [email-masked]
From: "Piers Chivers" <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked]
Subject: RE: E-mail address validation
Date: Wed, 16 Feb 2000 10:27:30 -0000
Importance: Normal
Sender: [email-masked]

Bob,
I thought this group was concerned about protocol whereas what you are
describing is largely human-machine-interface issues.  If we are going to
get into that arena I could argue that all signed receipts should be
displayed as green.  I expect that suggestion would be unacceptable to those
who like red!

Having said that, I think the addressing issues need to be clarified.  We
have the added complication of combining SMIME and X.400 where there are
both P1 and P2 addresses.

I mostly agree with your suggestions below but think they need to be worked
upon to become definitive.  I'm not sure if this WG is the right forum for
that discussion?

The most difficult approach is to educate users that who routed the message
(the envelope addressees) is not necessarily the same as who generated the
content.  Perhaps our UIs should improve to make this distinction more
explicit.

Piers

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Bob Jueneman
Sent: 16 February 2000 00:53
To: [email-masked]
Subject: E-mail address validation

Paul and Bartley make a good point regarding who the reply should be sent
to.
Although this a second order problem, it still appears to be a problem.

The first issue is what should be displayed as the confirmed
originator/signer
of the message. and I think we are beginning to get a handle on that
problem.

The second issue is one of routing the reply, and here there are so many
differences in the way replies are handled that I'm not even sure I
understand
all of the problems, much less the solutions.

I do know that mail lists frequently mangle the From address, putting the
address
of the mail list in the cc list, etc., etc.

Likewise, people that have multiple accounts for a number of different
reasons
often use a single Reply-To address to consolidate responses.

And if the reply is encrypted, it seems a bit much to ask the sender to
somehow
read my mind as to which processor containing which certificate/key I am
going
to use to decrypt the response.

And finally, if this is a really serious security issue, which I'm not quite
convinced
that it is, what should be done about all of the other To, Cc, and Bcc
addressees?

So let me take a stab at a revised solution that includes both problems,
although this may turn out to be only half-baked.

1.  The UI for a signed message SHOULD display the originator's "real"
common
name, which may be further qualified, if desired.  The originator's RFC822
address
from the certificate should also be displayed, and the DN as well, in that
order of
preference if those fields are all supplied, but it must be recognized that
some
may be missing.

2.  The UI SHOULD attempt to match the originator's RFC822 addr-spec address
from
the certificate to the From address of the message, and SHOULD flag a
mismatch,
but MUST NOT require that the RFC822 name be present in the certificate.

3.  In the event of an encrypted message, including a reply to a From or
Reply-to
address, the To, Cc, and Bcc addresses SHOULD all be matched against the
RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE
WAS SELECTED, and SHOULD flag any mismatch with a warning message.

Does this take care of the problem?  Do we need to say something about
checking the outgoing From or Reply-to addresses in the case of a signed
message
to make sure they conform to the user's certificate?  If so, which
certificate -- the
signing certificate, or the encryption certificate?

Hmm. This gets more and more complicated.

Bob

>>> <[email-masked]> 02/15/00 03:29AM >>>
Just to play Devils advocate...
There is a third address to be considered, the Reply-to. This is a specific
request from the originator of the message to reply to another address. If
it
is present we ought not reply to either of the other 2 addresses.

Regards,

Bartley O'Malley
Citibank NA
Lewisham House
25 Molesworth Street
London
SE13 7EX
England

Tel +44-020-7500-6473
Fax +44-020-7500-8880

-----Original Message-----
From: phoffman [SMTP:[email-masked]]
Sent: Tuesday, February 15, 2000 12:01 AM
To: ietf-smime
Cc: phoffman
Subject: Re: Problem for public CAs

At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote:
>Instead, in the case of a signed message the From address should be viewed
>as secondary, and the certificate contents the primary information.

 From a security standpoint, this is right. From a UI standpoint, it might
not be. Assume I have a different email address in my cert than in the
From: header of a message I send you, that your S/MIME client has informed
you of that, and you agreed. Now you want to reply to my message. You
probably don't want to reply to the email address in my cert, but you
might. There are essentially two From vales: the certificate one and the
insecure-and-possibly-altered one.

>Of course, we have to face the fact that NEITHER the DN nor the RFC822
address
>may be particularly relevant or informative.

Exactly right.

And, no, I'm not proposing a solution here.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 15 Feb 2000 17:53:27 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Subject: E-mail address validation
Sender: [email-masked]

Paul and Bartley make a good point regarding who the reply should be sent to.
Although this a second order problem, it still appears to be a problem.

The first issue is what should be displayed as the confirmed originator/signer
of the message. and I think we are beginning to get a handle on that problem.

The second issue is one of routing the reply, and here there are so many 
differences in the way replies are handled that I'm not even sure I understand 
all of the problems, much less the solutions.

I do know that mail lists frequently mangle the From address, putting the address 
of the mail list in the cc list, etc., etc. 

Likewise, people that have multiple accounts for a number of different reasons
often use a single Reply-To address to consolidate responses.

And if the reply is encrypted, it seems a bit much to ask the sender to somehow 
read my mind as to which processor containing which certificate/key I am going 
to use to decrypt the response.

And finally, if this is a really serious security issue, which I'm not quite convinced 
that it is, what should be done about all of the other To, Cc, and Bcc addressees?

So let me take a stab at a revised solution that includes both problems, 
although this may turn out to be only half-baked.

1.  The UI for a signed message SHOULD display the originator's "real" common 
name, which may be further qualified, if desired.  The originator's RFC822 address
from the certificate should also be displayed, and the DN as well, in that order of 
preference if those fields are all supplied, but it must be recognized that some 
may be missing.

2.  The UI SHOULD attempt to match the originator's RFC822 addr-spec address from
the certificate to the From address of the message, and SHOULD flag a mismatch,
but MUST NOT require that the RFC822 name be present in the certificate.

3.  In the event of an encrypted message, including a reply to a From or Reply-to 
address, the To, Cc, and Bcc addresses SHOULD all be matched against the 
RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE
WAS SELECTED, and SHOULD flag any mismatch with a warning message.

Does this take care of the problem?  Do we need to say something about 
checking the outgoing From or Reply-to addresses in the case of a signed message
to make sure they conform to the user's certificate?  If so, which certificate -- the 
signing certificate, or the encryption certificate?

Hmm. This gets more and more complicated.

Bob

>>> <[email-masked]> 02/15/00 03:29AM >>>
Just to play Devils advocate...
There is a third address to be considered, the Reply-to. This is a specific 
request from the originator of the message to reply to another address. If it 
is present we ought not reply to either of the other 2 addresses.

Regards,

Bartley O'Malley
Citibank NA
Lewisham House
25 Molesworth Street
London
SE13 7EX
England

Tel +44-020-7500-6473
Fax +44-020-7500-8880

-----Original Message-----
From: phoffman [SMTP:[email-masked]] 
Sent: Tuesday, February 15, 2000 12:01 AM
To: ietf-smime
Cc: phoffman
Subject: Re: Problem for public CAs

At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote:
>Instead, in the case of a signed message the From address should be viewed
>as secondary, and the certificate contents the primary information.

 From a security standpoint, this is right. From a UI standpoint, it might 
not be. Assume I have a different email address in my cert than in the 
From: header of a message I send you, that your S/MIME client has informed 
you of that, and you agreed. Now you want to reply to my message. You 
probably don't want to reply to the email address in my cert, but you 
might. There are essentially two From vales: the certificate one and the 
insecure-and-possibly-altered one.

>Of course, we have to face the fact that NEITHER the DN nor the RFC822 address
>may be particularly relevant or informative.

Exactly right.

And, no, I'm not proposing a solution here.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
Date: Tue, 15 Feb 2000 10:29:11 +0000
Subject: RE: Re: Problem for public CAs
TO: [email-masked]
Sender: [email-masked]

--openmail-part-10d68c22-00000001
Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT"
Content-Disposition: inline; filename="BDY.TXT"
Content-Transfer-Encoding: 7bit

Just to play Devils advocate...
There is a third address to be considered, the Reply-to. This is a specific 
request from the originator of the message to reply to another address. If it 
is present we ought not reply to either of the other 2 addresses.

Regards,

Bartley O'Malley
Citibank NA
Lewisham House
25 Molesworth Street
London
SE13 7EX
England

Tel +44-020-7500-6473
Fax +44-020-7500-8880

-----Original Message-----
From: phoffman [SMTP:[email-masked]]
Sent: Tuesday, February 15, 2000 12:01 AM
To: ietf-smime
Cc: phoffman
Subject: Re: Problem for public CAs

At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote:
>Instead, in the case of a signed message the From address should be viewed
>as secondary, and the certificate contents the primary information.

 From a security standpoint, this is right. From a UI standpoint, it might 
not be. Assume I have a different email address in my cert than in the 
From: header of a message I send you, that your S/MIME client has informed 
you of that, and you agreed. Now you want to reply to my message. You 
probably don't want to reply to the email address in my cert, but you 
might. There are essentially two From vales: the certificate one and the 
insecure-and-possibly-altered one.

>Of course, we have to face the fact that NEITHER the DN nor the RFC822 address
>may be particularly relevant or informative.

Exactly right.

And, no, I'm not proposing a solution here.

--Paul Hoffman, Director
--Internet Mail Consortium

--openmail-part-10d68c22-00000001
Content-Type: application/ms-tnef; name="WINMAIL.DAT"
Content-Disposition: attachment; filename="WINMAIL.DAT"
Content-Transfer-Encoding: base64

--openmail-part-10d68c22-00000001--

Date: Mon, 14 Feb 2000 16:01:05 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Problem for public CAs
Sender: [email-masked]

At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote:
>Instead, in the case of a signed message the From address should be viewed
>as secondary, and the certificate contents the primary information.

 From a security standpoint, this is right. From a UI standpoint, it might 
not be. Assume I have a different email address in my cert than in the 
From: header of a message I send you, that your S/MIME client has informed 
you of that, and you agreed. Now you want to reply to my message. You 
probably don't want to reply to the email address in my cert, but you 
might. There are essentially two From vales: the certificate one and the 
insecure-and-possibly-altered one.

>Of course, we have to face the fact that NEITHER the DN nor the RFC822 address
>may be particularly relevant or informative.

Exactly right.

And, no, I'm not proposing a solution here.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 14 Feb 2000 16:10:05 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Problem for public CAs
Sender: [email-masked]

This has been a fascinating discussion, in part because 
of the multi-dimensional aspects to the problem.

Let me see if I can summarize some of the different points of 
view:

The first issue raised was one of privacy, and in particular
the possibility of spam.  This reminds me of two lessons
I learned so time ago, rather forcefully, with regard to this space.

Back in the PEM days, I was concentrating on the question
of how to ensure the legal sufficiency of a digital signature
to assure nonrepudiation, and I was suggesting that full
name, verified address, and perhaps social security number
or driver's license number be included in the certificate.
John Gilmore brought me up short by pointing out that
we were supposed to be talking about privacy ENHANCED 
mail. Point taken -- some of this stuff needs to be optional.

Then a few years later, I was trying to solve the problem of 
uniquely identifying someone in a directory, given the presumption
at the time that multiple directory service providers (e.g., telcos) 
might exist and might have overlapping geopolitical boundaries.

The answer to this problem, it seemed to me, was to include 
sufficient disambiguating information, such as street address,
assuming that there wouldn't be two people with the same name 
in the same household. Sharon Boyen gave me another much
needed lesson in political correctness by pointing out that many
women, in particular, weren't about to list their residence address
in a public directory, and many wouldn't even list their given names,
preferring to be listed as "M. Smith". Point taken again. If necessary,
include meaningless qualifiers such as employeeID for uniqueness.

So these are legitimate issues, and I suppose that spam mail is 
the virtual equivalent of stalking.

So I accept the position that says that an e-mail address should 
not be required, either in the DN or the subjectAltName, although it may
be desirable.

This bears on the second issue, which I raised at the November 
meeting, where I pointed out that it was all too easy to manipulate
the From address in an e-mail so that the addr-spec portion would match
the e-mail address in the certificate, and yet the user-friendly portion of 
the name could be completely bogus and seriously misleading.

I now think that I agree with David Kemp -- this is primarily a man/machine
interface issue.

In other words, the conventional paradigm of presenting the From address
as the primary identification of the sender is WRONG in the case of a digitally 
signed message, and especially so considering how easily it can be forged
or manipulated.

Instead, in the case of a signed message the From address should be viewed 
as secondary, and the certificate contents the primary information.  The 
"contents": in this case should probably include the DN and the subjectAltName,
even if it takes an additional line of the GUI display.

Of course, we have to face the fact that NEITHER the DN nor the RFC822 address
may be particularly relevant or informative.

In the case of the DN, at least from the perspective of someone who works 
for a directory company, the DN is probably going to be whatever it is
today, not withstanding the fact that directories today are primary set up
for the convenience of the system administrator, and secondly for the benefit
of users within the organization, and thirdly if at all for the benefit of users
outside of the organization. In my case, for example, my directory name
is bjueneman.nsrd.prv.novell (note the "backwards" presentation order), or 
o=Novell, ou=prv, ou=nsrd, cn=bjueneman.  Hardly very helpful to someone 
on the outside, and certainly not what I would like, but unlikely to change 
any time soon.  Of course, [email-masked] isn't very helpful either, but
better than [email-masked].

(Public CAs may not have this problem, as they would tend to put "meaningful"
names in a directory.)

So the ugly fact of the matter is that both DNs and RFC822 names are
really the result of legacy systems, and are unlikely to change or to be 
very helpful. So neither is really satisfactory.

My preferred solution?  Use an _additional_ subjectAltName to convey the
person's "real" name, suitably qualified if desired. And leave the directory
DN to the directory administrators, and the RFC822 name to e-mail 
administrators. Render unto Caesar ....

Then in the message display, present the subjectAltName containing a 
commonName format as primary (if present), the RFC822 address as 
secondary (if present), and the DN as supplemental information (if present).
IN order to assure at least some semblance of uniqueness, either the 
RFC822 name or the DN MUST be present, and the "real" commonName
SHOULD be present.

The banner portion of a signed message from me would then be properly 
displayed as:

Signer: Robert R. (Bob) Jueneman [[email-masked]] 
           [o=Novell, ou=prv, ou=nsrd, cn=bjueneman]

The From address, i.e., what the RFC822 From address itself was, would 
not normally be displayed, except by viewing the message in RFC822 format.

I believe that the combination of these three different name forms will be sufficient 
to adequately disambiguate the sender of a message, and to prevent all sorts 
of mischief and possible accidents.

If this is the display format, I don't care that much about what the name matching 
rules are, or even whether name matching is done at all.  So far, name matching 
seems to be causing more problems than it solves.

Comments?

Bob

From: "Pawling, John" <[email-masked]>
To: "'SMIME WG'" <[email-masked]>
Subject: v1.5 SFL Re-Delivered
Date: Mon, 14 Feb 2000 16:42:40 -0500
Sender: [email-masked]

All,

We made a mistake when we constructed the smR15CTI.zip file described in the
enclosed message.  We omitted the CTIL source code.  We have re-built,
checked and re-delivered a corrected smR15CTI.zip file which is now stored
on the Fortezza Developer's S/MIME Page
<http://www.armadillo.huntsville.al.us/software/smime>.  We also fixed
memory leaks in the SFL code that we uncovered during Solaris 2.7 memory
leak testing late last week.  The memory leak fixes are included in a new
smimeR15.zip file also stored on the Fortezza Developer's S/MIME Page.
Anybody who downloaded the smR15CTI.zip and smimeR15.zip files prior to the
afternoon of 14 February should re-download the new zip files currently
stored on the Fortezza Developer's SFL Web Page.  We sincerely apologize for
any inconvenience caused by this mistake.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
[email-masked]
============================================ 

Original message:
=====================================================================
All,

J.G. Van Dyke and Associates (VDA), a Wang Government Services Company, has 
delivered Version 1.5 of the S/MIME Freeware Library (SFL) source code and 
Application Programming Interface (API).  The SFL source code files are 
freely available to everyone from the Fortezza Developer's S/MIME Page
<http://www.armadillo.huntsville.al.us/software/smime> (with no password 
control).  On 14 January 2000, the U.S. Department of Commerce, Bureau of 
Export Administration published a new regulation implementing an update to
the U.S. Government's encryption export policy 
<http://www.bxa.doc.gov/Encryption/Default.htm>.  In accordance with the 
revisions to the Export Administration Regulations (EAR) of 14 Jan 2000,
the downloading of the SFL source code is no longer password controlled.

The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message 
Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. 
It also implements portions of the RFC 2633 Message Specification and 
RFC 2632 Certificate Handling document.  When used in conjunction with
the Crypto++ freeware library, the SFL implements the RFC 2631 
Diffie-Hellman (D-H) Key Agreement Method specification.  It has been 
successfully tested using the MS Windows NT/95/98 and Solaris 2.7 operating 
systems.  Further enhancements, ports and testing of the SFL are still in 
process.  Further releases of the SFL will be provided as significant 
capabilities are added. 

The SFL has been successfully used to sign, verify, encrypt and decrypt
CMS/ESS 
objects using: S/MIME v3 mandatory-to-implement algorithms (DSA, E-S D-H,
3DES) 
provided by the Crypto++ 3.1 library; RSA suite of algorithms provided by
the 
RSA BSAFE v4.2 and Crypto++ 3.1 libraries; and Fortezza suite of algorithms 
provided by the Fortezza Crypto Card.  The SFL uses the VDA-enhanced SNACC
v1.3 
ASN.1 Library to encode/decode objects. The v1.5 SFL release includes: SFL
High-
level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL);

BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL (still being tested);
VDA-
enhanced GNU SNACC v1.3 rev 0.07 ASN.1 Compiler and Library; test utilities;

test drivers and test data.  All CTILs were tested as Dynamically Linked 
Libraries (DLL) using MS Windows.  The Fortezza, BSAFE and Crypto++ CTILs
were
tested with the respective security libraries as shared objects using
Solaris 2.7.  

The SFL has been successfully used to exchange signedData and envelopedData 
messages with the Microsoft (MS) Internet Explorer Outlook Express v4.01 and

Netscape Communicator 4.X S/MIME v2 products.  Signed messages have been 
exchanged with the RSA S/MAIL, WorldTalk and Entrust S/MIME v2 products. 

The SFL has also been used to perform S/MIME v3 interoperability testing
with 
Microsoft that exercised the majority of the features specified by RFCs
2630, 
2631 and 2634.  This testing included the RSA, mandatory S/MIME V3 and
Fortezza 
suites of algorithms.  We have also performed limited S/MIME v3 testing with

Baltimore and Entrust.  We are also participating in the IETF S/MIME WG 
interoperability testing documented in the "Examples of S/MIME Messages" 
document.  We have used the SFL to successfully process all of the correct 
signedData and envelopedData messages included in the document.  We are 
continuing to set up test config files to use the SFL to test the other
cases 
included in the document such as signed receipts.  We also plan to provide 
sample messages for inclusion in the document.

The following enhancements are included in the v1.5 SFL release (compared
with 
the v1.4 release):

1) SNACC: Fixed ASN.1 INTEGER bug in which one-byte values were improperly 
processed. 

2) Fixed many memory leaks;

3) Full CounterSignature test suite (autohiAllSFLd.cfg);

4) CertificateBuilder utility generates private/public key pairs and 
certificates (there is a "README.txt" file in the root directory regarding
this 
utility). 

5) PKCS #11 CTIL project (SFL integrators need to separately obtain a PKCS
#11 
crypto library, but this project provides a good template for PKCS #11).  We

are still testing the PKCS #11 CTIL.

6) Developed new test code and configuration files to implement test cases;
and

7) Performed regression testing to ensure that aforementioned enhancements
did 
not break existing SFL functionality.

We are still in the process of enhancing and testing the SFL.  Future
releases 
will include: completion of PKCS #11 CTIL testing; SPEX/ CTIL 
encrypt/decrypt/ESDH capabilities; finish CertificateBuilder command line 
utility; modify PKCS #12 code in test utilities to provide interoperable key

storage; add "Certificate Management Messages over CMS" ASN.1 encode/decode 
functions; add enhanced test routines; bug fixes; support for other crypto
APIs 
(possible); and support for other operating systems. 

The SFL is developed to maximize portability to 32-bit operating 
systems.  In addition to testing on MS Windows and Solaris 2.7, we plan to
port 
the SFL to the following operating systems: Linux, HP/UX 11, IBM AIX 3.2 
(possibly), SCO 5.0 (possibly) and Macintosh (possibly).

The following SFL files are available from the Fortezza Developer's S/MIME
Page:

1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL API, 
Software Test Description, Implementers Guide, Overview Briefing and Public 
License.
     
2) snacc1_5VDA.zip: Zip file containing SNACC v1.3 rev 0.07 ASN.1 Compiler
and 
Library source code compilable for Unix and MS Windows NT/95/98 that has
been 
enhanced by VDA to implement the Distinguished Encoding Rules.  Project
files 
and makefiles are included.  This file includes a sample test project 
demonstrating the use of the SNACC classes.

3) smimeR15.zip:  Zip file containing all SFL source code including: 
SFL Hi-Level source code; VDA-enhanced SNACC-generated ASN.1 source 
code; project files.  This file also contains test driver source code, 
sample CMS/ESS test data and test X.509 Certificates.  This file also 
includes test utilities to create X.509 Certificates that each include 
a D-H, DSA or RSA public key.  SNACC release and debug libraries
are compiled for MS Windows NT/95/98. MS Windows NT/95/98
project files and Unix makefiles are included for the SNACC code and
Crypto++.    

4) smR15CTI.zip:  Source code for the following CTILs: Test (no crypto), 
Crypto++, BSAFE, Fortezza, SPEX/ and PKCS #11.  The Win95/98/NT projects are

also included.  (NOTE: The Free (a.k.a. Crypto++) CTIL includes
VDA-developed 
source code to use the RSA public key algorithm implemented within the
external 
Crypto++ library.  As with all of the external crypto token libraries, the 
Crypto++ library is not distributed as part of the SFL source code.  
To use the Crypto++ library with the SFL, the application developer must 
independently obtain the Crypto++ library from the Crypto++ Web Page 
<http://www.eskimo.com/~weidai/cryptlib.html> and then compile it with 
the VDA-developed Crypto++ CTIL source code.  The RSA public key 
algorithm is covered by U.S. Patent 4,405,829 "Cryptographic Communication 
System and Method".  Within the U.S., users of the RSA public key algorithm 
provided by the external Crypto++ library must obtain a license from RSA 
granting them permission to use the RSA algorithm.)

5) csmime.mdl contains SFL Class diagrams created using Microsoft 
Visual Modeler (comes with MS Visual Studio 6.0, Enterprise Tools).
The file can also be viewed using Rational Rose C++ Demo 4.0
45 day evaluation copy which can be obtained from
<http://www.rational.com/uml/resources/practice_uml/index.jtmpl>.
Not all classes are documented in the MDL file at this time.

All source code for the SFL is being provided at no cost and with no 
financial limitations regarding its use and distribution. 
Organizations can use the SFL without paying any royalties or 
licensing fees.  VDA is developing the SFL under contract to the U.S. 
Government.  The U.S. Government is furnishing the SFL source code at no 
cost to the vendor subject to the conditions of the "SFL Public 
License" available from the VDA SFL Page and Fortezza Developer's 
S/MIME Page.

The SFL is composed of a high-level library that performs generic CMS 
and ESS processing independent of the crypto algorithms used to 
protect a specific object.  The SFL high-level library makes calls to 
an algorithm-independent CTIL API.  The underlying, external crypto
token libraries are not distributed as part of the SFL 
source code. The application developer must independently obtain these 
libraries and then link them with the SFL.  For example, the SFL uses 
the freeware Crypto++ library to obtain 3DES, D-H and DSA.  To use 
the SFL with Crypto++ the vendor must download the Crypto++ freeware 
library from the Crypto++ Web Page and then compile it with the  
VDA-developed Crypto++ CTIL source code.  

The Internet Mail Consortium (IMC) has established an SFL web page
<http://www.imc.org/imc-sfl>.  The IMC has also established an SFL
mail list which is used to: distribute information regarding SFL
releases; discuss SFL-related issues; and provide a means for SFL
users to provide feedback, comments, bug reports, etc.  Subscription
information for the imc-sfl mailing list is at the IMC web site
listed above.

The SFL documents and VDA-enhanced SNACC source code are also
available from the VDA SFL Web Page
<http://www.jgvandyke.com/services/infosec/sfl.htm>.

All comments regarding the SFL source code and documents are welcome. 
We recommend that comments should be sent to the imc-sfl mail list.  
We will respond to all messages on that list.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
[email-masked]
============================================ 

From: "John Biccum (Data Processing Resources Corp)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "Larry Talbot (Excell Data Corporation)" <[email-masked]>
Subject: cryptographic accelerators 
Date: Fri, 11 Feb 2000 09:15:54 -0800
Sender: [email-masked]

Does anyone on the list have any experience using hardware cryptographic
accelerators such as the Atalla or nCipher devices to generate asymmetrical
key pairs?  Cryptographic hardware seems close enough to an off-topic
subject that I'd prefer off-list replies.

From: "Pawling, John" <[email-masked]>
To: "'SMIME WG'" <[email-masked]>
Subject: v1.5 SFL Freely Available to All!!
Date: Thu, 10 Feb 2000 12:07:33 -0500
Sender: [email-masked]

All,

J.G. Van Dyke and Associates (VDA), a Wang Government Services Company, has 
delivered Version 1.5 of the S/MIME Freeware Library (SFL) source code and 
Application Programming Interface (API).  The SFL source code files are 
freely available to everyone from the Fortezza Developer's S/MIME Page
<http://www.armadillo.huntsville.al.us/software/smime> (with no password 
control).  On 14 January 2000, the U.S. Department of Commerce, Bureau of 
Export Administration published a new regulation implementing an update to
the U.S. Government's encryption export policy 
<http://www.bxa.doc.gov/Encryption/Default.htm>.  In accordance with the 
revisions to the Export Administration Regulations (EAR) of 14 Jan 2000,
the downloading of the SFL source code is no longer password controlled.

The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message 
Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. 
It also implements portions of the RFC 2633 Message Specification and 
RFC 2632 Certificate Handling document.  When used in conjunction with
the Crypto++ freeware library, the SFL implements the RFC 2631 
Diffie-Hellman (D-H) Key Agreement Method specification.  It has been 
successfully tested using the MS Windows NT/95/98 and Solaris 2.7 operating 
systems.  Further enhancements, ports and testing of the SFL are still in 
process.  Further releases of the SFL will be provided as significant 
capabilities are added. 

The SFL has been successfully used to sign, verify, encrypt and decrypt
CMS/ESS 
objects using: S/MIME v3 mandatory-to-implement algorithms (DSA, E-S D-H,
3DES) 
provided by the Crypto++ 3.1 library; RSA suite of algorithms provided by
the 
RSA BSAFE v4.2 and Crypto++ 3.1 libraries; and Fortezza suite of algorithms 
provided by the Fortezza Crypto Card.  The SFL uses the VDA-enhanced SNACC
v1.3 
ASN.1 Library to encode/decode objects. The v1.5 SFL release includes: SFL
High-
level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL);

BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL (still being tested);
VDA-
enhanced GNU SNACC v1.3 rev 0.07 ASN.1 Compiler and Library; test utilities;

test drivers and test data.  All CTILs were tested as Dynamically Linked 
Libraries (DLL) using MS Windows.  The Fortezza, BSAFE and Crypto++ CTILs
were
tested with the respective security libraries as shared objects using
Solaris 2.7.  

The SFL has been successfully used to exchange signedData and envelopedData 
messages with the Microsoft (MS) Internet Explorer Outlook Express v4.01 and

Netscape Communicator 4.X S/MIME v2 products.  Signed messages have been 
exchanged with the RSA S/MAIL, WorldTalk and Entrust S/MIME v2 products. 

The SFL has also been used to perform S/MIME v3 interoperability testing
with 
Microsoft that exercised the majority of the features specified by RFCs
2630, 
2631 and 2634.  This testing included the RSA, mandatory S/MIME V3 and
Fortezza 
suites of algorithms.  We have also performed limited S/MIME v3 testing with

Baltimore and Entrust.  We are also participating in the IETF S/MIME WG 
interoperability testing documented in the "Examples of S/MIME Messages" 
document.  We have used the SFL to successfully process all of the correct 
signedData and envelopedData messages included in the document.  We are 
continuing to set up test config files to use the SFL to test the other
cases 
included in the document such as signed receipts.  We also plan to provide 
sample messages for inclusion in the document.

The following enhancements are included in the v1.5 SFL release (compared
with 
the v1.4 release):

1) SNACC: Fixed ASN.1 INTEGER bug in which one-byte values were improperly 
processed. 

2) Fixed many memory leaks;

3) Full CounterSignature test suite (autohiAllSFLd.cfg);

4) CertificateBuilder utility generates private/public key pairs and 
certificates (there is a "README.txt" file in the root directory regarding
this 
utility). 

5) PKCS #11 CTIL project (SFL integrators need to separately obtain a PKCS
#11 
crypto library, but this project provides a good template for PKCS #11).  We

are still testing the PKCS #11 CTIL.

6) Developed new test code and configuration files to implement test cases;
and

7) Performed regression testing to ensure that aforementioned enhancements
did 
not break existing SFL functionality.

We are still in the process of enhancing and testing the SFL.  Future
releases 
will include: completion of PKCS #11 CTIL testing; SPEX/ CTIL 
encrypt/decrypt/ESDH capabilities; finish CertificateBuilder command line 
utility; modify PKCS #12 code in test utilities to provide interoperable key

storage; add "Certificate Management Messages over CMS" ASN.1 encode/decode 
functions; add enhanced test routines; bug fixes; support for other crypto
APIs 
(possible); and support for other operating systems. 

The SFL is developed to maximize portability to 32-bit operating 
systems.  In addition to testing on MS Windows and Solaris 2.7, we plan to
port 
the SFL to the following operating systems: Linux, HP/UX 11, IBM AIX 3.2 
(possibly), SCO 5.0 (possibly) and Macintosh (possibly).

The following SFL files are available from the Fortezza Developer's S/MIME
Page:

1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL API, 
Software Test Description, Implementers Guide, Overview Briefing and Public 
License.
     
2) snacc1_5VDA.zip: Zip file containing SNACC v1.3 rev 0.07 ASN.1 Compiler
and 
Library source code compilable for Unix and MS Windows NT/95/98 that has
been 
enhanced by VDA to implement the Distinguished Encoding Rules.  Project
files 
and makefiles are included.  This file includes a sample test project 
demonstrating the use of the SNACC classes.

3) smimeR15.zip:  Zip file containing all SFL source code including: 
SFL Hi-Level source code; VDA-enhanced SNACC-generated ASN.1 source 
code; project files.  This file also contains test driver source code, 
sample CMS/ESS test data and test X.509 Certificates.  This file also 
includes test utilities to create X.509 Certificates that each include 
a D-H, DSA or RSA public key.  SNACC release and debug libraries
are compiled for MS Windows NT/95/98. MS Windows NT/95/98
project files and Unix makefiles are included for the SNACC code and
Crypto++.    

4) smR15CTI.zip:  Source code for the following CTILs: Test (no crypto), 
Crypto++, BSAFE, Fortezza, SPEX/ and PKCS #11.  The Win95/98/NT projects are

also included.  (NOTE: The Free (a.k.a. Crypto++) CTIL includes
VDA-developed 
source code to use the RSA public key algorithm implemented within the
external 
Crypto++ library.  As with all of the external crypto token libraries, the 
Crypto++ library is not distributed as part of the SFL source code.  
To use the Crypto++ library with the SFL, the application developer must 
independently obtain the Crypto++ library from the Crypto++ Web Page 
<http://www.eskimo.com/~weidai/cryptlib.html> and then compile it with 
the VDA-developed Crypto++ CTIL source code.  The RSA public key 
algorithm is covered by U.S. Patent 4,405,829 "Cryptographic Communication 
System and Method".  Within the U.S., users of the RSA public key algorithm 
provided by the external Crypto++ library must obtain a license from RSA 
granting them permission to use the RSA algorithm.)

5) csmime.mdl contains SFL Class diagrams created using Microsoft 
Visual Modeler (comes with MS Visual Studio 6.0, Enterprise Tools).
The file can also be viewed using Rational Rose C++ Demo 4.0
45 day evaluation copy which can be obtained from
<http://www.rational.com/uml/resources/practice_uml/index.jtmpl>.
Not all classes are documented in the MDL file at this time.

All source code for the SFL is being provided at no cost and with no 
financial limitations regarding its use and distribution. 
Organizations can use the SFL without paying any royalties or 
licensing fees.  VDA is developing the SFL under contract to the U.S. 
Government.  The U.S. Government is furnishing the SFL source code at no 
cost to the vendor subject to the conditions of the "SFL Public 
License" available from the VDA SFL Page and Fortezza Developer's 
S/MIME Page.

The SFL is composed of a high-level library that performs generic CMS 
and ESS processing independent of the crypto algorithms used to 
protect a specific object.  The SFL high-level library makes calls to 
an algorithm-independent CTIL API.  The underlying, external crypto
token libraries are not distributed as part of the SFL 
source code. The application developer must independently obtain these 
libraries and then link them with the SFL.  For example, the SFL uses 
the freeware Crypto++ library to obtain 3DES, D-H and DSA.  To use 
the SFL with Crypto++ the vendor must download the Crypto++ freeware 
library from the Crypto++ Web Page and then compile it with the  
VDA-developed Crypto++ CTIL source code.  

The Internet Mail Consortium (IMC) has established an SFL web page
<http://www.imc.org/imc-sfl>.  The IMC has also established an SFL
mail list which is used to: distribute information regarding SFL
releases; discuss SFL-related issues; and provide a means for SFL
users to provide feedback, comments, bug reports, etc.  Subscription
information for the imc-sfl mailing list is at the IMC web site
listed above.

The SFL documents and VDA-enhanced SNACC source code are also
available from the VDA SFL Web Page
<http://www.jgvandyke.com/services/infosec/sfl.htm>.

All comments regarding the SFL source code and documents are welcome. 
We recommend that comments should be sent to the imc-sfl mail list.  
We will respond to all messages on that list.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
[email-masked]
============================================ 

Date: Thu, 10 Feb 2000 12:02:43 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Problem for public CAs 
To: [email-masked]
Content-MD5: DMUoRIEvVpj0qCoQTAZrzw==
Sender: [email-masked]

RFC 2632 is fairly clear on the requirements for email addresses:

   3. Using Distinguished Names for Internet Mail

   End-entity certificates MAY contain an Internet mail address as
   described in [RFC-822]. The address must be an "addr-spec" as defined
   in Section 6.1 of that specification.  The email address SHOULD be in
   the subjectAltName extension, and SHOULD NOT be in the subject
   distinguished name.

   Receiving agents MUST recognize email addresses in the subjectAltName
   field. Receiving agents MUST recognize email addresses in the
   Distinguished Name field in the PKCS #9 emailAddress attribute.

   Sending agents SHOULD make the address in the From or Sender header
   in a mail message match an Internet mail address in the signer's
   certificate. Receiving agents MUST check that the address in the From
   or Sender header of a mail message matches an Internet mail address
   in the signer's certificate, if mail addresses are present in the
   certificate. A receiving agent SHOULD provide some explicit alternate
   processing of the message if this comparison fails, which may be to
   display a message that shows the recipient the addresses in the
   certificate or other certificate details.

It should be obvious, but apparently is not, that "Sending and receiving
agents MUST accept certificates that do not contain an email address
in either the subject distinguished name or the subjectAltName extension."

For the son of RFC 2632, I propose:

  1) appending a sentence to that effect to the first paragraph
     of section 3.
  
  2) changing the last sentence of the third paragraph from SHOULD to MUST:
     "A receiving agent MUST provide some explicit alternate processing ..."

Individual communities of interest will profile whether their CAs
populate the subjectAltName extension, based on their judgement of
whether it is a benefit or an operational headache and security risk.
I just want to ensure that community-specific CAs have that choice, and
are not forced to populate the extension by a proliferation of
non-compliant user agents.

To: "David P. Kemp" <[email-masked]>
cc: [email-masked]
Subject: Re: Problem for public CAs 
Date: Thu, 10 Feb 2000 12:45:17 +1000
From: Dean Povey <[email-masked]>
Sender: [email-masked]

<snip>

>
>If the message you received from "js" is an S/MIME message, only one
>cert will validate the signature or decrypt the body, so you know
>which DN is correct.

Yes, but you still don't know if that was the correct DN for the email 
address.  You have to guess that the DN "matches" the email address, 
unless you have some other information.

>How does the person who owns [email-masked] get involved in the first place?
>
>If a hacker sends you an S/MIME message with the hacker's cert,
>you can reply to it "securely" (with a message the hacker can decode).
>What motivation is there for the hacker to cause the reply to be
>delivered to "[email-masked]" where, presumably, the hacker can't get
>it and the "real" js can't decrypt it?

Because the hacker can get you to reveal some information that you might
reveal to js but not to the hacker.  I can think of scenarios where this 
might happen, for example you come to trust someone on a mailing list, but 
you only associate them with their email address and common name.  The 
hacker learns this and uses this to socially engineer you via email to 
send him/her some information.  You figure, okay well it's encrypted so 
I'm safe, and the DN kind of looks okay, so I'll send it.

>You bootstrap an electronic identity by what you say.  If I send out
>signed S/MIME messages all of which can be verified by the same cert,
>it doesn't matter whether some of them come from a home rfc822 address
>and others come from a work rfc822 address.  If I want them linked to
>the same persona I'll use the same cert.  It also doesn't matter
>whether the DN is a name with physical significance or a 'nym.  All that
>matters is that the messages come from the possessor of one private key.
>If you have a collection of S/MIME messages with two different certs,
>with similar or even identical DNs:
>
> C=AU, OU=Accounting, O=ACME, CN=John Smith  (issuer A, public key X)
> C=AU, OU=Accounting, O=ACME, CN=John Smith  (issuer B, public key Y)
>
>you will have enough context to label one address book entry "John Smith"
>and the other one "John the flaming idiot".

Sure, that is nice in theory, but if there is nothing meaningful in the
Certificate to associate with the possessor of the private key then what
have you gained? All you know is: a) The person who sent you email message
has a private key; and b) That some third party has verified that the
person that sent you the email possesses the private key.  The email
address could be forged and the DN might be meaningless.  Now what you are
saying is that you associate this DN locally with your address book,
mapping the meaningless DN back to a name/context you understand. Therefore
you have verified by some out-of-band mechanism that you can associate the
public key with a person/entity you know about (via the indirect route of
associating them with the meaninglyess DN).  So in effect you have negated
the need for a third-party certificate in the first place as you have
already obtained all the information you needed OOB. Therefore this negates
the need to publish the certificate in a public repository, and hence the
reason for leaving it out in the first place.

Your argument seems to predicated on the basis that I know the people 
personally with whom I communicate via email.  More often than not I am 
communicating with people via email whom I have never met, and who I know 
very little about.  I sometimes come to trust these people through the 
email that they send, i.e. I find the things they say knowlegeable or 
insightful.  Therefore I build a certain degree of trust on the basis of 
this past experience, but I only associate that with their email address 
and name, not with their DN.  My point is that it is not possible to 
unambiguously associate a DN with an email address, so you can't make this 
leap without both being in a cert.  Therefore I am not going to send some 
one some secure data on the basis of just a DN if I have nothing to 
associate it with.

Now you could argue that there are some cases where you don't need to 
verify this binding if you have the context required to get the DN anyway, 
so therefore it should not be mandated.  But this is a relying party 
decision, not the decision of the person who signs the email.  I think you 
limit the ability of the relying party to make decisions about their email 
if you don't associate the From address with the signature.  

Every email address must have a From: address, and I think it is reasonable
that this email address in a secure message should always be securely 
verifiable, so that you can accurately bind an S/MIME message with its 
point of origin.

>If you are using free CAs which hand out certs to anyone, an rfc822
>address is just clutter which shortens the lifetime of the cert.  It
>doesn't make the two Johns any more unique than they were without it.
>Saying "John could receive email at this address at the time this cert
>was issued" links the cert to a non-secure pre-S/MIME rfc822 persona,
>but the reliability of that link is questionable, particularly if
>anything more than net reputation is at stake.

This is a valid point.  One my misgivings with X.509 is that they chose not
to separate attribute and key management (SPKI is much better about this).
While S/MIME has support for attribute certs that could be used to
associate email addresses with keys in identity certs (useful as these will
have different life-cycles), I don't think that the application support is
wide enough yet that this is really a valid alternative to putting the
email address in the certificate.

>If you are relying on CAs to provide a real PK Infrastructure (by ensuring
>that keyholders are tied to something with Identity significance such
>as a DUNS number or an employment record), then rfc822 addresses are
>obviously irrelevant.

Well actually what I think you are really after is associate a key holder 
with something (i.e. a privilege, identity or attribute).  But the point 
is about rfc822 addresses is that this is something you just about always 
need to verify.

Cheers.
-- 
Dean Povey,         | e-m: [email-masked]     | JCSI: Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120       |  security.dstc.edu.au/ 
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - C++ PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/

Date: Wed, 9 Feb 2000 19:02:34 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Problem for public CAs 
To: [email-masked]
Content-MD5: j/VaByAlx1qi3fsAN68bag==
Sender: [email-masked]

> To: "David P. Kemp" <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Problem for public CAs 
> Date: Thu, 10 Feb 2000 07:49:40 +1000
> From: Dean Povey <[email-masked]>
> 
> Sure, this is fine if you know the person you are communicating with by
> email personally, and aware of all the context that is implicit in their
> email address and hence the right DN to pick.  But what if I get the
> following:
> 
> From: [email-masked]
> Subject: Request for Proposal for the provision of Consulting Services
> To: Security Consultants Mailing List <[email-masked]>
> 
> Which of the following DN's is the correct one?
> 
> C=AU, OU=Accounting, O=ACME, CN=John Smith
> C=AU, OU=Accounting, O=ACME, CN=Jane Siegfried
> C=AU, OU=Hacking, O=ACME, CN=John Smith
> C=US, OU=Accounting, O=ACME, CN=John Smith
> C=ZA, OU=Consulting, O=ACME Rival Security Consultants, CN=John Smith
> 
> etc. etc.

If the message you received from "js" is an S/MIME message, only one
cert will validate the signature or decrypt the body, so you know
which DN is correct.

If the message from "js" is not S/MIME, you don't need a cert at all.

> So all I have to do to forge an email that looks like it comes from a 
> valid address is to come up with DN that looks plausible.  The problem 
> with relying on global names in general is that they don't include the 
> associated context (often referred to by the SPKI community as the "which 
> John Smith" problem).  The reason you make them stick the email address in 
> the cert is that this is absolutely bound to the message, wheras there is no 
> guarantee that the DN and email map to the same entity.  The cert can then 
> make the mapping between email and DN explicit hence linking the DN to the 
> message.
> 
> Sure, the person who "owns" [email-masked] can later point out that the DN
> used in the certificate is not them, but it is a bit late after you have
> just replied to them and sent a message encrypted with the hacker's public
> key.

How does the person who owns [email-masked] get involved in the first place?

If a hacker sends you an S/MIME message with the hacker's cert,
you can reply to it "securely" (with a message the hacker can decode).
What motivation is there for the hacker to cause the reply to be
delivered to "[email-masked]" where, presumably, the hacker can't get
it and the "real" js can't decrypt it?

You bootstrap an electronic identity by what you say.  If I send out
signed S/MIME messages all of which can be verified by the same cert,
it doesn't matter whether some of them come from a home rfc822 address
and others come from a work rfc822 address.  If I want them linked to
the same persona I'll use the same cert.  It also doesn't matter
whether the DN is a name with physical significance or a 'nym.  All that
matters is that the messages come from the possessor of one private key.
If you have a collection of S/MIME messages with two different certs,
with similar or even identical DNs:

 C=AU, OU=Accounting, O=ACME, CN=John Smith  (issuer A, public key X)
 C=AU, OU=Accounting, O=ACME, CN=John Smith  (issuer B, public key Y)

you will have enough context to label one address book entry "John Smith"
and the other one "John the flaming idiot".

If you are using free CAs which hand out certs to anyone, an rfc822
address is just clutter which shortens the lifetime of the cert.  It
doesn't make the two Johns any more unique than they were without it.
Saying "John could receive email at this address at the time this cert
was issued" links the cert to a non-secure pre-S/MIME rfc822 persona,
but the reliability of that link is questionable, particularly if
anything more than net reputation is at stake.

If you are relying on CAs to provide a real PK Infrastructure (by ensuring
that keyholders are tied to something with Identity significance such
as a DUNS number or an employment record), then rfc822 addresses are
obviously irrelevant.

To: "David P. Kemp" <[email-masked]>
Cc: [email-masked]
Subject: Re: Problem for public CAs 
Date: Thu, 10 Feb 2000 07:49:40 +1000
From: Dean Povey <[email-masked]>
Sender: [email-masked]

>Russ,
>
>Please describe a security vulnerability that is caused by lack of
>email address in subjectAltName.
>
>* In the case of authentication:
>I sign my own messages with (one of) my own certs.  The subject name of
>my cert is displayed to the recipient when the message signature is
>validated.  What vulnerability is introduced if a message signed by
>"C=US ... CN=David Kemp" comes from any email address, or mail list
>address, in the world?  The "from" and "reply-to" fields are both
>irrelevant to the authentication.
>
>* In the case of confidentiality:
>I want to send a message to "C=CA ... CN=Joe Smith".  I look up Joe's
>email address in my address book, which might be correct or incorrect.
>If Joe receives the message using whatever email address I have for him,
>he can read the message.  If my address book is incorrect and Fred
>receives the message, he can't read it because he doesn't have Joe's
>private key.
>

Sure, this is fine if you know the person you are communicating with by
email personally, and aware of all the context that is implicit in their
email address and hence the right DN to pick.  But what if I get the
following:

From: [email-masked]
Subject: Request for Proposal for the provision of Consulting Services
To: Security Consultants Mailing List <[email-masked]>

Which of the following DN's is the correct one?

C=AU, OU=Accounting, O=ACME, CN=John Smith
C=AU, OU=Accounting, O=ACME, CN=Jane Siegfried
C=AU, OU=Hacking, O=ACME, CN=John Smith
C=US, OU=Accounting, O=ACME, CN=John Smith
C=ZA, OU=Consulting, O=ACME Rival Security Consultants, CN=John Smith

etc. etc.

So all I have to do to forge an email that looks like it comes from a 
valid address is to come up with DN that looks plausible.  The problem 
with relying on global names in general is that they don't include the 
associated context (often referred to by the SPKI community as the "which 
John Smith" problem).  The reason you make them stick the email address in 
the cert is that this is absolutely bound to the message, wheras there is no 
guarantee that the DN and email map to the same entity.  The cert can then 
make the mapping between email and DN explicit hence linking the DN to the 
message.

Sure, the person who "owns" [email-masked] can later point out that the DN
used in the certificate is not them, but it is a bit late after you have
just replied to them and sent a message encrypted with the hacker's public
key. 

The answer to the privacy problem for public certificates is simple.  
Don't publish your certificate if you are worried about it.  Go to a CA 
whose certificate policy is not to publish in a public directory and give 
out your certificate to those you trust.

-- 
Dean Povey,         | e-m: [email-masked]     | JCSI: Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120       |  security.dstc.edu.au/ 
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - C++ PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/

From: [email-masked]
To: [email-masked]
Date: Wed, 9 Feb 2000 15:34:39 -0500
Subject: Re: Problem for public CAs
Sender: [email-masked]

Yes, but just what is it that is cryptographically bound?  In many cases,
requests for a certificate are submitted via mail and the certificate is
returned by mail (or at least the notification that the certificate is ready).
We are starting to cross the line of the CA's policy.  It seems to me that the
approach to both Signature Verification and the faith put in non-disclosure have
been far too simplified.  In cases where the CA Policy is based solely on the
e-mail address then it makes sense that ALL that is cryptographicalyly bound IS
the e-mail address and this have no relevance at all to the source's claimed
identity.  If you want more than that then you should not trust such a CA, and
the binding should be to some other credential which must somehow be
incorporated into the message.

>Russ,
>
>Please describe a security vulnerability that is caused by lack of
>email address in subjectAltName.
>
>* In the case of authentication:
>I sign my own messages with (one of) my own certs.  The subject name of
>my cert is displayed to the recipient when the message signature is
>validated.  What vulnerability is introduced if a message signed by
>"C=US ... CN=David Kemp" comes from any email address, or mail list
>address, in the world?  The "from" and "reply-to" fields are both
>irrelevant to the authentication.
>
>* In the case of confidentiality:
>I want to send a message to "C=CA ... CN=Joe Smith".  I look up Joe's
>email address in my address book, which might be correct or incorrect.
>If Joe receives the message using whatever email address I have for him,
>he can read the message.  If my address book is incorrect and Fred
>receives the message, he can't read it because he doesn't have Joe's
>private key.
>
>It seems to me that if there are security vulnerabilities, they are
>the result of a flawed HMI, not a flawed certificate profile.  If
>the HMI does not associate the subjectName with the message to which
>it is cryptographically bound, you will have vulnerabilities.
>
>Dave

Date: Wed, 9 Feb 2000 12:14:19 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Problem for public CAs
To: [email-masked]
Content-MD5: DwiWZh3kX07nptstkA9NSw==
Sender: [email-masked]

Russ,

Please describe a security vulnerability that is caused by lack of
email address in subjectAltName.

* In the case of authentication:
I sign my own messages with (one of) my own certs.  The subject name of
my cert is displayed to the recipient when the message signature is
validated.  What vulnerability is introduced if a message signed by
"C=US ... CN=David Kemp" comes from any email address, or mail list
address, in the world?  The "from" and "reply-to" fields are both
irrelevant to the authentication.

* In the case of confidentiality:
I want to send a message to "C=CA ... CN=Joe Smith".  I look up Joe's
email address in my address book, which might be correct or incorrect.
If Joe receives the message using whatever email address I have for him,
he can read the message.  If my address book is incorrect and Fred
receives the message, he can't read it because he doesn't have Joe's
private key.

It seems to me that if there are security vulnerabilities, they are
the result of a flawed HMI, not a flawed certificate profile.  If
the HMI does not associate the subjectName with the message to which
it is cryptographically bound, you will have vulnerabilities.

Dave

> Date: Wed, 09 Feb 2000 11:27:35 -0500
> To: "Graham Laws" <[email-masked]>
> From: Russ Housley <[email-masked]>
> Subject: Re: Problem for public CAs
> Cc: "'SMIME IETF'" <[email-masked]>

> Graham:
> 
> Certificates usually contain a subject name and a public key.  However, 
> this information is not adequate for a mail user agent to determine which 
> certificate goes with a particular e-mail address.  That is why the S/MIME 
> RFCs require the inclusion of the e-mail address in the subjectAltName.
> 
> Several people have tried to build S/MIME capabilities that support 
> certificates without e-mail address in the subjectAltName.  The results are 
> security vulnerabilities!  The address book must be used to associate the 
> certificate and the e-mail address.  Users are not very good at associating 
> the correct certificate with the correct address book entry (that is, the 
> correct e-mail address).  This mismatch has impacts on both authentication 
> and confidentiality.
> 
> Russ

From: Tim Dean <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'David P. Kemp'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Problem for public CAs
Date: Wed, 9 Feb 2000 16:44:35 -0000
Organization: DERA
Sender: [email-masked]

Dave,

What you describe is also the practice in our organisation: a fairly simple 
addressing structure is presented to the "external world" and a much richer 
structure is used internally . I also agree with you that having multiple 
e-mail addresses in certificates is a bad idea for several reasons: it gives 
away organisational structure that in some cases is sensitive. Furthermore, it 
may give away other things about the organisation, such as which employees are 
involved in mobile working, for example.

In order to address this kind of requirement in S/MIME, this is precisely the 
motivation for the "domain Signature" in the domain security services draft. We 
have there a name mapping convention (section 3.1.1) that says that the bit on 
the right-hand side of the '@' symbol in the certificate of the domain signer 
must be the same as, or an ascendant of that in the originator's address.  ( 
thus for my e-mail address, [email-masked], the domain signature could 
contain [email-masked]).

At the last meeting, I believe there was a question raised as to whether 
allowing a subset of the originators address in the domain signature is such a 
good idea. Some people felt that forcing them to be identical would be better - 
ie for [email-masked] the domain signer must be 
[email-masked], nothing more, nothing less. (The 
arguments were not discussed in detail.)   We can't make up our minds on this 
one: we are probably leaning in favour of allowing the greater flexibility, and 
therefore relying on the CA naming policy to prevent certificates with 
non-sensible names (e.g. tim@uk!). However, if you or others have views on 
this, they would be most appreciated. We very much hope to nail down this issue 
soon, so we can move the Draft towards last call.

Regards,
Tim

-----Original Message-----
From:	David P. Kemp [SMTP:[email-masked]]
Sent:	09 February 2000 14:37
To:	[email-masked]
Subject:	RE: Problem for public CAs

Brad,

The problem is that I may not *want* to have two or more E-mail
addresses within the subjectAltName extension of my certificates.

Many organizations choose to present organizational email addresses
for all employees, regardless of how email is delivered within the
organization.  My external address is "[email-masked]'.

Internally, email addresses include hostnames - my internal address could
be (but isn't :-) something like [email-masked]'.  Our
network administrators have configured Microsoft Outlook so that users
use internal addresses for their internal workstations.  As far as I
know, that is standard practice.  If S/MIME requires transport addresses
to be present in certificates, that means my certificate MUST contain
both [email-masked]' and [email-masked]' if I
want to be able to both send and receive S/MIME messages.

This is a defect.  I claim that the defect is with the S/MIME spec,
not with the mail transport infrastructure.

Dave

> From: Brad Smith <[email-masked]>
> To: [email-masked]
> Subject: RE: Problem for public CAs
> Date: Mon, 7 Feb 2000 14:39:57 -0500
>
> Unless I'm misunderstanding what you're saying, recall that 'subjectAltName'
> is allowed to have multiple values. So, for example, your own certificate
> can have all three E-mail addresses within.
>
> The advantage is that somebody doing a search on any of your known E-mail
> addresses will always return the same certificate.
>
> The downside (or, certainly, *a* downside) is that if somebody knows, for
> example, your Compuserve address, he can do a directory search for that, get
> your certificate, and from that learn all your other E-mail addresses.
>
> On the other hand, if you send a signed message, presumably your digital
> signature would contain all that information anyway.
>
> Alas, I'm unable to suggest any solutions. If it were a major issue to me
> personally, I'd just not allow my certificate to be published in any public
> CAs. But that's probably not the answer you're looking for. :-)
>
> Brad.
> --
> Brad P. Smith   [Development Lead - Entrust/Express]
> Entrust Technologies Inc.
> 750 Heron Road, Suite E800
> Ottawa, Ontario, K1V 1A7, Canada
> mailto:[email-masked]	http://www.entrust.com

Date: Wed, 09 Feb 2000 11:27:35 -0500
To: "Graham Laws" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Problem for public CAs
Cc: "'SMIME IETF'" <[email-masked]>
Sender: [email-masked]

Graham:

Certificates usually contain a subject name and a public key.  However, 
this information is not adequate for a mail user agent to determine which 
certificate goes with a particular e-mail address.  That is why the S/MIME 
RFCs require the inclusion of the e-mail address in the subjectAltName.

Several people have tried to build S/MIME capabilities that support 
certificates without e-mail address in the subjectAltName.  The results are 
security vulnerabilities!  The address book must be used to associate the 
certificate and the e-mail address.  Users are not very good at associating 
the correct certificate with the correct address book entry (that is, the 
correct e-mail address).  This mismatch has impacts on both authentication 
and confidentiality.

Russ

At 02:24 PM 02/07/2000 +0000, Graham Laws wrote:
>For public CAs, particularly in Europe, the requirement to place an email
>address in the subjectAltname extension of each x.509 public key certificate
>in order to enable S/MIME is a big problem.
>
>Firstly, all such certificates must reside in a public Directory. Any
>determined spammer is going to be able to easily create an immense spam list
>from the Directory's entire certificate population, using a few LDAP calls
>and an ASN.1 decoder. Our customers are already nervous at the prospect of
>this, and for potential customers it may be a significant bar to take-up.
>
>Secondly, the European Privacy Directive looks very unfavourably upon
>real-world identities being in any way expressed both in the Subject and
>SubjectAltName attributes of the public key certificate. This would appear
>to rule out S/MIME for those whose names are embedded in their email
>addresses, e.g.  [email-masked]
>
>The issues raised by the second point are relatively easy to circumvent. Use
>pseudonymous names for the Subject, and insist on a pseudonymous email
>address if S/MIME is required.
>
>But the first point about the ease with which spam lists can be created is a
>real worrier. I have looked through previous threads, including the one
>entitled "Mail addresses in S/MIME certs", but I can't find where these
>specific issues have been discussed before.
>
>Comments/discussion via this forum welcome.
>
>Best Regards
>Graham Laws
>
>______________________________________________
>Graham Laws
>PKI Systems Technical Consultant
>Royal Mail ViaCode      Phone :         +44 (0)1246-293761
>Block A, 1st Floor      Postline : 5453-3761
>St. Mary's Court                Fax :   +44 (0)1246-293751
>St. Mary's Gate
>Chesterfield
>S41 7TD
>
>Public Key Validation String : MXZQ-7MM5-9A58

Date: Wed, 9 Feb 2000 09:37:13 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Problem for public CAs
To: [email-masked]
Content-MD5: VyV4rrR6ewKjW3JlbybK+w==
Sender: [email-masked]

Brad,

The problem is that I may not *want* to have two or more E-mail
addresses within the subjectAltName extension of my certificates.

Many organizations choose to present organizational email addresses
for all employees, regardless of how email is delivered within the
organization.  My external address is "[email-masked]'.

Internally, email addresses include hostnames - my internal address could
be (but isn't :-) something like [email-masked]'.  Our
network administrators have configured Microsoft Outlook so that users
use internal addresses for their internal workstations.  As far as I
know, that is standard practice.  If S/MIME requires transport addresses
to be present in certificates, that means my certificate MUST contain
both [email-masked]' and [email-masked]' if I
want to be able to both send and receive S/MIME messages.

This is a defect.  I claim that the defect is with the S/MIME spec,
not with the mail transport infrastructure.

Dave

> From: Brad Smith <[email-masked]>
> To: [email-masked]
> Subject: RE: Problem for public CAs
> Date: Mon, 7 Feb 2000 14:39:57 -0500 
> 
> Unless I'm misunderstanding what you're saying, recall that 'subjectAltName'
> is allowed to have multiple values. So, for example, your own certificate
> can have all three E-mail addresses within.
> 
> The advantage is that somebody doing a search on any of your known E-mail
> addresses will always return the same certificate.
> 
> The downside (or, certainly, *a* downside) is that if somebody knows, for
> example, your Compuserve address, he can do a directory search for that, get
> your certificate, and from that learn all your other E-mail addresses.
> 
> On the other hand, if you send a signed message, presumably your digital
> signature would contain all that information anyway.
> 
> Alas, I'm unable to suggest any solutions. If it were a major issue to me
> personally, I'd just not allow my certificate to be published in any public
> CAs. But that's probably not the answer you're looking for. :-)
> 
> Brad.
> --
> Brad P. Smith   [Development Lead - Entrust/Express]
> Entrust Technologies Inc.
> 750 Heron Road, Suite E800
> Ottawa, Ontario, K1V 1A7, Canada
> mailto:[email-masked]	http://www.entrust.com

Date: Tue, 08 Feb 2000 10:32:29 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: 47th IETF: S/MIME WG Agenda
Sender: [email-masked]

Dear Working Group:

The S/MIME WG meeting is currently scheduled for WEDNESDAY, March 29, 2000 
from 1530 to 1730.  As usual, scheduling is tentative and subject to change.

So, I am now putting together the agenda for the meeting.  Please send me 
requests for time slots.

Russ

Date: Tue, 08 Feb 2000 10:42:33 +0100
From: HORII Naoto <[email-masked]>
Subject: Re: Problem for public CAs
To: [email-masked]
Sender: [email-masked]

Alfred Arsenault wrote:

> -----Original Message-----
> From: HORII Naoto [mailto:[email-masked]]
> Sent: Monday, February 07, 2000 1:33 PM
> To: [email-masked]
> Subject: Re: Problem for public CAs
>
> Item 3 would typically be implemented by restricting the type of questions a
> client can ask to the CA:
>
> 1) S/MIME certificates would be returned only if the subjectAltname is
> unambiguously specified - e.g.
>
> client: search certificate for subjectAltname=[email-masked]
> server: OK, certificate=blah
>
> client: search certificate for subjectAltname=[email-masked]
> server: ERROR, inavlid search key
>
> For such a protection scheme to work, your directory server must obviously
> be able to validate/
> sanitize a search key against access rules - e.g. "no wildcards allowed in
> search keys" - before
> forwarding the search to your directory's backend engine.
>
> <snip>
>
> AWA: Of course, this doesn't work if you allow me an unlimited number of
> queries to your directory.  I'll just start with some of the more "obvious"
> possibilities and work my way out; e.g.,
>
>         search for:  certificate for [email-masked]
>                        certificate for [email-masked]
>                          certificate for [email-masked]
>                          ...
>
> It's not real efficient, but hey, that's what computer programs are for. :-)
> Sooner or later, I'll get a reasonable number of certs, and away I go.  I'll
> chew up a lot of network bandwidth and leave footprints all over your
> directory, but if you let me search like this, it's worth it - if there's
> money to be made in spamming, I don't care what it costs you for me to get
> the addresses. :-)

My assumption, of course, is that it would be less expensive for a spammer to just send
his/her mail via an open relay mail gateway to [email-masked], [email-masked],
[email-masked] -- even if most of these addresses will be invalid -- than to look up
digital certificates for these addresses before sending the mails.

It usually doesn't make sense for a spammer to use the target's certificate to encrypt the
spam: doing so makes evey message unique and the spammer then loses the leverage
of being able to dispatch a mountain of e-mail by forwarding just a single copy of the
mail to an open relay SMTP server together with a space-efficient recipient address list.

For e-mail, I think the privacy concerns of having your e-mail address -- once it's known --
easily mappable to a PKI certificate via a publicly accesible directory are outweighed by the
benefit of allowing people to authemticate your mails or send you encrypted data.
E-mail addresses are just one of the numerous coordinate points  -- which include e.g. mobile
and fax phone numbers, e-mail addresses, URLs, X.500 DNs... -- people can use to sort of
locate you in an abstract digital space.  IMHO these coordinate's connection with the "real"
physical world in which you live can be made quite tenuous if you are careful enough...

Are we straying more and more off-topic for this forum or what ;-)

Cheers,
Naoto

From: Alfred Arsenault <[email-masked]>
To: "'HORII Naoto'" <[email-masked]>, [email-masked]
Subject: RE: Problem for public CAs
Date: Mon, 7 Feb 2000 15:41:41 -0500 
Sender: [email-masked]

-----Original Message-----
From: HORII Naoto [mailto:[email-masked]]
Sent: Monday, February 07, 2000 1:33 PM
To: [email-masked]
Subject: Re: Problem for public CAs

Item 3 would typically be implemented by restricting the type of questions a
client can ask to the CA:

1) S/MIME certificates would be returned only if the subjectAltname is
unambiguously specified - e.g.

client: search certificate for subjectAltname=[email-masked]
server: OK, certificate=blah

client: search certificate for subjectAltname=[email-masked]
server: ERROR, inavlid search key

For such a protection scheme to work, your directory server must obviously
be able to validate/
sanitize a search key against access rules - e.g. "no wildcards allowed in
search keys" - before
forwarding the search to your directory's backend engine.

<snip>

AWA: Of course, this doesn't work if you allow me an unlimited number of
queries to your directory.  I'll just start with some of the more "obvious"
possibilities and work my way out; e.g.,

	search for:  certificate for [email-masked]
		       certificate for [email-masked]
			 certificate for [email-masked]
			 ...

It's not real efficient, but hey, that's what computer programs are for. :-)
Sooner or later, I'll get a reasonable number of certs, and away I go.  I'll
chew up a lot of network bandwidth and leave footprints all over your
directory, but if you let me search like this, it's worth it - if there's
money to be made in spamming, I don't care what it costs you for me to get
the addresses. :-)  

				Al Arsenault

-- insert usual disclaimer about this being my opinion, and not reflecting
the opinion of my employer or of any other organization with which I have a
relationship

-- insert second disclaimer: no, I don't spam, I don't like spam, I don't
harvest names to help somebody else spam;...

From: Alfred Arsenault <[email-masked]>
To: [email-masked]
Subject: RE: Problem for public CAs
Date: Mon, 7 Feb 2000 15:34:43 -0500 
Sender: [email-masked]

Well, I don't know how AlphaTrust does this, but one system I've been
involved with in the past works as follows:

	- the directory mandates "strong authentication"; i.e., you have to
authenticate yourself cryptographically as part of binding to the directory;

	- the directory enforces the policy that only people who have
certificates issued by an approved CA can query the directory.  That is,
when you ask the directory for a certificate for user "Paul Hoffman", it
verifies via the strong authentication that:
		- you possess the private key associated with a certificate
		- that certificate was issued by an approved CA.
If you pass this check, the directory will search for the cert you want and
return it if it can find it.

	- requests from other than approved users are rejected.  If you
aren't already in my community, you don't get information from my directory.
Enforcement is via authentication to the directory; no matter who you claim
to be, if you can't authenticate using a cert from an approved CA, it's the
bit bucket for ya.

Then, the only people who can violate the policy on combing the directory
for email addresses to later be used for spam are your own users, and you
have their pledge - I hope backed up with the threat of legal action - that
they won't do so.

Bill, is that roughly how your system works?

				Al Arsenault

-- As usual, this posting reflects my own opinions only, and does not
represent the opinions or policies of my employer or any other organization
with which I may have a relationship.

Graham Laws wrote:

> Bill,
> Thanks for the reply. I am intrigued by item 3 as to how, if I wanted to
> encrypt a message to you, I would be able to find your public key
> certificate, if the CA's directory entries are not open to the public ?
(to
> avoid cross-cert issues, lets assume we both belong to the same CA).
>
> Are you assuming that correspondents will swap key files and use some
> out-of-band authentication mechanism ? Or can your clients only gain
access
> to the directory for searches, etc., by using their certificates, e.g. by
> LDAPv3 TLS or SASL ?
>
> The S/MIME requirement to place email address in the certificate severely
> weakens the PKI model with regard to privacy, and will no doubt lead to
all
> sorts of bespoke solutions for public Directories. I suspect this will
also
> lead to many interoperability problems later.
>
> Best Regards
> Graham
>
> -----Original Message-----
> From: Bill Brice (listserv) [mailto:[email-masked]]
> Sent: 07 February 2000 15:54
> To: 'Graham Laws'
> Subject: RE: Problem for public CAs
>
> Graham,
>
> As a US based public CA that incorporates EU Privacy and Data Protection
> directives into our PKI, we have addressed this issue as follows:
>
> 1) Our Members give their permission, as required by EU law, to
incorporate
> common names and email addresses into their certificates.
> 2) Our Members pledge, as part of their Member Agreement, not to use
another
> Members information for purposes such as spam.
> 3) Our directory entries are not open to the public, unless the Member has
> agreed
> to publish such information publicly.
> 4) Relying parties have agreed to respect the privacy rights of our
Members
> and
> not to use personally identifiable information without the Member's
> permission.
>
> Such a solution is possible with a contractually-based public PKI such as
> AlphaTrust. It is more difficult to implement with an enterprise model
> or an open model (i.e. Verisign). But then that's why we exist - to solve
> the
> sticky issues of privacy, legality and transaction risk.
>
> Food for thought.
>
> Bill Brice, CEO
> http://alphatrust.com
>
> -----Original Message-----
> From: Graham Laws [mailto:[email-masked]]
> Sent: Monday, February 07, 2000 8:24 AM
> To: 'SMIME IETF'
> Subject: Problem for public CAs
>
> For public CAs, particularly in Europe, the requirement to place an email
> address in the subjectAltname extension of each x.509 public key
certificate
> in order to enable S/MIME is a big problem.
>
> Firstly, all such certificates must reside in a public Directory. Any
> determined spammer is going to be able to easily create an immense spam
list
> from the Directory's entire certificate population, using a few LDAP calls
> and an ASN.1 decoder. Our customers are already nervous at the prospect of
> this, and for potential customers it may be a significant bar to take-up.
>
> Secondly, the European Privacy Directive looks very unfavourably upon
> real-world identities being in any way expressed both in the Subject and
> SubjectAltName attributes of the public key certificate. This would appear
> to rule out S/MIME for those whose names are embedded in their email
> addresses, e.g.  [email-masked]
>
> The issues raised by the second point are relatively easy to circumvent.
Use
> pseudonymous names for the Subject, and insist on a pseudonymous email
> address if S/MIME is required.
>
> But the first point about the ease with which spam lists can be created is
a
> real worrier. I have looked through previous threads, including the one
> entitled "Mail addresses in S/MIME certs", but I can't find where these
> specific issues have been discussed before.
>
> Comments/discussion via this forum welcome.
>
> Best Regards
> Graham Laws
>
> ______________________________________________
> Graham Laws
> PKI Systems Technical Consultant
> Royal Mail ViaCode      Phone :         +44 (0)1246-293761
> Block A, 1st Floor      Postline : 5453-3761
> St. Mary's Court                Fax :   +44 (0)1246-293751
> St. Mary's Gate
> Chesterfield
> S41 7TD
>
> Public Key Validation String : MXZQ-7MM5-9A58

From: Brad Smith <[email-masked]>
To: [email-masked]
Subject: RE: Problem for public CAs
Date: Mon, 7 Feb 2000 14:39:57 -0500 
Sender: [email-masked]

Unless I'm misunderstanding what you're saying, recall that 'subjectAltName'
is allowed to have multiple values. So, for example, your own certificate
can have all three E-mail addresses within.

The advantage is that somebody doing a search on any of your known E-mail
addresses will always return the same certificate.

The downside (or, certainly, *a* downside) is that if somebody knows, for
example, your Compuserve address, he can do a directory search for that, get
your certificate, and from that learn all your other E-mail addresses.

On the other hand, if you send a signed message, presumably your digital
signature would contain all that information anyway.

Alas, I'm unable to suggest any solutions. If it were a major issue to me
personally, I'd just not allow my certificate to be published in any public
CAs. But that's probably not the answer you're looking for. :-)

Brad.
--
Brad P. Smith   [Development Lead - Entrust/Express]
Entrust Technologies Inc.
750 Heron Road, Suite E800
Ottawa, Ontario, K1V 1A7, Canada
mailto:[email-masked]	http://www.entrust.com

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Monday, February 7, 2000 13:36
To: [email-masked]
Subject: Re: Problem for public CAs

Graham,

The problem with requiring email addresses in certificates (assuming
the address is examined by Mail User Agents) is much more basic:  the
identity certified by a CA has in principle nothing to do with where
email is sent from or delivered to.  Regardless of whether I want my
Certified Net Nym to be "Dave Kemp" or "[email-masked]", I
should be able to send and receive S/MIME messages using any address,
including "[email-masked]" and "[email-masked]", without
having to know in advance where I might be or who I'll be using for
an ISP.

The concept that Identification and Authentication should be independent
of transport addressing seems not to have gained traction last time
around, for some unfathomable reason.  Perhaps the spam and privacy
arguments will resonate more effectively with readers of this list.

Good luck.

Dave

> From: "Graham Laws" <[email-masked]>
> To: "'SMIME IETF'" <[email-masked]>
> Subject: Problem for public CAs
> Date: Mon, 7 Feb 2000 14:24:16 -0000
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
> Importance: Normal
> List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
> List-ID: <ietf-smime.imc.org>
> List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
> 
> For public CAs, particularly in Europe, the requirement to place an email
> address in the subjectAltname extension of each x.509 public key
certificate
> in order to enable S/MIME is a big problem.
> 
> Firstly, all such certificates must reside in a public Directory. Any
> determined spammer is going to be able to easily create an immense spam
list
> from the Directory's entire certificate population, using a few LDAP calls
> and an ASN.1 decoder. Our customers are already nervous at the prospect of
> this, and for potential customers it may be a significant bar to take-up.
> 
> Secondly, the European Privacy Directive looks very unfavourably upon
> real-world identities being in any way expressed both in the Subject and
> SubjectAltName attributes of the public key certificate. This would appear
> to rule out S/MIME for those whose names are embedded in their email
> addresses, e.g.  [email-masked]
> 
> The issues raised by the second point are relatively easy to circumvent.
Use
> pseudonymous names for the Subject, and insist on a pseudonymous email
> address if S/MIME is required.
> 
> But the first point about the ease with which spam lists can be created is
a
> real worrier. I have looked through previous threads, including the one
> entitled "Mail addresses in S/MIME certs", but I can't find where these
> specific issues have been discussed before.
> 
> Comments/discussion via this forum welcome.
> 
> Best Regards
> Graham Laws
> 
> ______________________________________________
> Graham Laws
> PKI Systems Technical Consultant
> Royal Mail ViaCode	Phone : 	+44 (0)1246-293761
> Block A, 1st Floor	Postline : 5453-3761
> St. Mary's Court		Fax : 	+44 (0)1246-293751
> St. Mary's Gate
> Chesterfield
> S41 7TD
> 
> Public Key Validation String : MXZQ-7MM5-9A58
> 
> 

Date: Mon, 7 Feb 2000 13:36:16 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Problem for public CAs
To: [email-masked]
Content-MD5: nIijzPrls4LyDnNfOF1DyA==
Sender: [email-masked]

Graham,

The problem with requiring email addresses in certificates (assuming
the address is examined by Mail User Agents) is much more basic:  the
identity certified by a CA has in principle nothing to do with where
email is sent from or delivered to.  Regardless of whether I want my
Certified Net Nym to be "Dave Kemp" or "[email-masked]", I
should be able to send and receive S/MIME messages using any address,
including "[email-masked]" and "[email-masked]", without
having to know in advance where I might be or who I'll be using for
an ISP.

The concept that Identification and Authentication should be independent
of transport addressing seems not to have gained traction last time
around, for some unfathomable reason.  Perhaps the spam and privacy
arguments will resonate more effectively with readers of this list.

Good luck.

Dave

> From: "Graham Laws" <[email-masked]>
> To: "'SMIME IETF'" <[email-masked]>
> Subject: Problem for public CAs
> Date: Mon, 7 Feb 2000 14:24:16 -0000
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
> Importance: Normal
> List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
> List-ID: <ietf-smime.imc.org>
> List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
> 
> For public CAs, particularly in Europe, the requirement to place an email
> address in the subjectAltname extension of each x.509 public key certificate
> in order to enable S/MIME is a big problem.
> 
> Firstly, all such certificates must reside in a public Directory. Any
> determined spammer is going to be able to easily create an immense spam list
> from the Directory's entire certificate population, using a few LDAP calls
> and an ASN.1 decoder. Our customers are already nervous at the prospect of
> this, and for potential customers it may be a significant bar to take-up.
> 
> Secondly, the European Privacy Directive looks very unfavourably upon
> real-world identities being in any way expressed both in the Subject and
> SubjectAltName attributes of the public key certificate. This would appear
> to rule out S/MIME for those whose names are embedded in their email
> addresses, e.g.  [email-masked]
> 
> The issues raised by the second point are relatively easy to circumvent. Use
> pseudonymous names for the Subject, and insist on a pseudonymous email
> address if S/MIME is required.
> 
> But the first point about the ease with which spam lists can be created is a
> real worrier. I have looked through previous threads, including the one
> entitled "Mail addresses in S/MIME certs", but I can't find where these
> specific issues have been discussed before.
> 
> Comments/discussion via this forum welcome.
> 
> Best Regards
> Graham Laws
> 
> ______________________________________________
> Graham Laws
> PKI Systems Technical Consultant
> Royal Mail ViaCode	Phone : 	+44 (0)1246-293761
> Block A, 1st Floor	Postline : 5453-3761
> St. Mary's Court		Fax : 	+44 (0)1246-293751
> St. Mary's Gate
> Chesterfield
> S41 7TD
> 
> Public Key Validation String : MXZQ-7MM5-9A58
> 
> 

Date: Mon, 07 Feb 2000 19:32:57 +0100
From: HORII Naoto <[email-masked]>
Subject: Re: Problem for public CAs
To: [email-masked]
Sender: [email-masked]

Item 3 would typically be implemented by restricting the type of questions a client can ask to the CA:

1) S/MIME certificates would be returned only if the subjectAltname is unambiguously specified - e.g.

client: search certificate for subjectAltname=[email-masked]
server: OK, certificate=blah

client: search certificate for subjectAltname=[email-masked]
server: ERROR, inavlid search key

For such a protection scheme to work, your directory server must obviously be able to validate/
sanitize a search key against access rules — e.g. "no wildcards allowed in search keys" — before
forwarding the search to your directory's backend engine.

2) Certificate revocation status would be returned only for explicitly specified serial numbers:

client: search revocationStatus for serialNumber=12:34:56:78:9a:bc:de:f0
server: OK, revocationStatus=false

client: search revocationStatus for serialNumber=12:34:56:*
server: ERROR, inavlid search key

Note that to prevent a trivial exploration of the certificate space by a spy intent on
determining the number of certificates issued by a particular CA, the certificate's serial
numbers should probably be derived from a hash of the Subject's data.
A 64- or 80-bit long hash would give a serial number space large enough to prevent brute-
force scans of the CRL subtree, while yielding serial numbers small enough to be accepted
by most X.509 implementations.

Cheers,
Naoto

Graham Laws wrote:

> Bill,
> Thanks for the reply. I am intrigued by item 3 as to how, if I wanted to
> encrypt a message to you, I would be able to find your public key
> certificate, if the CA's directory entries are not open to the public ? (to
> avoid cross-cert issues, lets assume we both belong to the same CA).
>
> Are you assuming that correspondents will swap key files and use some
> out-of-band authentication mechanism ? Or can your clients only gain access
> to the directory for searches, etc., by using their certificates, e.g. by
> LDAPv3 TLS or SASL ?
>
> The S/MIME requirement to place email address in the certificate severely
> weakens the PKI model with regard to privacy, and will no doubt lead to all
> sorts of bespoke solutions for public Directories. I suspect this will also
> lead to many interoperability problems later.
>
> Best Regards
> Graham
>
> -----Original Message-----
> From: Bill Brice (listserv) [mailto:[email-masked]]
> Sent: 07 February 2000 15:54
> To: 'Graham Laws'
> Subject: RE: Problem for public CAs
>
> Graham,
>
> As a US based public CA that incorporates EU Privacy and Data Protection
> directives into our PKI, we have addressed this issue as follows:
>
> 1) Our Members give their permission, as required by EU law, to incorporate
> common names and email addresses into their certificates.
> 2) Our Members pledge, as part of their Member Agreement, not to use another
> Members information for purposes such as spam.
> 3) Our directory entries are not open to the public, unless the Member has
> agreed
> to publish such information publicly.
> 4) Relying parties have agreed to respect the privacy rights of our Members
> and
> not to use personally identifiable information without the Member's
> permission.
>
> Such a solution is possible with a contractually-based public PKI such as
> AlphaTrust. It is more difficult to implement with an enterprise model
> or an open model (i.e. Verisign). But then that's why we exist - to solve
> the
> sticky issues of privacy, legality and transaction risk.
>
> Food for thought.
>
> Bill Brice, CEO
> http://alphatrust.com
>
> -----Original Message-----
> From: Graham Laws [mailto:[email-masked]]
> Sent: Monday, February 07, 2000 8:24 AM
> To: 'SMIME IETF'
> Subject: Problem for public CAs
>
> For public CAs, particularly in Europe, the requirement to place an email
> address in the subjectAltname extension of each x.509 public key certificate
> in order to enable S/MIME is a big problem.
>
> Firstly, all such certificates must reside in a public Directory. Any
> determined spammer is going to be able to easily create an immense spam list
> from the Directory's entire certificate population, using a few LDAP calls
> and an ASN.1 decoder. Our customers are already nervous at the prospect of
> this, and for potential customers it may be a significant bar to take-up.
>
> Secondly, the European Privacy Directive looks very unfavourably upon
> real-world identities being in any way expressed both in the Subject and
> SubjectAltName attributes of the public key certificate. This would appear
> to rule out S/MIME for those whose names are embedded in their email
> addresses, e.g.  [email-masked]
>
> The issues raised by the second point are relatively easy to circumvent. Use
> pseudonymous names for the Subject, and insist on a pseudonymous email
> address if S/MIME is required.
>
> But the first point about the ease with which spam lists can be created is a
> real worrier. I have looked through previous threads, including the one
> entitled "Mail addresses in S/MIME certs", but I can't find where these
> specific issues have been discussed before.
>
> Comments/discussion via this forum welcome.
>
> Best Regards
> Graham Laws
>
> ______________________________________________
> Graham Laws
> PKI Systems Technical Consultant
> Royal Mail ViaCode      Phone :         +44 (0)1246-293761
> Block A, 1st Floor      Postline : 5453-3761
> St. Mary's Court                Fax :   +44 (0)1246-293751
> St. Mary's Gate
> Chesterfield
> S41 7TD
>
> Public Key Validation String : MXZQ-7MM5-9A58

Date: Mon, 07 Feb 2000 10:28:31 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Problem for public CAs
Sender: [email-masked]

Hmmm. Either you identify the public key in a certificate by an appropriate 
identifier (and "email address" is appropriate for S/MIME), or you ignore 
the identification in the certificate. Are you proposing an alternative 
solution for S/MIME certificate usage?

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Graham Laws" <[email-masked]>
To: "'Bill Brice (listserv)'" <[email-masked]>
Cc: "'SMIME IETF'" <[email-masked]>
Subject: RE: Problem for public CAs
Date: Mon, 7 Feb 2000 17:03:56 -0000
Importance: Normal
Sender: [email-masked]

Bill,
Thanks for the reply. I am intrigued by item 3 as to how, if I wanted to
encrypt a message to you, I would be able to find your public key
certificate, if the CA's directory entries are not open to the public ? (to
avoid cross-cert issues, lets assume we both belong to the same CA).

Are you assuming that correspondents will swap key files and use some
out-of-band authentication mechanism ? Or can your clients only gain access
to the directory for searches, etc., by using their certificates, e.g. by
LDAPv3 TLS or SASL ?

The S/MIME requirement to place email address in the certificate severely
weakens the PKI model with regard to privacy, and will no doubt lead to all
sorts of bespoke solutions for public Directories. I suspect this will also
lead to many interoperability problems later.

Best Regards
Graham

-----Original Message-----
From: Bill Brice (listserv) [mailto:[email-masked]]
Sent: 07 February 2000 15:54
To: 'Graham Laws'
Subject: RE: Problem for public CAs

Graham,

As a US based public CA that incorporates EU Privacy and Data Protection
directives into our PKI, we have addressed this issue as follows:

1) Our Members give their permission, as required by EU law, to incorporate
common names and email addresses into their certificates.
2) Our Members pledge, as part of their Member Agreement, not to use another
Members information for purposes such as spam.
3) Our directory entries are not open to the public, unless the Member has
agreed
to publish such information publicly.
4) Relying parties have agreed to respect the privacy rights of our Members
and
not to use personally identifiable information without the Member's
permission.

Such a solution is possible with a contractually-based public PKI such as
AlphaTrust. It is more difficult to implement with an enterprise model
or an open model (i.e. Verisign). But then that's why we exist - to solve
the
sticky issues of privacy, legality and transaction risk.

Food for thought.

Bill Brice, CEO
http://alphatrust.com

-----Original Message-----
From: Graham Laws [mailto:[email-masked]]
Sent: Monday, February 07, 2000 8:24 AM
To: 'SMIME IETF'
Subject: Problem for public CAs

For public CAs, particularly in Europe, the requirement to place an email
address in the subjectAltname extension of each x.509 public key certificate
in order to enable S/MIME is a big problem.

Firstly, all such certificates must reside in a public Directory. Any
determined spammer is going to be able to easily create an immense spam list
from the Directory's entire certificate population, using a few LDAP calls
and an ASN.1 decoder. Our customers are already nervous at the prospect of
this, and for potential customers it may be a significant bar to take-up.

Secondly, the European Privacy Directive looks very unfavourably upon
real-world identities being in any way expressed both in the Subject and
SubjectAltName attributes of the public key certificate. This would appear
to rule out S/MIME for those whose names are embedded in their email
addresses, e.g.  [email-masked]

The issues raised by the second point are relatively easy to circumvent. Use
pseudonymous names for the Subject, and insist on a pseudonymous email
address if S/MIME is required.

But the first point about the ease with which spam lists can be created is a
real worrier. I have looked through previous threads, including the one
entitled "Mail addresses in S/MIME certs", but I can't find where these
specific issues have been discussed before.

Comments/discussion via this forum welcome.

Best Regards
Graham Laws

______________________________________________
Graham Laws
PKI Systems Technical Consultant
Royal Mail ViaCode	Phone : 	+44 (0)1246-293761
Block A, 1st Floor	Postline : 5453-3761
St. Mary's Court		Fax : 	+44 (0)1246-293751
St. Mary's Gate
Chesterfield
S41 7TD

Public Key Validation String : MXZQ-7MM5-9A58

From: "Graham Laws" <[email-masked]>
To: "'SMIME IETF'" <[email-masked]>
Subject: Problem for public CAs
Date: Mon, 7 Feb 2000 14:24:16 -0000
Importance: Normal
Sender: [email-masked]

For public CAs, particularly in Europe, the requirement to place an email
address in the subjectAltname extension of each x.509 public key certificate
in order to enable S/MIME is a big problem.

Firstly, all such certificates must reside in a public Directory. Any
determined spammer is going to be able to easily create an immense spam list
from the Directory's entire certificate population, using a few LDAP calls
and an ASN.1 decoder. Our customers are already nervous at the prospect of
this, and for potential customers it may be a significant bar to take-up.

Secondly, the European Privacy Directive looks very unfavourably upon
real-world identities being in any way expressed both in the Subject and
SubjectAltName attributes of the public key certificate. This would appear
to rule out S/MIME for those whose names are embedded in their email
addresses, e.g.  [email-masked]

The issues raised by the second point are relatively easy to circumvent. Use
pseudonymous names for the Subject, and insist on a pseudonymous email
address if S/MIME is required.

But the first point about the ease with which spam lists can be created is a
real worrier. I have looked through previous threads, including the one
entitled "Mail addresses in S/MIME certs", but I can't find where these
specific issues have been discussed before.

Comments/discussion via this forum welcome.

Best Regards
Graham Laws

______________________________________________
Graham Laws
PKI Systems Technical Consultant
Royal Mail ViaCode	Phone : 	+44 (0)1246-293761
Block A, 1st Floor	Postline : 5453-3761
St. Mary's Court		Fax : 	+44 (0)1246-293751
St. Mary's Gate
Chesterfield
S41 7TD

Public Key Validation String : MXZQ-7MM5-9A58