Subject: Document Action: Use of the KEA and SKIPJACK Algorithms in CMS to Informational

From: The IESG <[email-masked]>
Date: Wed, 31 May 2000 09:50:02 -0400

The IESG has approved the Internet-Draft 'Use of the KEA and SKIPJACK
Algorithms in CMS' <draft-ietf-smime-cmskea-05.txt> as a
Informational.  This document is the product of the S/MIME Mail
Security Working Group.  The IESG contact persons are Jeffrey Schiller
and Marcus Leech.

From: "Rob Saky" <[email-masked]>
Subject: FREE INFORMATION # DED
To: [email-masked]
Date: Wed, 31 May 2000 21:25:21 -0500
Sender: [email-masked]

    HOW TO SUBSTANTIALLY INCREASE SALES:

Easily accept major credit cards right away!

******Act now and all App. & Processing fees waived*****

call our (888) 363-7881 now! Our courteous customer care reps.
are anxious to help you get your merchant account today.

Merchant Status will help you increase sales by an
incredible 50% to 400%. Stop losing valuable sales!

With one phone call you can be:

Accepting all major credit cards!

Accepting checks over the net or by Fax!

Accepting real time processing for member sites!

Gaining customer loyalty and trust!

Close the sale now. No more wondering if "The check
is in the mail"

We specialize in helping those entrepreneurs whom
are just starting out: no credit, poor credit, or
even if you have great credit.

Almost everyone is approved!

For the next 5 days we will waive all app. and processing
fees! (Other companies charge $200 to $500 to set up)

In Business since 1992

Call us today @ 1 (888) 363-7881 and ask for extension FBK for free
setup!

****************************************************
If you have received this message in error, please
remove at:
mailto:[email-masked]?subject=remove
****************************************************

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Document Action: Use of the KEA and SKIPJACK Algorithms in CMS to Informational
Date: Wed, 31 May 2000 09:50:02 -0400
Sender: [email-masked]

The IESG has approved the Internet-Draft 'Use of the KEA and SKIPJACK
Algorithms in CMS' <draft-ietf-smime-cmskea-05.txt> as a
Informational.  This document is the product of the S/MIME Mail
Security Working Group.  The IESG contact persons are Jeffrey Schiller
and Marcus Leech.

From: "Frank O'Dwyer" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: RE: Border directories
Date: Tue, 30 May 2000 13:34:48 +0100
Importance: Normal
Disposition-Notification-To: "Frank O'Dwyer" <[email-masked]>
Sender: [email-masked]

> I wouldn't say we do hardwiring; it's more like seeing a URL on TV and
> typing it into a browser :-).  When users register for a DoD
> certificate, they get an instruction sheet for adding the DoD root and
> finding the directory.

That does seem to be the only way to do it at present. However, it also
sounds like it has severe scaling problems for users who need to work with
many disjoint directories. Presumably if there is no mapping from email
address to directory server, then it is necessary to look in them all. That
has to be a big performance hit (for the LDAP servers concerned). It also
unnecessarily leaks information about who is communicating with whom. Even a
simple convention such as having clients attempt a lookup for
[email-masked] by connecting to ldap.company.com would go a long way to
address that (even if it is a bit of a kludge).

Cheers,
Frank.

> Coordination from the DoD to other directories is not complete, but
> people are working on it.
> See http://www.fts.gsa.gov/html/fedware/Govt_OnlineDirectories.html.
>
> Dave
>
>
>
> > From: "Frank O'Dwyer" <[email-masked]>
> >
> > Bob Jueneman wrote:
> > >3.  The much more significant point, unless I've overlooked a
> > >"directoryCapabilities"  attribute in the S/MIME spec
> somewhere , is that
> > >both the originating and receiving application are completely clueless
> > >as to where to find either the directory itself, or the http provider.
> >
> > I had been wondering how S/MIME addressed mapping of an email
> address to a
> > directory server address. From the sound of this thread, I
> guess it doesn't.
> > So how are people doing this in practice? Is everyone setting up an LDAP
> > directory, then ignoring it and exchanging certificates by
> email? Or just
> > hardwiring a few LDAP servers into client configs?
> >
> > Cheers,
> > Frank O'Dwyer
> > [email-masked]
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.145 / Virus Database: 69 - Release Date: 5/4/00
>
---
Outgoing mail has been scanned for viruses.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.145 / Virus Database: 69 - Release Date: 5/4/00

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-domsec-05.txt
Date: Tue, 30 May 2000 06:34:53 -0400
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		: Domain Security Services using S/MIME
	Author(s)	: T. Dean, W. Ottaway
	Filename	: draft-ietf-smime-domsec-05.txt
	Pages		: 8
	Date		: 26-May-00
	
This document describes how the S/MIME protocol can be processed and
generated by a number of components of a communication system, such as
message transfer agents, guards and gateways to deliver security
services. These services are collectively referred to as 'Domain
Security Services'. The mechanisms described in this document are
designed to solve a number of interoperability problems and technical
limitations that arise when different security domains wish to
communicate securely, for example when two domains use incompatible
messaging technologies such as X.400 and SMTP/MIME, or when a single 
domain wishes to communicate securely with one of its members residing
on an untrusted domain. The scenarios covered by this document are
domain to domain, individual to domain and domain to individual
communications. This document is also applicable to organisations and
enterprises that have internal PKIs which are not accessible by the
outside world, but wish to interoperate securely using the S/MIME
protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-domsec-05.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-domsec-05.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-domsec-05.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-domsec-05.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 26 May 2000 14:33:20 -0400
To: William Whyte <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-smime-idea-04.txt: parameters question
Cc: [email-masked]
Sender: [email-masked]

I agree.  This was probably follows SKIPJACK.  In that case, they are 
including the SEQUENCE wrapper for compatibility with another 
environment.  Here, I am unaware of any compatibility requirement.

SKIPJACK uses:

         Skipjack-Parm ::= SEQUENCE { initialization-vector   OCTET STRING }

I suggest that IDEA should use:

         IDEA-CBC-IV ::=  OCTET STRING  -- must be 8 octets

Russ

P.S.  Authors, please consider this to be a Last Call comment.

At 04:44 PM 05/25/2000 +0100, William Whyte wrote:
>The IDEA in CMS draft specifies the parameters as follows:
>
>   IDEA-CBCPar ::= SEQUENCE {
>     IV  OCTET STRING OPTIONAL -- exactly 8 octets }
>
>Is there a good reason for the SEQUENCE wrapping? We already
>have a CBCParameter structure defined in RFC 2630, and it
>seems a shame to be inventing a slightly-differently-shaped
>wheel.
>
>Cheers,
>
>William

Date: Fri, 26 May 2000 12:23:33 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: WG LAST CALL: draft-ietf-smime-idea-04.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

The IDEA algorithm document, draft-ietf-smime-idea-04.txt, is ready for 
S/MIME WG Last Call.  This document is slated to become an informational 
RFC.  Last Call will end on 12 June 2000.

	Title		: Use of the IDEA Encryption Algorithm in CMS	
         Author(s)	: S. Teiwes, P. Hartmann, D. Kuenzi
	Filename	: draft-ietf-smime-idea-04.txt
	Pages		: 6
	Date		: 22-May-00

Please note that an statement regarding IDEA and patents has been posted at 
http://www.ietf.org/ipr.html.
	
Happy reading,
    Russ

Date: Thu, 25 May 2000 14:39:25 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Border directories
To: [email-masked]
Content-MD5: oz/RB+nFzxs/srk0673F5g==
Sender: [email-masked]

I wouldn't say we do hardwiring; it's more like seeing a URL on TV and
typing it into a browser :-).  When users register for a DoD
certificate, they get an instruction sheet for adding the DoD root and
finding the directory.

Coordination from the DoD to other directories is not complete, but
people are working on it.
See http://www.fts.gsa.gov/html/fedware/Govt_OnlineDirectories.html.

Dave

> From: "Frank O'Dwyer" <[email-masked]>
> 
> Bob Jueneman wrote:
> >3.  The much more significant point, unless I've overlooked a
> >"directoryCapabilities"  attribute in the S/MIME spec somewhere , is that
> >both the originating and receiving application are completely clueless
> >as to where to find either the directory itself, or the http provider.
> 
> I had been wondering how S/MIME addressed mapping of an email address to a
> directory server address. From the sound of this thread, I guess it doesn't.
> So how are people doing this in practice? Is everyone setting up an LDAP
> directory, then ignoring it and exchanging certificates by email? Or just
> hardwiring a few LDAP servers into client configs?
> 
> Cheers,
> Frank O'Dwyer
> [email-masked]

From: William Whyte <[email-masked]>
To: [email-masked]
Subject: draft-ietf-smime-idea-04.txt: parameters question
Date: Thu, 25 May 2000 16:44:18 +0100
Sender: [email-masked]

The IDEA in CMS draft specifies the parameters as follows:

  IDEA-CBCPar ::= SEQUENCE {
    IV  OCTET STRING OPTIONAL -- exactly 8 octets }

Is there a good reason for the SEQUENCE wrapping? We already 
have a CBCParameter structure defined in RFC 2630, and it
seems a shame to be inventing a slightly-differently-shaped
wheel.

Cheers,

William

From: "Frank O'Dwyer" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Border directories
Date: Thu, 25 May 2000 11:54:53 +0100
Importance: Normal
Disposition-Notification-To: "Frank O'Dwyer" <[email-masked]>
Sender: [email-masked]

Bob Jueneman wrote:
>3.  The much more significant point, unless I've overlooked a
>"directoryCapabilities"  attribute in the S/MIME spec somewhere , is that
>both the originating and receiving application are completely clueless
>as to where to find either the directory itself, or the http provider.

I had been wondering how S/MIME addressed mapping of an email address to a
directory server address. From the sound of this thread, I guess it doesn't.
So how are people doing this in practice? Is everyone setting up an LDAP
directory, then ignoring it and exchanging certificates by email? Or just
hardwiring a few LDAP servers into client configs?

Cheers,
Frank O'Dwyer
[email-masked]

---
Outgoing mail has been scanned for viruses.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.145 / Virus Database: 69 - Release Date: 5/4/00

Date: Tue, 23 May 2000 10:26:31 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Border directories
To: [email-masked]
Content-MD5: +Os8NFXnHjLZTpqzx2st+A==
Sender: [email-masked]

I acknowledge that one can shift complexity around in any system,
and that by both eliminating options and shifting processing to
a server, one can make a small client that does just one thing, and
even succeeds in doing it some of the time.

But to eliminate the ESP that Bob referred to (given an email address,
how does the client devine which RDBMS to query for a cert?) one needs
a client that talks not only HTTP or SMTP but also BIND.  That's another
several lines to your 10 line client.  It also assumes that
everyone:
 1) stands up an HTTP-accessible RDBMS to serve certificates,
   including populating the RDBMS when the directory backend
   is only usable through a directory interface, and
 2) populates SRV records in the DNS to point to the HTTP/RDBMS server.

The alternative, of course, is to talk to the directory directly.  I
couldn't accept the assertion that a "Lightweight" client is 1MB,
so last night I did an experiment of pruning out some unused code
from an OpenLDAP client.  The result is a 54KB executable that can
fetch any LDAP attribute (not just certificates) using any search
criteria (not just email address), including wildcards.
Code mailed on request.

54 KB is within the realm of what could be called Lightweight. With a
few more hours of surgery (which I have no intention of pursuing) it
might get down to half that, or less if the client already includes a
BER library (which it will if it actually uses the certificate for
anything :-).

The best part is that LDAP uses the infrastructure which is already
in place, rather than requiring everyone to stand up Something Else.

Dave

> From: [email-masked] (Peter Gutmann)
> Date: Sat, 13 May 2000 05:36:15 (NZST)
>
>   ...
> 
> Every RDBMS vendor on the planet either has or is making their database
> web-aware (although for security purposes I'd prefer to stick my own stub in
> front of it because I don't trust anyone to get things like this right :-).
> The interface is incredibly trivial, using a speed-optimised database like
> MySQL (which doesn't have a "lightweight" client like, say, Oracle), the 
> server stub isn't more than a page or two of code (bind to a socket, read
> requests, drop them into a line of SQL, then call mysql_query() and 
> mysql_use_result()/fetch_row() and send the result back to the caller.  I'm
> sure I could crank it out in a hour or so (although MySQL does have web glue
> built in if you want to go that way and use the native capabilities).
> 
> Total extra overhead in the client (assuming it already speaks SMTP, which 
> one can probably assume for a mail client): One read and one write call.
> 
> Total overhead in the server: An accept(), a read, the aforementioned RDBMS
> glue code, and a write for the results.
> 
> You can even use the standard dictionary definition of lightweight to desribe 
> that.  It makes for a very nice, simple "gimme a cert" protocol without the
> bloat and overhead of other alternatives.
> 
> Peter.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-idea-04.txt
Date: Tue, 23 May 2000 06:35:56 -0400
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		: Use of the IDEA Encryption Algorithm in CMS	 
        Author(s)	: S. Teiwes, P. Hartmann, D. Kuenzi
	Filename	: draft-ietf-smime-idea-04.txt
	Pages		: 6
	Date		: 22-May-00
	
This memo specifies how to incorporate IDEA (International Data
Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as 
an additional strong algorithm for symmetric encryption. For 
organizations who make use of IDEA for data security purposes 
it is of high interest that IDEA is also available in S/MIME. 
The intention of this memo is to provide the OIDs and algorithms 
required that IDEA can be included in S/MIME for symmetric content
and key encryption.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-04.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-04.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-04.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-04.txt

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

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

--OtherAccess--

--NextPart--

From: "Wendy Steiner" <[email-masked]>
Subject: A Must See #2199
To: op29s
Date: Sun, 21 May 2000 18:18:47 -0500
Sender: [email-masked]

Start your own 1-900 business or Adult Web Site Business!

People are making $$$ week, after week in the 1-900 business.  We'll
teach you all of our incredible secrets that will take your new
exciting business to a whole new level!

It's The Simplest and Most Exciting Business You Could Ever Start!

*You'll use our "state" of the art equipment!
*You'll use our "Live 1 on 1 Psychics" & "Chat Line" girls!
*You'll use our incredible Date Line program(s)!

No chargebacks! 
Quick payouts! 
No expertise needed!

Complete programs start at only $99 (no additional charges)

The only thing you'll have to do is advertise! This is an excellent 
turnkey business.

We also have excellent turnkey programs if you want to own your own 
"top" of the line adult web site.

ACT NOW!!!

For a free color brochure:
reply to: mailto:[email-masked]?subject=brochure
With the following information:

          Name:_________________
       Address:_________________
City/State/Zip:_________________
 email address:_________________
     Telephone:_________________ (optional)

///////////////////////////////////////////////////
To be removed permanantly from this list reply to:
mailto:[email-masked]?subject=remove
///////////////////////////////////////////////////

From: "Karl Serny" <[email-masked]>
Subject: You Can Win... # 37B
To: [email-masked]
Date: Fri, 19 May 2000 23:02:17 -0500
Sender: [email-masked]

Are you interested in increasing your odds in
winning a lottery?  To find out how, reply to:
mailto:[email-masked]?subject=How_to_win
We will only respond if all of the
information below is completed.
Thanks for your time.

Name: _________________________________________

Email Address: __________________________________

Address __________________________________________

City ________________________ ST _____ ZIP __________

Phone  (_______)  ______________________Best time to call.

*****************************************************************
This message is sent in compliance of the new email bill section 301.
PerSection 301, Paragraph (a)(2)(C) of S. 1618, further transmissions
to
you by the sender of this email may be stopped
at no cost to you. This message is not intended for residents in
the State of WA, CA & VA Screening of addresses has been
done to the best of our technical ability.  If you are a Washington,
Virginia, or California resident please remove yourself.
=================================================================
If you wish to be removed from future mailings,
please Reply to:mailto:[email-masked]?subject=remove

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-certdist-05.txt
Date: Fri, 19 May 2000 06:51:59 -0400
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		: Certificate Distribution Specification
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-certdist-05.txt
	Pages		: 20
	Date		: 18-May-00
	
Current methods of publishing certificates in directory services are
restricted to just certificates.  This document provides a method of
publishing certificates with secondary support information such as
the SMimeCapabilities attribute (containing bulk algorithm support)
in a way that is both authenticated and bound to a given
certificate.
This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[email-masked]> with
the single word 'subscribe' in the body of the message.  Also, 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-certdist-05.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-certdist-05.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-certdist-05.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-certdist-05.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 18 May 2000 10:54:13 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Cert Dist Changes
To: [email-masked], [email-masked]
Content-MD5: w1MWkw8LYbFIlVAPH9/bVQ==
Sender: [email-masked]

Jim,

If the new draft specifies that the userSmimeCertificate LDAP attribute
contains either user certificates or CA certificates, it is in conflict
with the PKIX directory schema.  *No* certificates should appear in this
attribute, *All* certificates should be populated in the standard PKIX
locations: userCertificate and caCertificate.

Size considerations are a very minor concern to me, although the size
difference between "smimeCapabilities only" and "smimeCapabilities +
full cert path" is significant.  The major concern is the duplication
of data, and the corresponding likelihood that the data will get out of
sync.  If you believe that it is too difficult to fetch certificates
from the directory when formatting a CertDist object for http
retrieval, or alternatively stripping the cert path out when populating
the CertDist object as a directory attribute,  then you certainly must
not be inclined to check CertDist objects which contain certificates
for consistency with the certs already in the userCertificate and
caCertificate attributes of the directory.

SMIME LDAP attribute definitions must be compatible with and
non-duplicative of PKIX LDAP attribute definitions.  Until that is the
case with Certdist, I will continue to oppose its approval as an RFC.

Regards,
Dave

> From: "Jim Schaad" <[email-masked]>
> To: [email-masked]
> Date: Wed, 17 May 2000 21:41:41 +0800
> Subject: Cert Dist Changes
> X-User-Info: 131.107.3.84
> 
> Since I have been out of touch and have not be able to respond well to 
comments
> on this draft, I will attempt to summerize the comments in this message as 
well
> as the action that I have taken about them.  A new draft is on the way to the
> editors at the same time as this message went out.
> 
> 1.  LDAP was not understandable as writen.  I have changed to using the LDAP
> v2 rather than LDAP v3 descriptions so that they look more like what people
> understand.  It is perfectly possible that I did not understand what the v3
> docs were trying to do and so got the v3 schema completely wrong.
> 
> 2.  May omit user's certificate if publishing to LDAP.  This is the one with
> the most traffic.  The arguments that I have found are:
> 
> a)  The document should be modified so that the text states that the 
certificate
> MUST NOT appear in an LDAP entry.
> 
> - I don't like the text MUST NOT.  It is quite possible that when I prepare
> a CertDist object for publication I don't know where it will appear or it may
> appear in multiple places.  Putting the MUST NOT text in says that I need to
> either be able to manipulate the object at publication time or potentially 
start
> creating multiple objects.  Note this goes in the opposite direction as well,
> something move the attribute from LDAP to http get would need to insert the
> certificate.
> 
> b)  The document does not say what do to in the absence of the property.
> 
> - I don't believe the document needs to discuss other ways of obtaining 
certificates.
>  More specifically the text to deal with this is very LDAP specific and I 
don't
> want to tie the document any closer to LDAP than necessary.
> 
> c)  Need to look at two attributes to find the certificates.
> 
> - Given the relative time involved, I think that most applications are going
> to pull down multiple attributes at once in any event.  The time involved in
> pulling down extra bytes vs the time involved in establishing and re-querying
> to get the correct result seems to me to indicate that all possible attributes
> should be pulled at once if you even suspect that you might need this.  From
> my days at Microsoft one of the worse things to do for performance was to ask
> anything new of the directory or message store.  The cost of doing one extra
> RPC was just a killer.
> 
> d)  Does not work with existing code bases as currently written.
> 
> - We are writing standards not documenting existing code.  This implies that
> we need to do things right and not just document things that are wrong but 
already
> in use.
> 
> 
> RESULT:
> 
> I have pulled the MAY text from the document for the following reasons:
> 1.  The reason it was put in was to deal with size issues in the directory.
>  After looking at this, the savings from not having the end-entity certificate
> duplicated in a single directory entry, but still having the entire chain of
> certificates above it duplicated in every end-entity record just seems a bit
> extreme.  It would be possible for a server which really cared about space to
> do this operation itself, and do the space savings on chaining certificates
> as well.
> 
> 2.  The difficulty of moving an item from an LDAP to a non-LDAP location where
> the certificate is inserted or removed as appropriate seems to be a killer 
type
> problem.
> 
> If the searching abilities are not present, then we need to look at how to add
> them to the document, but I will need help from some real LDAP people on how
> to do this.  Please provide me with the necessary set of text and references
> so that I can understand what you have suggested.
> 
> jim
> http://www.nwlink.com
> 
> 
> *****************************************************************************
> This confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> ******************************************************************************

From: "Jim Schaad" <[email-masked]>
Reply-to: [email-masked]
To: [email-masked]
Date: Wed, 17 May 2000 21:41:41 +0800
Subject: Cert Dist Changes
Sender: [email-masked]

Since I have been out of touch and have not be able to respond well to comments
on this draft, I will attempt to summerize the comments in this message as well
as the action that I have taken about them.  A new draft is on the way to the
editors at the same time as this message went out.

1.  LDAP was not understandable as writen.  I have changed to using the LDAP
v2 rather than LDAP v3 descriptions so that they look more like what people
understand.  It is perfectly possible that I did not understand what the v3
docs were trying to do and so got the v3 schema completely wrong.

2.  May omit user's certificate if publishing to LDAP.  This is the one with
the most traffic.  The arguments that I have found are:

a)  The document should be modified so that the text states that the certificate
MUST NOT appear in an LDAP entry.

- I don't like the text MUST NOT.  It is quite possible that when I prepare
a CertDist object for publication I don't know where it will appear or it may
appear in multiple places.  Putting the MUST NOT text in says that I need to
either be able to manipulate the object at publication time or potentially start
creating multiple objects.  Note this goes in the opposite direction as well,
something move the attribute from LDAP to http get would need to insert the
certificate.

b)  The document does not say what do to in the absence of the property.

- I don't believe the document needs to discuss other ways of obtaining certificates.
 More specifically the text to deal with this is very LDAP specific and I don't
want to tie the document any closer to LDAP than necessary.

c)  Need to look at two attributes to find the certificates.

- Given the relative time involved, I think that most applications are going
to pull down multiple attributes at once in any event.  The time involved in
pulling down extra bytes vs the time involved in establishing and re-querying
to get the correct result seems to me to indicate that all possible attributes
should be pulled at once if you even suspect that you might need this.  From
my days at Microsoft one of the worse things to do for performance was to ask
anything new of the directory or message store.  The cost of doing one extra
RPC was just a killer.

d)  Does not work with existing code bases as currently written.

- We are writing standards not documenting existing code.  This implies that
we need to do things right and not just document things that are wrong but already
in use.

RESULT:

I have pulled the MAY text from the document for the following reasons:
1.  The reason it was put in was to deal with size issues in the directory.
 After looking at this, the savings from not having the end-entity certificate
duplicated in a single directory entry, but still having the entire chain of
certificates above it duplicated in every end-entity record just seems a bit
extreme.  It would be possible for a server which really cared about space to
do this operation itself, and do the space savings on chaining certificates
as well.

2.  The difficulty of moving an item from an LDAP to a non-LDAP location where
the certificate is inserted or removed as appropriate seems to be a killer type
problem.

If the searching abilities are not present, then we need to look at how to add
them to the document, but I will need help from some real LDAP people on how
to do this.  Please provide me with the necessary set of text and references
so that I can understand what you have suggested.

jim
http://www.nwlink.com

From: "John Ross" <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: "s/mime list" <[email-masked]>
Subject: Fw:      ETSI ES 201 733 Electronic Signature Formats
Date: Mon, 15 May 2000 16:07:05 +0100
Sender: [email-masked]

Russ & all

The ETSI document on Electronic Signature Formats and Signature Policies is
now an approved ETSI document, see the  ETSI El Sign Website

http://www.etsi.org/sec/el-sign.htm

The ASN.1 has been split into four modules, two for Electronic Signature
Formats and two for Electronic Signature Policies. I intend to divide the
current IETF draft text along the same lines and have another version of the
IETF document ready in a couple of weeks.

Regards

John Ross
-----Original Message-----
From: Harri Rasilainen <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 15 May 2000 08:56
Subject: ETSI ES 201 733 Electronic Signature Formats

>Dear all,
>The ETSI ES 201 733 Electronic Signature Formats standard has been approved
>and
>published.
>To ensure there are no copyright issues in the final published version,
>where text from RFC was previously duplicated in draft ETSI ES 201 733,
such
>text has
>now been incorporated by reference.
>The standard is available from the ETSI web site:
>http://webapp.etsi.org/pda/
>
>and the ETSI El Sign Website
>http://www.etsi.org/sec/el-sign.htm
>
>
>Best regards,
>Harri Rasilainen
>ETSI Technical Officer - SEC, TETRA and SAGE
>Tel: +33 6 87 69 12 51
>
>Technical news from ETSI:
> http://www.etsi.org/tbnews/ta_news.htm
>

From: "Wellington Alencar" <[email-masked]>
To: <[email-masked]>
Subject: S/MIME
Date: Mon, 15 May 2000 10:33:58 -0000
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01BFBE59.13BBBA20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I=B4m doing a homework about S/MIME, but I have problems...Can you help =
me ?
I need a chart about S/MIME.Do you Know where Can I find ?

Thank=B4s

Wellington
Brazil

------=_NextPart_000_0009_01BFBE59.13BBBA20
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.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>Hi,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>I=B4m doing a homework about S/MIME, but I have =
problems...Can=20
you help me ?</FONT></DIV>
<DIV><FONT size=3D2>I need a chart about S/MIME.Do you Know where Can I =
find=20
?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Thank=B4s</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Wellington</FONT></DIV>
<DIV><FONT size=3D2>Brazil</FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0009_01BFBE59.13BBBA20--

From: Jeff Tozzi <[email-masked]>
To: "'Andrew Ferguson'" <[email-masked]>
Cc: [email-masked]
Subject: RE: S/MIME v3 plus ESS
Date: Mon, 15 May 2000 01:52:20 -0700
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFBE4A.E128AD60
Content-Type: text/plain;
	charset="ISO-8859-1"

Andrew,
 
Microsoft has an in-production version of S/MIME v3 ESS with their release
of Outlook 2000 SR1 (released March 2000).
 
Jeff
 
Jeff Tozzi
Program Manager
Microsoft
425-705-8060
 <mailto:[email-masked]> [email-masked] 

 -----Original Message-----
From: Andrew Ferguson [mailto:[email-masked]]
Sent: Monday, May 15, 2000 12:28 AM
To: [email-masked]
Subject: S/MIME v3 plus ESS

Can any one tell me if they know of in production versions of S/MIMEv3 plus
ESS for Novell Groupwise, Lotus Notes and Microsoft Outlook (97 and 2000)

Thanks 
Andrew Ferguson 
--- 
Software Agencies Australia Pty Ltd (SAA)
ACN 078 025 813 
1 Huntingdale Road 
Burwood 
3125 Victoria 
Australia 

Tel: +61-3-9831-6666 
Fax: +61-3-9831-6624
Mob: +61-41-222-3940 
Email: [email-masked] 
URL:  <http://www.software-aus.com.au/> www.software-aus.com.au 
Offices in: Melbourne and Singapore (Software Agencies Asia). 
Resellers in: Canberra, Brisbane, Gold Coast, Adelaide, Sydney, Wellington,
Auckland, Taipei and Kuala Lumpur. 

Your business integration partner for Internet Commerce, Messaging ,
Directories and Public Key Infrastructure security - give us a call we would
love to help you with Internet Commerce. 
---- 
The Information contained in this E-Mail and any subsequent  correspondence
is private and is intended solely for the intended recipient(s).  For those
other than the intended recipient any 
disclosure, copying, distribution, or any action taken or omitted to be
taken in reliance on such information is prohibited and may be unlawful. 

Virus Disclaimer: It is the recipient's duty to virus scan or otherwise test
this Email before loading it onto any computer. Software Agencies Australia
make every effort to ensure that no viruses are attached to this email
however no warranty is given by Software Agencies Australia that this Email
is free from computer viruses or any other defect or error. Software
Agencies Australia is not liable for any loss or damage incurred by any
person loading this Email or if liable Software Agencies Australia's
obligation will be limited to retransmitting this email to the intended
recipient.

------_=_NextPart_001_01BFBE4A.E128AD60
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">

<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=594504608-15052000>Andrew,</SPAN></FONT></DIV>
<DIV><SPAN class=594504608-15052000></SPAN><FONT color=#0000ff face=Arial 
size=2>&nbsp;</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=594504608-15052000>Microsoft has an in-production version of S/MIME v3 ESS 
with their release of Outlook 2000 SR1 (released March 
2000).</SPAN></FONT></DIV>
<DIV><SPAN class=594504608-15052000></SPAN><FONT color=#0000ff face=Arial 
size=2>&nbsp;</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=594504608-15052000>Jeff</SPAN></FONT></DIV>
<DIV><SPAN class=594504608-15052000></SPAN><FONT color=#0000ff face=Arial 
size=2>&nbsp;</FONT></DIV>
<DIV><EM><FONT color=#0000ff face=Arial size=2><SPAN 
class=594504608-15052000>Jeff Tozzi</SPAN></FONT></EM></DIV>
<DIV><EM><FONT color=#0000ff face=Arial size=2><SPAN 
class=594504608-15052000>Program Manager</SPAN></FONT></EM></DIV>
<DIV><EM><FONT color=#0000ff face=Arial size=2><SPAN 
class=594504608-15052000>Microsoft</SPAN></FONT></EM></DIV>
<DIV><EM><FONT color=#0000ff face=Arial size=2><SPAN 
class=594504608-15052000>425-705-8060</SPAN></FONT></EM></DIV>
<DIV><SPAN class=594504608-15052000><A href="mailto:[email-masked]"><FONT 
face=Arial size=2><EM>[email-masked]</EM></FONT></A><FONT color=#0000ff 
face=Arial size=2><SPAN 
class=208395108-15052000>&nbsp;</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=594504608-15052000><FONT color=#0000ff face=Arial size=2><SPAN 
class=208395108-15052000></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=594504608-15052000><FONT color=#0000ff face=Arial size=2><SPAN 
class=208395108-15052000><BR>&nbsp;</SPAN></FONT></SPAN><FONT face=Tahoma><FONT 
size=2>-----Original Message-----<BR><B>From:</B> Andrew Ferguson 
[mailto:[email-masked]]<BR><B>Sent:</B> Monday, May 15, 
2000 12:28 AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> S/MIME v3 
plus ESS<BR><BR></DIV></FONT></DIV>
<BLOCKQUOTE></FONT>
  <DIV>Can any one tell me if they know of in production versions of S/MIMEv3 
  plus ESS for Novell Groupwise, Lotus Notes and Microsoft Outlook (97 and 
  2000)</DIV><BR>
  <DIV>Thanks </DIV>Andrew Ferguson <BR>--- <BR><FONT color=#008000 
  size=4><B>Software Agencies Australia Pty Ltd (SAA)<BR></FONT></B>ACN 078 025 
  813 <BR>1 Huntingdale Road <BR>Burwood <BR>3125 Victoria <BR>Australia 
  <BR><BR>Tel: +61-3-9831-6666 <BR>Fax: +61-3-9831-6624<BR>Mob: +61-41-222-3940 
  <BR>Email: [email-masked] <BR>URL: <A 
  href="http://www.software-aus.com.au/" eudora="autourl"><FONT 
  size=4><B>www.software-aus.com.au</A> <BR></FONT></B>Offices in:<FONT size=4> 
  </FONT>Melbourne and Singapore (Software Agencies Asia). <BR><B>Resellers 
  in:<FONT size=4> </FONT></B>Canberra, Brisbane, Gold Coast, Adelaide, Sydney, 
  Wellington, Auckland, Taipei and Kuala Lumpur. <BR><BR><B>Your business 
  integration partner for Internet Commerce, Messaging , Directories and Public 
  Key Infrastructure security - give us a call we would love to help you with 
  Internet Commerce. <BR><FONT color=#ff0000>---- <BR></FONT></B><FONT 
  size=2>The Information contained in this E-Mail and any subsequent&nbsp; 
  correspondence is private and is intended solely for the intended 
  recipient(s).&nbsp; For those other than the intended recipient any 
  <BR>disclosure, copying, distribution, or any action taken or omitted to be 
  taken in reliance on such information is prohibited and may be unlawful. 
  <BR><BR></FONT>Virus Disclaimer: It is the recipient's duty to virus scan or 
  otherwise test this Email before loading it onto any computer. Software 
  Agencies Australia make every effort to ensure that no viruses are attached to 
  this email however no warranty is given by Software Agencies Australia that 
  this Email is free from computer viruses or any other defect or error. 
  Software Agencies Australia is not liable for any loss or damage incurred by 
  any person loading this Email or if liable Software Agencies Australia's 
  obligation will be limited to retransmitting this email to the intended 
  recipient.<BR><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFBE4A.E128AD60--

Date: Mon, 15 May 2000 17:27:49 +1000
To: [email-masked]
From: Andrew Ferguson <[email-masked]>
Subject: S/MIME v3 plus ESS
Sender: [email-masked]

--=====================_6357582==_.ALT
Content-Type: text/plain; charset="us-ascii"

Can any one tell me if they know of in production versions of S/MIMEv3 plus ESS
for Novell Groupwise, Lotus Notes and Microsoft Outlook (97 and 2000)

Thanks 
Andrew Ferguson 
--- 
Software Agencies Australia Pty Ltd (SAA)
ACN 078 025 813 
1 Huntingdale Road 
Burwood 
3125 Victoria 
Australia 

Tel: +61-3-9831-6666 
Fax: +61-3-9831-6624
Mob: +61-41-222-3940 
Email: [email-masked] 
URL: www.software-aus.com.au 
Offices in: Melbourne and Singapore (Software Agencies Asia). 
Resellers in: Canberra, Brisbane, Gold Coast, Adelaide, Sydney, Wellington,
Auckland, Taipei and Kuala Lumpur. 

Your business integration partner for Internet Commerce, Messaging ,
Directories and Public Key Infrastructure security - give us a call we would
love to help you with Internet Commerce. 
---- 
The Information contained in this E-Mail and any subsequent  correspondence is
private and is intended solely for the intended recipient(s).  For those other
than the intended recipient any 
disclosure, copying, distribution, or any action taken or omitted to be taken
in reliance on such information is prohibited and may be unlawful. 

Virus Disclaimer: It is the recipient's duty to virus scan or otherwise test
this Email before loading it onto any computer. Software Agencies Australia
make every effort to ensure that no viruses are attached to this email however
no warranty is given by Software Agencies Australia that this Email is free
from computer viruses or any other defect or error. Software Agencies Australia
is not liable for any loss or damage incurred by any person loading this Email
or if liable Software Agencies Australia's obligation will be limited to
retransmitting this email to the intended recipient.

--=====================_6357582==_.ALT
Content-Type: text/html; charset="us-ascii"

<html><div>Can any one tell me if they know of in production versions of
S/MIMEv3 plus ESS for Novell Groupwise, Lotus Notes and Microsoft Outlook
(97 and 2000)</div>
<br>
<div>Thanks </div>
Andrew Ferguson
<br>

--- <br>
<font size=4 color="#008000"><b>Software Agencies Australia Pty Ltd
(SAA)<br>
</font></b>ACN 078 025 813 <br>
1 Huntingdale Road <br>
Burwood <br>
3125 Victoria <br>
Australia <br>
<br>
Tel: +61-3-9831-6666 <br>
Fax: +61-3-9831-6624<br>
Mob: +61-41-222-3940 <br>
Email: [email-masked] <br>
URL:
<a href="http://www.software-aus.com.au/" eudora="autourl"><font size=4><b>www.software-aus.com.au</a>
<br>
</font></b>Offices in:<font size=4> </font>Melbourne and Singapore (Software Agencies Asia). <br>
<b>Resellers in:<font size=4> </font></b>Canberra, Brisbane, Gold Coast, Adelaide, Sydney, Wellington, Auckland, Taipei and Kuala Lumpur. <br>
<br>
<b>Your business integration partner for Internet Commerce, Messaging , Directories and Public Key Infrastructure security - give us a call we would love to help you with Internet Commerce. <br>
<font color="#FF0000">---- <br>
</font></b><font size=2>The Information contained in this E-Mail and any subsequent&nbsp; correspondence is private and is intended solely for the intended recipient(s).&nbsp; For those other than the intended recipient any <br>
disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. <br>
<br>
</font>Virus Disclaimer: It is the recipient's duty to virus scan or otherwise test this Email before loading it onto any computer. Software Agencies Australia make every effort to ensure that no viruses are attached to this email however no warranty is given by Software Agencies Australia that this Email is free from computer viruses or any other defect or error. Software Agencies Australia is not liable for any loss or damage incurred by any person loading this Email or if liable Software Agencies Australia's obligation will be limited to retransmitting this email to the intended recipient.<br>
<br>
</html>

--=====================_6357582==_.ALT--

From: [email-masked]
Date: Fri, 12 May 2000 21:59:56 -0800 (PST)
Subject: RE: Border directories
To: Philip Hallam-Baker <[email-masked]>
Cc: "'Bob Jueneman'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> Well this was actually my main point. I have been trying to persuade folk
> to take the SRV record seriously and use it for this purpose for two
> years...

> So what is stopping the email client application vendors?

The lack of any specification explaining how SRV could be used by email
clients might have something to do with it... And in the case of SMTP in
particular, the existance of a widely deployed viable alternative (MX records)
also plays a part.

The SRV record specification is quite clear: Actual use of SRV records for
specific protocols is beyond its scope. For that you need a SRV
profile/applicability statement.

If you see a useful application for SRV records in the email space (or any
other space for that matter) what's needed is a document describing that
usage, and I encourage you to write it out. This is what will persuade people
to use SRV records.

				Ned

From: Philip Hallam-Baker <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: Border directories
Date: Fri, 12 May 2000 17:13:01 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01BFBC4E.9C897BB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Bob said:

>3.  The much more significant point, unless I've overlooked a 
>"directoryCapabilities"  attribute in the S/MIME spec somewhere , is
that 
>both the originating and receiving application are completely clueless 
>as to where to find either the directory itself, or the http provider.

>Once I use mental telephathy to figure out the DSN name of the server 
>where the user chose to publish his certificates(s), then I can start
rummaging 
>around though either LDAP or HTTP, trying to guess the schema, and
which 
>index to use to locate that user's certificate.

>Those are the points we ought to be focussing on, IMHO.

Well this was actually my main point. I have been trying to persuade
folk 
to take the SRV record seriously and use it for this purpose for two
years...

So what is stopping the email client application vendors?

		Phill

------=_NextPart_000_0000_01BFBC4E.9C897BB0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0000_01BFBC4E.9C897BB0--

Date: Fri, 12 May 2000 17:36:16 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Border directories
Sender: [email-masked]

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_B5ED9D6D.395892DF
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Three brief technical points:

1.  At least with respect to Novell's 8th generation directory, NDS, LDAP =
is=20
an access protocol that is supported natively by the directory engine. =20
So you can use NDAP (Novell's variant of the standard X.500 DAP, for=20
reasons I won't go into), or you can use the not particularly light-weight,=
=20
but arguably light-functionality LDAP interface. It makes no difference to =
us,=20
as we support both.

2.  NDS is based on a Novell-proprietary "arbitrarily-structured data =
base",=20
NOT on an RDBMS.  That's why the directory is as small as it is, and =
yet=20
has the scalability and performance it does. Although other Novell =
applications=20
can use the same underlying database technology (the GroupWise message
server does), they do not share the same database.

So David's assumptions are incorrect, at least with respect to one =
major=20
DSA provider.  That's not to say that you couldn't publish certificates in =
a=20
web server and access them via http, independent of any directory.  You =
could. =20
You could even synchronize the web server and the directory using our=20
DirXML capability, if you chose to.  But you don't access the underlying=20=

database while it may be undergoing synchronization, replication, backup,
 repair, etc., etc., under the control of the higher level application, =
about=20
which the other application would know nothing.

3.  The much more significant point, unless I've overlooked a=20
"directoryCapabilities"  attribute in the S/MIME spec somewhere , is =
that=20
both the originating and receiving application are completely clueless=20
as to where to find either the directory itself, or the http provider.

Once I use mental telephathy to figure out the DSN name of the server=20
where the user chose to publish his certificates(s), then I can start =
rummaging=20
around though either LDAP or HTTP, trying to guess the schema, and =
which=20
index to use to locate that user's certificate.

Those are the points we ought to be focussing on, IMHO.

Bob

>>> Peter Gutmann <[email-masked]> 05/13/00 05:36AM >>>
"David P. Kemp" <[email-masked]> writes:

(Phew, back to technical discussions at last)...

>Aren't you leaving out both a block and an assumption in the HTTP path?
>
>The assumptions are that the DSA not only is based on an RDBMS but that =
the=20
>RDBMS interface is exposed to other applications.  If these assumptions =
are=20
>true, the paths would be more like:
>
>  client -> LDAP client -> LDAP server ---------\
>                                                 \
>                                                  RDBMS
>                                                 /
>  client -> HTTP GET -> Apache w/mod_perl & DBI-/

Why would you need to run Apache?  The model I was using was:

   client -> socket read -> server stub -> RDBMS

Every RDBMS vendor on the planet either has or is making their database
web-aware (although for security purposes I'd prefer to stick my own stub =
in
front of it because I don't trust anyone to get things like this right =
:-).
The interface is incredibly trivial, using a speed-optimised database like
MySQL (which doesn't have a "lightweight" client like, say, Oracle), =
the=20
server stub isn't more than a page or two of code (bind to a socket, read
requests, drop them into a line of SQL, then call mysql_query() and=20
mysql_use_result()/fetch_row() and send the result back to the caller.  =
I'm
sure I could crank it out in a hour or so (although MySQL does have web =
glue
built in if you want to go that way and use the native capabilities).

Total extra overhead in the client (assuming it already speaks SMTP, =
which=20
one can probably assume for a mail client): One read and one write call.

Total overhead in the server: An accept(), a read, the aforementioned =
RDBMS
glue code, and a write for the results.

You can even use the standard dictionary definition of lightweight to =
desribe=20
that.  It makes for a very nice, simple "gimme a cert" protocol without =
the
bloat and overhead of other alternatives.

Peter.

--=_B5ED9D6D.395892DF
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.2614.3401" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: =
2px">
<DIV><FONT size=3D2>Three brief technical points:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>1.&nbsp; At least with respect to Novell's 8th =
generation=20
directory, NDS, LDAP is </FONT></DIV>
<DIV><FONT size=3D2>an access protocol that is </FONT><FONT size=3D2>suppor=
ted=20
natively by the directory engine.&nbsp; </FONT></DIV>
<DIV><FONT size=3D2>So you can use NDAP (Novell's </FONT><FONT size=3D2>var=
iant of=20
the standard X.500 DAP, for </FONT></DIV>
<DIV><FONT size=3D2>reasons I won't go into), or you can use </FONT><FONT=
=20
size=3D2>the not particularly light-weight, </FONT></DIV>
<DIV><FONT size=3D2>but arguably light-functionality LDAP interface. =
</FONT><FONT=20
size=3D2>It makes no difference to us, </FONT></DIV>
<DIV><FONT size=3D2>as we support both.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>2.&nbsp; NDS is based on a Novell-proprietary=20
"arbitrarily-structured data base", </FONT></DIV>
<DIV><FONT size=3D2>NOT </FONT><FONT size=3D2>on an RDBMS.&nbsp; That's =
why the=20
directory is as small as it is, and yet </FONT></DIV>
<DIV><FONT size=3D2>has the scalability </FONT><FONT size=3D2>and =
performance it=20
does. Although other Novell applications </FONT></DIV>
<DIV><FONT size=3D2>can use the same underlying </FONT><FONT size=3D2>datab=
ase=20
technology (the GroupWise message</FONT></DIV>
<DIV><FONT size=3D2>server does), they do not share the same=20
database.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>So David's assumptions are incorrect, at least with =
respect to=20
one major </FONT></DIV>
<DIV><FONT size=3D2>DSA provider.&nbsp; </FONT><FONT size=3D2>That's not =
to say that=20
you couldn't publish certificates in a </FONT></DIV>
<DIV><FONT size=3D2>web server and access them via </FONT><FONT size=3D2>ht=
tp,=20
independent of any directory.&nbsp; You could.&nbsp; </FONT></DIV>
<DIV><FONT size=3D2>You could even synchronize the web server and the =
</FONT><FONT=20
size=3D2>directory using our </FONT></DIV>
<DIV><FONT size=3D2>DirXML capability, if you chose to.&nbsp; But you =
don't access=20
the underlying </FONT></DIV>
<DIV><FONT size=3D2>database while it may be undergoing synchronization,=20=

replication, backup,</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;repair, etc., </FONT><FONT size=3D2>etc., under =
the=20
control of the higher level application, about </FONT></DIV>
<DIV><FONT size=3D2>which the other application would </FONT><FONT =
size=3D2>know=20
nothing.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>3.&nbsp; The much more significant point, unless =
I've=20
overlooked a </FONT></DIV>
<DIV><FONT size=3D2>"directoryCapabilities"&nbsp; </FONT><FONT size=3D2>att=
ribute in=20
the S/MIME </FONT><FONT size=3D2>spec somewhere , is that </FONT></DIV>
<DIV><FONT size=3D2>both the originating and receiving application =
</FONT><FONT=20
size=3D2>are completely clueless </FONT></DIV>
<DIV><FONT size=3D2>as to <U>where to find </U>either the directory =
itself, or the=20
http provider.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Once I use mental telephathy to figure out the DSN =
name of the=20
server </FONT></DIV>
<DIV><FONT size=3D2>where </FONT><FONT size=3D2>the user chose to publish =
his=20
certificates(s), <U>then </U>I can start rummaging </FONT></DIV>
<DIV><FONT size=3D2>around though&nbsp;</FONT><FONT size=3D2>either =
LDAP=20
</FONT><FONT size=3D2>or HTTP, trying to guess the schema, and which =
</FONT></DIV>
<DIV><FONT size=3D2>index to use to locate </FONT><FONT size=3D2>that =
user's=20
</FONT><FONT size=3D2>certificate.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Those are the points we ought to be focussing on,=20
IMHO.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Bob</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt;&gt;&gt; Peter Gutmann &lt;[email-masked]&gt; =
05/13/00=20
05:36AM &gt;&gt;&gt;<BR>"David P. Kemp" &lt;[email-masked]&gt;=20
writes:<BR><BR>(Phew, back to technical discussions at=20
last)...<BR><BR>&gt;Aren't you leaving out both a block and an assumption =
in the=20
HTTP path?<BR>&gt;<BR>&gt;The assumptions are that the DSA not only is =
based on=20
an RDBMS but that the <BR>&gt;RDBMS interface is exposed to other=20
applications.&nbsp; If these assumptions are <BR>&gt;true, the paths would =
be=20
more like:<BR>&gt;<BR>&gt;&nbsp; client -&gt; LDAP client -&gt; LDAP =
server=20
---------\<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
\<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
RDBMS<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
/<BR>&gt;&nbsp; client -&gt; HTTP GET -&gt; Apache w/mod_perl &amp;=20
DBI-/<BR><BR>Why would you need to run Apache?&nbsp; The model I was =
using=20
was:<BR><BR>&nbsp;&nbsp; client -&gt; socket read -&gt; server stub =
-&gt;=20
RDBMS<BR><BR>Every RDBMS vendor on the planet either has or is making =
their=20
database<BR>web-aware (although for security purposes I'd prefer to stick =
my own=20
stub in<BR>front of it because I don't trust anyone to get things like =
this=20
right :-).<BR>The interface is incredibly trivial, using a speed-optimised=
=20
database like<BR>MySQL (which doesn't have a "lightweight" client like, =
say,=20
Oracle), the <BR>server stub isn't more than a page or two of code (bind =
to a=20
socket, read<BR>requests, drop them into a line of SQL, then call =
mysql_query()=20
and <BR>mysql_use_result()/fetch_row() and send the result back to the=20
caller.&nbsp; I'm<BR>sure I could crank it out in a hour or so (although =
MySQL=20
does have web glue<BR>built in if you want to go that way and use the =
native=20
capabilities).<BR><BR>Total extra overhead in the client (assuming it =
already=20
speaks SMTP, which <BR>one can probably assume for a mail client): One =
read and=20
one write call.<BR><BR>Total overhead in the server: An accept(), a read, =
the=20
aforementioned RDBMS<BR>glue code, and a write for the results.<BR><BR>You =
can=20
even use the standard dictionary definition of lightweight to desribe=20
<BR>that.&nbsp; It makes for a very nice, simple "gimme a cert" protocol =
without=20
the<BR>bloat and overhead of other=20
alternatives.<BR><BR>Peter.<BR><BR></DIV></BODY></HTML>

--=_B5ED9D6D.395892DF--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Border directories
Reply-To: [email-masked]
Date: Sat, 13 May 2000 05:43:42 (NZST)
Sender: [email-masked]

Colin Robbins <[email-masked]> writes:

>If anyone is interested in the technical reasons why a RDBMS is bad news for
>directory performance, then there is a white paper " Use of OODB Technology
>for Directories" written by an independent expert on our web site
>(http://www.nexor.com/info/papers.htm) that describes these problems in
>detail.

And OpenDirectory claim the exact opposite on their site :-).  I'm actually
surprised Alan Lloyd hasn't chimed in with his perspective on LDAP yet.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: Border directories
Reply-To: [email-masked]
Date: Sat, 13 May 2000 05:36:15 (NZST)
Sender: [email-masked]

"David P. Kemp" <[email-masked]> writes:

(Phew, back to technical discussions at last)...

>Aren't you leaving out both a block and an assumption in the HTTP path?
>
>The assumptions are that the DSA not only is based on an RDBMS but that the 
>RDBMS interface is exposed to other applications.  If these assumptions are 
>true, the paths would be more like:
>
>  client -> LDAP client -> LDAP server ---------\
>                                                 \
>                                                  RDBMS
>                                                 /
>  client -> HTTP GET -> Apache w/mod_perl & DBI-/

Why would you need to run Apache?  The model I was using was:

   client -> socket read -> server stub -> RDBMS

Every RDBMS vendor on the planet either has or is making their database
web-aware (although for security purposes I'd prefer to stick my own stub in
front of it because I don't trust anyone to get things like this right :-).
The interface is incredibly trivial, using a speed-optimised database like
MySQL (which doesn't have a "lightweight" client like, say, Oracle), the 
server stub isn't more than a page or two of code (bind to a socket, read
requests, drop them into a line of SQL, then call mysql_query() and 
mysql_use_result()/fetch_row() and send the result back to the caller.  I'm
sure I could crank it out in a hour or so (although MySQL does have web glue
built in if you want to go that way and use the native capabilities).

Total extra overhead in the client (assuming it already speaks SMTP, which 
one can probably assume for a mail client): One read and one write call.

Total overhead in the server: An accept(), a read, the aforementioned RDBMS
glue code, and a write for the results.

You can even use the standard dictionary definition of lightweight to desribe 
that.  It makes for a very nice, simple "gimme a cert" protocol without the
bloat and overhead of other alternatives.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: RE: Border directories
Reply-To: [email-masked]
Date: Sat, 13 May 2000 05:22:53 (NZST)
Sender: [email-masked]

"Walter Williams" <[email-masked]> writes:

>Lets kill this thread as it is getting us no where. 

I agree, any attempt at further debate seems pointless.  However, I'm willing 
to extend the following olive branch: I you can give me a 10-line RFC 1823-
compliant C program to fetch certificates from an LDAP directory as per your
previous message, then I'm prepared to admit that everything I've said is 
wrong and everything you've said (that all MTA's support LDAP and none of them
apparently support TCP/IP (which is what's required to do an HTTP GET), 
necessitating the use of an external web browser to fetch certs, etc etc) is 
right.  Deal?

(Incidentally, to the person who claimed that their <1MB LDAP client is
 "lightweight", you may have a future working for Oracle's marketing division,
 since their <1MB client is frequently criticised as being unnecessarily
 bloated and heavyweight.  I'd also recommend contacting the editors of the
 Oxford English Dictionary so they can correct their definition of 
 "lightweight", perhaps US dictionaries define this word differently than our 
 ones do).

Peter (exits, shaking head in disbelief).

From: "Walter Williams" <[email-masked]>
To: "Philip Hallam-Baker" <[email-masked]>, "'David P. Kemp'" <[email-masked]>, <[email-masked]>
Subject: RE: Border directories
Date: Fri, 12 May 2000 13:01:33 -0400
Importance: Normal
Sender: [email-masked]

>
> Oh and by the way, folk making statements about Active directory
> as if it was simply and exclusively an LDAP directory make
> a major underestimation of its function and capabilities.
>
> 		Phill

But the other capacities were outside the context of our discussion on
interoperability with S/MIME and therefor out of scope.  I try not to waste
people's time with fluf and am again calling that this thread be snuffed.
It has lost any and all relevance to the initial discussions.

Reply-To: "Colin.Robbins" <[email-masked]>
From: Colin Robbins <[email-masked]>
To: "'David P. Kemp'" <[email-masked]>, ietf-smime <[email-masked]>
Subject: RE: Border directories
Date: Fri, 12 May 2000 17:07:01 +0100
Importance: Normal
Sender: [email-masked]

> More importantly, the assumption that DSAs are generally
> based on RDBMS
> backends is not obviously valid - directories and RDBMSs have
> different
> strengths.  Implementing one as an interface to the other, though
> possible, is not likely to win any performance benchmarks.  Perhaps
> a few DSA vendors will chime in here with some ground truth on RDBMS
> usage and API accessability to 3rd party apps.
>

There is an assumption that because a DSA is based on a RDBMS,  you can use
RDBMS tools to access the data directly.  This is a false assumption.

Due to the mismatch between Directory requirements and a RDBMS, directory
vendors using a RDBMS generally have to write an interface layer to map data
between directory constructs and RDBMS constructs.   This generally means
the data in the RDBMS is structured to meet the directory needs, and not
other application needs.  As such, using third party RDBMS tools becomes
very difficult - the data is not is an easily-usable form.

If anyone is interested in the technical reasons why a RDBMS is bad news for
directory performance, then there is a white paper " Use of OODB Technology
for Directories" written by an independent expert on our web site
(http://www.nexor.com/info/papers.htm) that describes these problems in
detail.
NEXOR's own DSA is fundamentally not based on a RDBMS due to these problems.

If you want to access data in a Directory, then the only reliable method is
to use Directory APIs, as provided by the directory vendors.   In addition
to understanding the data structure, they also know about application
constraints.  For example access control.   Going direct to a RDBMS is
likely to bypass any application access controls provided by the Directory
vendor.

Colin

From: Philip Hallam-Baker <[email-masked]>
To: "'David P. Kemp'" <[email-masked]>, [email-masked]
Subject: RE: Border directories
Date: Fri, 12 May 2000 08:55:15 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0014_01BFBC07.FC77DD10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>>  client -> HTTP GET -> Apache w/mod_perl & DBI-/

Perl? Puleeezzee...

I am not a fan of the RDBMS model either... But  basing a
design decision on the 'Fact' that HTTP has to involve
a shell scripting language with a somewhat eccentric syntax
rather than a direct call to the databes API is somewhat odd
in any case.

All you need in the repository is ACID properties. Insisting
that the choice of data model must be either RDB or X.500 is
somewhat odd IMNSHO.

The only data model you actually need is that required by the
S/MIME client interface and the PKI interface. i.e. retrieval
by means of a key formed by the subjectAltName (or legacy DN
component) and incremental addition/deletion of certificates
and CRLs by the PKI data source.

Oh and by the way, folk making statements about Active directory
as if it was simply and exclusively an LDAP directory make
a major underestimation of its function and capabilities.

		Phill

------=_NextPart_000_0014_01BFBC07.FC77DD10
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0014_01BFBC07.FC77DD10--

Date: Fri, 12 May 2000 11:24:14 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Border directories
To: [email-masked]
Content-MD5: c9yL/76h5kk9tWZa3I1ujw==
Sender: [email-masked]

Aren't you leaving out both a block and an assumption in the
HTTP path?

The assumptions are that the DSA not only is based on an RDBMS but
that the RDBMS interface is exposed to other applications.  If
these assumptions are true, the paths would be more like:

  client -> LDAP client -> LDAP server ---------\
                                                 \
                                                  RDBMS
                                                 /
  client -> HTTP GET -> Apache w/mod_perl & DBI-/

It's not obvious that an HTTP server with a DB interface can be made to
have a smaller footprint than an LDAP server with a DB interface, or
that server footprint is even a useful metric.  I'd be more concerned
with transaction response time as a function of offered load, using
identical hardware.

More importantly, the assumption that DSAs are generally based on RDBMS
backends is not obviously valid - directories and RDBMSs have different
strengths.  Implementing one as an interface to the other, though
possible, is not likely to win any performance benchmarks.  Perhaps
a few DSA vendors will chime in here with some ground truth on RDBMS
usage and API accessability to 3rd party apps.

Dave

> From: [email-masked] (Peter Gutmann)
>
> 
> "Walter Williams" <[email-masked]> writes:
> 
> >Last I checked, as the information is stored in a directory to begin with,
> 
> Last I checked all the LDAP directories I could find used either
> Berkeley DB or an RDBMS to store information.  With LDAP you have:
> 
>  client -> LDAP (client) -> LDAP (server) -> RDBMS
> 
> What I was suggesting is:
> 
>  client -> HTTP GET -> RDBMS
> 
> cutting out the superfluous LDAP bloat in the middle.
> 
> Peter.

From: "Walter Williams" <[email-masked]>
To: "Philip Hallam-Baker" <[email-masked]>, <[email-masked]>, "'Laurent Deffranne'" <[email-masked]>
Cc: "'ietf-smime'" <[email-masked]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Fri, 12 May 2000 11:10:19 -0400
Importance: Normal
Sender: [email-masked]

I never said all CA vendors do the legal work but I listed three who do.
Legal work is a hugh hidden cost and risk of PKI.  Please do not put words
im my mouth.

Walter

> -----Original Message-----
> From: Philip Hallam-Baker [mailto:[email-masked]]
> Sent: Friday, May 12, 2000 10:07 AM
> To: Walter Williams; [email-masked]; 'Laurent Deffranne'
> Cc: 'ietf-smime'
> Subject: RE: Does Smime works fine with Windows 2000 PKI
>
>
> I think that the hidden costs of using Cert server was what Peter
> was referring to when he said 'free was the best thing to be said
> about it'...
>
> The purchase cost of enterprise infrastructure software is rarely
> a significant factor in the total cost of deployment. I am not aware
> that all PKI vendors 'do the legal work for you' however. In fact
> some specialist PKI vendors do no more than Microsoft, they deliver
> software in shrink wrapped boxes...
>
> 	Phill
>
> -----Original Message-----
> From: Walter Williams [mailto:[email-masked]]
> Sent: Thursday, May 11, 2000 2:26 PM
> To: [email-masked]; 'Laurent Deffranne'
> Cc: 'ietf-smime'
> Subject: RE: Does Smime works fine with Windows 2000 PKI
>
>
> Free only if you own Windows 2000, but yes that means free for most folks
> eventually.  However, most of the costs associated with a PKI are not in
> the
> actual technology, but rather in the legal side of things.  Outsourcing to
> a
> CA vendor such as Baltimore, Entrust or Verisign allows you to offset the
> soft costs to a company which has already done its legal home work for
> you.
> There is a lot of discussion on the cost/benefits on inhousing a CA which
> can be found in EMA sessions, often available on www.ema.org.  Also look
> at
> www.pki.org for interoperability testing (not just white papers here).
> EMA
> has recently published the findings of a large test regarding PKI interop
> which involved many vendors, the federal government and this is available
> again at www.ema.org.  I don't know if the tests have included W2K in the
> past but we can ask Microsoft to participate as they are an ongoing
> process.
>
> Walt
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Piers Chivers
> > Sent: Thursday, May 11, 2000 1:17 PM
> > To: 'Laurent Deffranne'; 'walter.williams'
> > Cc: 'ietf-smime'
> > Subject: RE: Does Smime works fine with Windows 2000 PKI
> >
> >
> > MS have published a White Paper on Win2k PKI interoperability with other
> > leading PKI vendor products.  The WP is available on their MSDN website
> > (can't remember where but it's called win2kpkinterop.doc).
> >
> > In my experience Win2k PKI is excellent as choice for an
> > Enterprise PKI.  It
> > integrates well with AD (not surprisingly).  However, as a commercial
> PKI
> > the best thing that can be said about it is that it is free.  And that
> > probably sums it up succintly.
> >
> > Piers
> >
> > -----Original Message-----
> > From: Laurent Deffranne [mailto:[email-masked]]
> > Sent: 11 May 2000 14:19
> > To: walter.williams
> > Cc: ietf-smime
> > Subject: RE: Does Smime works fine with Windows 2000 PKI
> >
> >
> > Walt,
> >
> > Do you mean that there are difficulties to access through LDAP an Active
> > Directory, as you want to read or use X509 certificates ?
> >
> > By the way,does somebody know issues about Active Directory LDAP, or
> > issues to read a certificate in an Active Directory ?
> >
> > For me it would be a mistake to use now the "brand new" Active
> > Directory, but if someone could tell me where I can find proofs of lack
> > of compatibility (from Microsoft, there must be surely one of two), this
> > would interrest me.
> >
> > Laurent
> >
> >
> >
> >
> >
> > walter.williams%genuity.com@Internet
> > 11/05/2000 14:54
> > To:	Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
> > cc:
> >
> > Subject:	RE: Does Smime works fine with Windows 2000 PKI
> >
> > Laurent;
> >
> > Yes, certs issued from a W2K CA can be used for S/MIME, and no less so
> > than
> > certs issued from Baltimore, Iplanet or any other CA vendor or product.
> > The
> > main issue is not will they work, but will you be able to validate the
> > certs.  Unless the person issuing the cert from W2K has provided you
> > with
> > their server's cert, or they have certified their CA with the signature
> > of
> > the publicly known CAs you will not be able to easily verify the
> > signature
> > to its source.  This is not the most technically acurate way of saying
> > this
> > but I'm not awake yet.  Baltimore has preregistered there CA with the
> > vendors distributing products, as has Verisign, Thaught, and many
> > others.
> > Just make certain that you have the certificates for the W2K CA, and
> > access
> > to its revocation list so you can validate properly and you'll be fine.
> >
> > Walt Williams
> > TSD-Systems
> > Senior IT Analyst
> > Genuity
> > www.genuity.com
> >
> > Please note: GTE Internetworking is now Genuity.
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of Laurent Deffranne
> > > Sent: Thursday, May 11, 2000 5:45 AM
> > > To: ietf-smime
> > > Subject: Does Smime works fine with Windows 2000 PKI
> > >
> > >
> > > Hi everybody,
> > >
> > > Just a question :
> > >
> > > Is there any known issues using S/MIME with Win2000PKI-certificates ?
> > > More generally, are Win2000 certificates usable with (and
> > > understood by ) the others mailers (especially Lotus Notes,
> > > Netscape, Eudora +plug-in?)
> > >
> > > Isn't Baltimore Unicert a "better choice" due to its greater
> > > compatibility ?
> > >
> > > Any advices are welcome.
> > >
> > > Regards,
> > >
> > > Laurent Deffranne
> >
> >
> >
> >
> >
>

From: "Walter Williams" <[email-masked]>
To: "Philip Hallam-Baker" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Border directories
Date: Fri, 12 May 2000 11:08:09 -0400
Importance: Normal
Sender: [email-masked]

True, certs can be and often are stored as files in file servers.  This does
not make them easy for an email client to find them.  We were talking about
S/MIME and Active Directory.  The W2K cert server can store the certs in a
Directory by default, one which is LDAP accessible and that is exactly what
the email client needs.  I never said that certs could only be stored in a
directory, but in this discussion, founded on the question of W2K and S/MIME
interoperability, a directory is precisely where you'll find them.  Since
active directory is not something most companies will want to expose to the
internet, I proposed a directory proxy.

You are also right, LDAP is a middleman, but only in the same way HTTP is.
Unfortunately, your quoting of my text does not properly quote Peter's.

Please lets drop these threads, they loose the context of the original
discussion which was on interoperability.

Walt

> -----Original Message-----
> From: Philip Hallam-Baker [mailto:[email-masked]]
> Sent: Friday, May 12, 2000 10:07 AM
> To: Walter Williams; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Border directories
>
>
>
> >Last I checked, as the information is stored in a directory to begin
> with,
> >LDAP is not a middleman, but is doing things rather directly.
>
> LDAP is just a protocol, all protocols are middlemen
>
>  >Doing an HTTP
> >Get presumes that this will find it in a Directory.  Probably you will
> find
> >that your HTTP needs a perl cgi which actually talks LDAP behind the
> scenes.
>
> More likely talk to a database.
>
> I was never a fan of either CGI or Perl.
>
> >Don't forget HTTP is not a Directory Access Protocol, LDAP is, and the
> certs
> >are stored in a Directory.
>
> Who says so??? They are wrong in many cases.
>
>
> 		Phill
>

From: Philip Hallam-Baker <[email-masked]>
To: [email-masked]
Subject: RE: Border directories
Date: Fri, 12 May 2000 07:22:40 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01BFBBFC.28435FC0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

>>certificates are stored in a directory that exposes its data 
>>via LDAP and some form of LDAP interface will be required 

Dead wrong. Sometimes this is the case but it is neither necessarily
the case or even usually the case.

LDAP is simply an access protocol. There is no necessity that LDAP
be involved AT ALL in the Certificate repository.

Of course to interface to many PKI applications it is usefull to
support LDAP as one option, but the idea that it is impossible to
access data directly through a repository interface to HTTP, FTP
or even Gopher without converting the protocol to LDAP and back 
is simply incorrect.

>>we have available an LDAP COM Automation server that can be used 
>>to tie an LDAP directory to a web server and has a footprint of 
>> < 1 MB.

Yeah, LIGHTWEIGHT!

Try fitting that on a Palm VII! How about a smartcard?

I don't know quite how we got into this argument. I am certainly not
trying to dis LDAP, far from it, I was very involved in the VeriSign
LDAP strategy.

All I am trying to say is that the LDAP protocol did not close forever
the question of where certificates are to reside and the access protocols
by which they are to be retrieved. If companies cannot be persuaded to
deploy border directories that talk LDAP we can try them on HTTP. If
they won't take HTTP we can invent something else altogether.

		Phill

------=_NextPart_000_0009_01BFBBFC.28435FC0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0009_01BFBBFC.28435FC0--

From: Philip Hallam-Baker <[email-masked]>
To: Walter Williams <[email-masked]>, [email-masked], "'Laurent Deffranne'" <[email-masked]>
Cc: "'ietf-smime'" <[email-masked]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Fri, 12 May 2000 07:06:43 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01BFBBA4.40D932B0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

I think that the hidden costs of using Cert server was what Peter
was referring to when he said 'free was the best thing to be said
about it'...

The purchase cost of enterprise infrastructure software is rarely
a significant factor in the total cost of deployment. I am not aware
that all PKI vendors 'do the legal work for you' however. In fact
some specialist PKI vendors do no more than Microsoft, they deliver
software in shrink wrapped boxes...

	Phill

-----Original Message-----
From: Walter Williams [mailto:[email-masked]]
Sent: Thursday, May 11, 2000 2:26 PM
To: [email-masked]; 'Laurent Deffranne'
Cc: 'ietf-smime'
Subject: RE: Does Smime works fine with Windows 2000 PKI

Free only if you own Windows 2000, but yes that means free for most folks
eventually.  However, most of the costs associated with a PKI are not in
the
actual technology, but rather in the legal side of things.  Outsourcing to
a
CA vendor such as Baltimore, Entrust or Verisign allows you to offset the
soft costs to a company which has already done its legal home work for
you.
There is a lot of discussion on the cost/benefits on inhousing a CA which
can be found in EMA sessions, often available on www.ema.org.  Also look
at
www.pki.org for interoperability testing (not just white papers here).
EMA
has recently published the findings of a large test regarding PKI interop
which involved many vendors, the federal government and this is available
again at www.ema.org.  I don't know if the tests have included W2K in the
past but we can ask Microsoft to participate as they are an ongoing
process.

Walt

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Piers Chivers
> Sent: Thursday, May 11, 2000 1:17 PM
> To: 'Laurent Deffranne'; 'walter.williams'
> Cc: 'ietf-smime'
> Subject: RE: Does Smime works fine with Windows 2000 PKI
>
>
> MS have published a White Paper on Win2k PKI interoperability with other
> leading PKI vendor products.  The WP is available on their MSDN website
> (can't remember where but it's called win2kpkinterop.doc).
>
> In my experience Win2k PKI is excellent as choice for an
> Enterprise PKI.  It
> integrates well with AD (not surprisingly).  However, as a commercial
PKI
> the best thing that can be said about it is that it is free.  And that
> probably sums it up succintly.
>
> Piers
>
> -----Original Message-----
> From: Laurent Deffranne [mailto:[email-masked]]
> Sent: 11 May 2000 14:19
> To: walter.williams
> Cc: ietf-smime
> Subject: RE: Does Smime works fine with Windows 2000 PKI
>
>
> Walt,
>
> Do you mean that there are difficulties to access through LDAP an Active
> Directory, as you want to read or use X509 certificates ?
>
> By the way,does somebody know issues about Active Directory LDAP, or
> issues to read a certificate in an Active Directory ?
>
> For me it would be a mistake to use now the "brand new" Active
> Directory, but if someone could tell me where I can find proofs of lack
> of compatibility (from Microsoft, there must be surely one of two), this
> would interrest me.
>
> Laurent
>
>
>
>
>
> walter.williams%genuity.com@Internet
> 11/05/2000 14:54
> To:	Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
> cc:
>
> Subject:	RE: Does Smime works fine with Windows 2000 PKI
>
> Laurent;
>
> Yes, certs issued from a W2K CA can be used for S/MIME, and no less so
> than
> certs issued from Baltimore, Iplanet or any other CA vendor or product.
> The
> main issue is not will they work, but will you be able to validate the
> certs.  Unless the person issuing the cert from W2K has provided you
> with
> their server's cert, or they have certified their CA with the signature
> of
> the publicly known CAs you will not be able to easily verify the
> signature
> to its source.  This is not the most technically acurate way of saying
> this
> but I'm not awake yet.  Baltimore has preregistered there CA with the
> vendors distributing products, as has Verisign, Thaught, and many
> others.
> Just make certain that you have the certificates for the W2K CA, and
> access
> to its revocation list so you can validate properly and you'll be fine.
>
> Walt Williams
> TSD-Systems
> Senior IT Analyst
> Genuity
> www.genuity.com
>
> Please note: GTE Internetworking is now Genuity.
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Laurent Deffranne
> > Sent: Thursday, May 11, 2000 5:45 AM
> > To: ietf-smime
> > Subject: Does Smime works fine with Windows 2000 PKI
> >
> >
> > Hi everybody,
> >
> > Just a question :
> >
> > Is there any known issues using S/MIME with Win2000PKI-certificates ?
> > More generally, are Win2000 certificates usable with (and
> > understood by ) the others mailers (especially Lotus Notes,
> > Netscape, Eudora +plug-in?)
> >
> > Isn't Baltimore Unicert a "better choice" due to its greater
> > compatibility ?
> >
> > Any advices are welcome.
> >
> > Regards,
> >
> > Laurent Deffranne
>
>
>
>
>

------=_NextPart_000_0005_01BFBBA4.40D932B0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0005_01BFBBA4.40D932B0--

From: Philip Hallam-Baker <[email-masked]>
To: Walter Williams <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: Border directories
Date: Fri, 12 May 2000 07:06:39 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01BFBBA2.F60F30F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>Last I checked, as the information is stored in a directory to begin
with,
>LDAP is not a middleman, but is doing things rather directly. 

LDAP is just a protocol, all protocols are middlemen

 >Doing an HTTP
>Get presumes that this will find it in a Directory.  Probably you will
find
>that your HTTP needs a perl cgi which actually talks LDAP behind the
scenes.

More likely talk to a database.

I was never a fan of either CGI or Perl. 

>Don't forget HTTP is not a Directory Access Protocol, LDAP is, and the
certs
>are stored in a Directory.

Who says so??? They are wrong in many cases.

		Phill

------=_NextPart_000_0000_01BFBBA2.F60F30F0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0000_01BFBBA2.F60F30F0--

From: "Stuart Ross" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Border directories
Date: Fri, 12 May 2000 11:09:25 +0100
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFBBFA.26B7EACE
Content-Type: text/plain; 
 charset=windows-1252
Content-Transfer-Encoding: 7bit

Peter,

LDAP stands for LIGHTWEIGHT Directory Access protocol and is by its very
nature efficient with an extremely low footprint, for example we have
available an LDAP COM Automation server that can be used to tie an LDAP
directory to a web server and has a footprint of < 1 MB. This aside if you
had to code HTTP requests into an SMIME client that could do all of the
functions that an LDAP SMIME client can do then I suspect you would find the
HTTP code growing and growing.

Stuart Ross 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 12, 2000 8:23 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Border directories

"Walter Williams" <[email-masked]> writes:

>And LDAP is already built into the client to do exactly what you are asking

>some one to write code to do.  Yes it can be done.  Yes it will be done.  
>But most are doing this through LDAP for very good reasons.  Keep in mind 
>that many email clients do not do HTTP, so then you would have a flow path 
>of: to create s/mime email, don't create a new email in client, open
browser,
>browse to proper link, run query, have email aware http application you
have 
>to now write create your email.  This application should idealy call your 
>default email package, but how will it tell Outlook as an example about the

>certificate it just found?  I can't see that as a natural flow of work.  
>Yes, if you are using an web based email service such as hotmail.  No if
you 
>are using a corporate solution.

Just because it's possible to push a pea up a mountain with your nose
doesn't
mean that that's the best way to get it there.  Certainly if you go with
this
amazing inverted world view in which 10 lines of code added to an existing 
TCP/IP-aware app is more work than integrating a multimegabyte LDAP client
library with its enormously complex programming interface and config 
requirements, then LDAP is simpler and easier than HTTP.  In my world
however,
doing it via HTTP from the email client would be the easier option (although

it's certainly possible to invent arbitrarily awkward scenarios for HTTP if 
your goal is to make LDAP look good in comparison).

Peter.

------_=_NextPart_001_01BFBBFA.26B7EACE
Content-Type: text/html; 
 charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Border directories</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Peter,</FONT>
</P>

<P><FONT SIZE=3D2>LDAP stands for LIGHTWEIGHT Directory Access protocol =
and is by its very nature efficient with an extremely low footprint, =
for example we have available an LDAP COM Automation server that can be =
used to tie an LDAP directory to a web server and has a footprint of =
&lt; 1 MB. This aside if you had to code HTTP requests into an SMIME =
client that could do all of the functions that an LDAP SMIME client can =
do then I suspect you would find the HTTP code growing and =
growing.</FONT></P>

<P><FONT SIZE=3D2>Stuart Ross </FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked].=
nz</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, May 12, 2000 8:23 AM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]; [email-masked]; =
[email-masked];</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Border directories</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&quot;Walter Williams&quot; =
&lt;[email-masked]&gt; writes:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;And LDAP is already built into the client to do =
exactly what you are asking </FONT>
<BR><FONT SIZE=3D2>&gt;some one to write code to do.&nbsp; Yes it can =
be done.&nbsp; Yes it will be done.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;But most are doing this through LDAP for very =
good reasons.&nbsp; Keep in mind </FONT>
<BR><FONT SIZE=3D2>&gt;that many email clients do not do HTTP, so then =
you would have a flow path </FONT>
<BR><FONT SIZE=3D2>&gt;of: to create s/mime email, don't create a new =
email in client, open browser,</FONT>
<BR><FONT SIZE=3D2>&gt;browse to proper link, run query, have email =
aware http application you have </FONT>
<BR><FONT SIZE=3D2>&gt;to now write create your email.&nbsp; This =
application should idealy call your </FONT>
<BR><FONT SIZE=3D2>&gt;default email package, but how will it tell =
Outlook as an example about the </FONT>
<BR><FONT SIZE=3D2>&gt;certificate it just found?&nbsp; I can't see =
that as a natural flow of work.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;Yes, if you are using an web based email service =
such as hotmail.&nbsp; No if you </FONT>
<BR><FONT SIZE=3D2>&gt;are using a corporate solution.</FONT>
</P>

<P><FONT SIZE=3D2>Just because it's possible to push a pea up a =
mountain with your nose doesn't</FONT>
<BR><FONT SIZE=3D2>mean that that's the best way to get it there.&nbsp; =
Certainly if you go with this</FONT>
<BR><FONT SIZE=3D2>amazing inverted world view in which 10 lines of =
code added to an existing </FONT>
<BR><FONT SIZE=3D2>TCP/IP-aware app is more work than integrating a =
multimegabyte LDAP client</FONT>
<BR><FONT SIZE=3D2>library with its enormously complex programming =
interface and config </FONT>
<BR><FONT SIZE=3D2>requirements, then LDAP is simpler and easier than =
HTTP.&nbsp; In my world however,</FONT>
<BR><FONT SIZE=3D2>doing it via HTTP from the email client would be the =
easier option (although </FONT>
<BR><FONT SIZE=3D2>it's certainly possible to invent arbitrarily =
awkward scenarios for HTTP if </FONT>
<BR><FONT SIZE=3D2>your goal is to make LDAP look good in =
comparison).</FONT>
</P>

<P><FONT SIZE=3D2>Peter.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFBBFA.26B7EACE--

From: "Stuart Ross" <[email-masked]>
To: "'Walter Williams'" <[email-masked]>, "Piers Chivers" <[email-masked]>, "'Laurent Deffranne'" <[email-masked]>
cc: "'ietf-smime'" <[email-masked]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Fri, 12 May 2000 10:48:59 +0100
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFBBF7.4BCEA1D4
Content-Type: text/plain; 
 charset=windows-1252
Content-Transfer-Encoding: 7bit

Ongoing costs play the largest part in the cost of a PKI, for example
issuing Certificates, revoking certificates, rolling over certificates,
supporting users etc, the list goes on and it is non trivial, therefore
expensive either outsourcing or in-house. 

Stuart R 
 
-----Original Message-----
From: Walter Williams [mailto:[email-masked]]
Sent: Thursday, May 11, 2000 7:26 PM
To: [email-masked]; 'Laurent Deffranne'
Cc: 'ietf-smime'
Subject: RE: Does Smime works fine with Windows 2000 PKI

Free only if you own Windows 2000, but yes that means free for most folks
eventually.  However, most of the costs associated with a PKI are not in the
actual technology, but rather in the legal side of things.  Outsourcing to a
CA vendor such as Baltimore, Entrust or Verisign allows you to offset the
soft costs to a company which has already done its legal home work for you.
There is a lot of discussion on the cost/benefits on inhousing a CA which
can be found in EMA sessions, often available on www.ema.org.  Also look at
www.pki.org for interoperability testing (not just white papers here).  EMA
has recently published the findings of a large test regarding PKI interop
which involved many vendors, the federal government and this is available
again at www.ema.org.  I don't know if the tests have included W2K in the
past but we can ask Microsoft to participate as they are an ongoing process.

Walt

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Piers Chivers
> Sent: Thursday, May 11, 2000 1:17 PM
> To: 'Laurent Deffranne'; 'walter.williams'
> Cc: 'ietf-smime'
> Subject: RE: Does Smime works fine with Windows 2000 PKI
>
>
> MS have published a White Paper on Win2k PKI interoperability with other
> leading PKI vendor products.  The WP is available on their MSDN website
> (can't remember where but it's called win2kpkinterop.doc).
>
> In my experience Win2k PKI is excellent as choice for an
> Enterprise PKI.  It
> integrates well with AD (not surprisingly).  However, as a commercial PKI
> the best thing that can be said about it is that it is free.  And that
> probably sums it up succintly.
>
> Piers
>
> -----Original Message-----
> From: Laurent Deffranne [mailto:[email-masked]]
> Sent: 11 May 2000 14:19
> To: walter.williams
> Cc: ietf-smime
> Subject: RE: Does Smime works fine with Windows 2000 PKI
>
>
> Walt,
>
> Do you mean that there are difficulties to access through LDAP an Active
> Directory, as you want to read or use X509 certificates ?
>
> By the way,does somebody know issues about Active Directory LDAP, or
> issues to read a certificate in an Active Directory ?
>
> For me it would be a mistake to use now the "brand new" Active
> Directory, but if someone could tell me where I can find proofs of lack
> of compatibility (from Microsoft, there must be surely one of two), this
> would interrest me.
>
> Laurent
>
>
>
>
>
> walter.williams%genuity.com@Internet
> 11/05/2000 14:54
> To:	Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
> cc:
>
> Subject:	RE: Does Smime works fine with Windows 2000 PKI
>
> Laurent;
>
> Yes, certs issued from a W2K CA can be used for S/MIME, and no less so
> than
> certs issued from Baltimore, Iplanet or any other CA vendor or product.
> The
> main issue is not will they work, but will you be able to validate the
> certs.  Unless the person issuing the cert from W2K has provided you
> with
> their server's cert, or they have certified their CA with the signature
> of
> the publicly known CAs you will not be able to easily verify the
> signature
> to its source.  This is not the most technically acurate way of saying
> this
> but I'm not awake yet.  Baltimore has preregistered there CA with the
> vendors distributing products, as has Verisign, Thaught, and many
> others.
> Just make certain that you have the certificates for the W2K CA, and
> access
> to its revocation list so you can validate properly and you'll be fine.
>
> Walt Williams
> TSD-Systems
> Senior IT Analyst
> Genuity
> www.genuity.com
>
> Please note: GTE Internetworking is now Genuity.
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Laurent Deffranne
> > Sent: Thursday, May 11, 2000 5:45 AM
> > To: ietf-smime
> > Subject: Does Smime works fine with Windows 2000 PKI
> >
> >
> > Hi everybody,
> >
> > Just a question :
> >
> > Is there any known issues using S/MIME with Win2000PKI-certificates ?
> > More generally, are Win2000 certificates usable with (and
> > understood by ) the others mailers (especially Lotus Notes,
> > Netscape, Eudora +plug-in?)
> >
> > Isn't Baltimore Unicert a "better choice" due to its greater
> > compatibility ?
> >
> > Any advices are welcome.
> >
> > Regards,
> >
> > Laurent Deffranne
>
>
>
>
>

------_=_NextPart_001_01BFBBF7.4BCEA1D4
Content-Type: text/html; 
 charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Does Smime works fine with Windows 2000 PKI</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Ongoing costs play the largest part in the cost of a =
PKI, for example issuing Certificates, revoking certificates, rolling =
over certificates, supporting users etc, the list goes on and it is non =
trivial, therefore expensive either outsourcing or in-house. =
</FONT></P>

<P><FONT SIZE=3D2>Stuart R </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Walter Williams [<A =
HREF=3D"mailto:[email-masked]">mailto:walter.williams@genui=
ty.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, May 11, 2000 7:26 PM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]; 'Laurent Deffranne'</FONT>
<BR><FONT SIZE=3D2>Cc: 'ietf-smime'</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Does Smime works fine with Windows 2000 =
PKI</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Free only if you own Windows 2000, but yes that means =
free for most folks</FONT>
<BR><FONT SIZE=3D2>eventually.&nbsp; However, most of the costs =
associated with a PKI are not in the</FONT>
<BR><FONT SIZE=3D2>actual technology, but rather in the legal side of =
things.&nbsp; Outsourcing to a</FONT>
<BR><FONT SIZE=3D2>CA vendor such as Baltimore, Entrust or Verisign =
allows you to offset the</FONT>
<BR><FONT SIZE=3D2>soft costs to a company which has already done its =
legal home work for you.</FONT>
<BR><FONT SIZE=3D2>There is a lot of discussion on the cost/benefits on =
inhousing a CA which</FONT>
<BR><FONT SIZE=3D2>can be found in EMA sessions, often available on =
www.ema.org.&nbsp; Also look at</FONT>
<BR><FONT SIZE=3D2>www.pki.org for interoperability testing (not just =
white papers here).&nbsp; EMA</FONT>
<BR><FONT SIZE=3D2>has recently published the findings of a large test =
regarding PKI interop</FONT>
<BR><FONT SIZE=3D2>which involved many vendors, the federal government =
and this is available</FONT>
<BR><FONT SIZE=3D2>again at www.ema.org.&nbsp; I don't know if the =
tests have included W2K in the</FONT>
<BR><FONT SIZE=3D2>past but we can ask Microsoft to participate as they =
are an ongoing process.</FONT>
</P>

<P><FONT SIZE=3D2>Walt</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-smime@ma=
il.imc.org</A>]On Behalf Of Piers Chivers</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, May 11, 2000 1:17 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Laurent Deffranne'; =
'walter.williams'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'ietf-smime'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Does Smime works fine with Windows =
2000 PKI</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; MS have published a White Paper on Win2k PKI =
interoperability with other</FONT>
<BR><FONT SIZE=3D2>&gt; leading PKI vendor products.&nbsp; The WP is =
available on their MSDN website</FONT>
<BR><FONT SIZE=3D2>&gt; (can't remember where but it's called =
win2kpkinterop.doc).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; In my experience Win2k PKI is excellent as =
choice for an</FONT>
<BR><FONT SIZE=3D2>&gt; Enterprise PKI.&nbsp; It</FONT>
<BR><FONT SIZE=3D2>&gt; integrates well with AD (not =
surprisingly).&nbsp; However, as a commercial PKI</FONT>
<BR><FONT SIZE=3D2>&gt; the best thing that can be said about it is =
that it is free.&nbsp; And that</FONT>
<BR><FONT SIZE=3D2>&gt; probably sums it up succintly.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Piers</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Laurent Deffranne [<A =
HREF=3D"mailto:[email-masked]">mailto:Laurent.Deffranne@dexi=
a.be</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 11 May 2000 14:19</FONT>
<BR><FONT SIZE=3D2>&gt; To: walter.williams</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: ietf-smime</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Does Smime works fine with Windows =
2000 PKI</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Walt,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Do you mean that there are difficulties to =
access through LDAP an Active</FONT>
<BR><FONT SIZE=3D2>&gt; Directory, as you want to read or use X509 =
certificates ?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; By the way,does somebody know issues about =
Active Directory LDAP, or</FONT>
<BR><FONT SIZE=3D2>&gt; issues to read a certificate in an Active =
Directory ?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; For me it would be a mistake to use now the =
&quot;brand new&quot; Active</FONT>
<BR><FONT SIZE=3D2>&gt; Directory, but if someone could tell me where I =
can find proofs of lack</FONT>
<BR><FONT SIZE=3D2>&gt; of compatibility (from Microsoft, there must be =
surely one of two), this</FONT>
<BR><FONT SIZE=3D2>&gt; would interrest me.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Laurent</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; walter.williams%genuity.com@Internet</FONT>
<BR><FONT SIZE=3D2>&gt; 11/05/2000 14:54</FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp;&nbsp; Laurent =
Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet</FONT>
<BR><FONT SIZE=3D2>&gt; cc:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: Does =
Smime works fine with Windows 2000 PKI</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Laurent;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Yes, certs issued from a W2K CA can be used for =
S/MIME, and no less so</FONT>
<BR><FONT SIZE=3D2>&gt; than</FONT>
<BR><FONT SIZE=3D2>&gt; certs issued from Baltimore, Iplanet or any =
other CA vendor or product.</FONT>
<BR><FONT SIZE=3D2>&gt; The</FONT>
<BR><FONT SIZE=3D2>&gt; main issue is not will they work, but will you =
be able to validate the</FONT>
<BR><FONT SIZE=3D2>&gt; certs.&nbsp; Unless the person issuing the cert =
from W2K has provided you</FONT>
<BR><FONT SIZE=3D2>&gt; with</FONT>
<BR><FONT SIZE=3D2>&gt; their server's cert, or they have certified =
their CA with the signature</FONT>
<BR><FONT SIZE=3D2>&gt; of</FONT>
<BR><FONT SIZE=3D2>&gt; the publicly known CAs you will not be able to =
easily verify the</FONT>
<BR><FONT SIZE=3D2>&gt; signature</FONT>
<BR><FONT SIZE=3D2>&gt; to its source.&nbsp; This is not the most =
technically acurate way of saying</FONT>
<BR><FONT SIZE=3D2>&gt; this</FONT>
<BR><FONT SIZE=3D2>&gt; but I'm not awake yet.&nbsp; Baltimore has =
preregistered there CA with the</FONT>
<BR><FONT SIZE=3D2>&gt; vendors distributing products, as has Verisign, =
Thaught, and many</FONT>
<BR><FONT SIZE=3D2>&gt; others.</FONT>
<BR><FONT SIZE=3D2>&gt; Just make certain that you have the =
certificates for the W2K CA, and</FONT>
<BR><FONT SIZE=3D2>&gt; access</FONT>
<BR><FONT SIZE=3D2>&gt; to its revocation list so you can validate =
properly and you'll be fine.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Walt Williams</FONT>
<BR><FONT SIZE=3D2>&gt; TSD-Systems</FONT>
<BR><FONT SIZE=3D2>&gt; Senior IT Analyst</FONT>
<BR><FONT SIZE=3D2>&gt; Genuity</FONT>
<BR><FONT SIZE=3D2>&gt; www.genuity.com</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Please note: GTE Internetworking is now =
Genuity.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-smime@ma=
il.imc.org</A>]On Behalf Of Laurent Deffranne</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, May 11, 2000 5:45 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: ietf-smime</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Does Smime works fine with =
Windows 2000 PKI</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi everybody,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Just a question :</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Is there any known issues using S/MIME =
with Win2000PKI-certificates ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; More generally, are Win2000 certificates =
usable with (and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; understood by ) the others mailers =
(especially Lotus Notes,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Netscape, Eudora +plug-in?)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Isn't Baltimore Unicert a &quot;better =
choice&quot; due to its greater</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; compatibility ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Any advices are welcome.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Laurent Deffranne</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFBBF7.4BCEA1D4--

From: "Stuart Ross" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: Border directories
Date: Fri, 12 May 2000 10:42:28 +0100
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFBBF6.63333534
Content-Type: text/plain; 
 charset=windows-1252
Content-Transfer-Encoding: 7bit

Peter, 

I am with Walter on this one, whether LDAP is implemented at the client or
at the server you are going to need it in their somewhere, certificates are
stored in a directory that exposes its data via LDAP and some form of LDAP
interface will be required between the Directory and web server. Yes you can
use HTTP to retrieve certificates but this is not the way the market has
gone, all of the major SMIME clients available on the market today will
retrieve certificates using the LDAP protocol quickly and efficiently, off
course this has the added advantage that all directories should support
LDAP, not all companies that you will communicate with will have tied their
directory to a web server.

Stuart Ross
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 12, 2000 7:06 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Border directories

"Walter Williams" <[email-masked]> writes:

>The major problem I see with using HTML is the need for the email client to
>retrieve the public key.  They are designed to do this over LDAP.  Not all
>email clients are integrated with a HTML reader.  The LDAP query is not
>significant overhead and checks for public key data very transparently.

Uhh... anything which can talk TCP/IP can do an HTML GET in about 10 lines
of code and about 5 minutes of work.  When used as a cert-grabbing
mechanism,
I'd estimate that LDAP has about four orders of magnitude more overhead (in
terms of code complexity) than HTML (probably more like five or six, going
by the size of LDAP binaries).  I'm not sure what the performance overhead
is 
but I can imagine that'd also be vastly higher.

Given that in the end all you're doing is a 'SELECT cert WHERE name = foo',
doing it via an HTTP GET makes much more sense than rewriting it into an
LDAP query in the client, communicating it via an enormously complex and
heavyweight protocol to the server, having the server rewrite it back into 
its original form so it can do something useful with it, and then reversing 
the process to return the result.  Sure, you get to say "We're using LDAP",
but wouldn't it make more sense to cut out the middleman and do things
directly?

Peter.

------_=_NextPart_001_01BFBBF6.63333534
Content-Type: text/html; 
 charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Border directories</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Peter, </FONT>
</P>

<P><FONT SIZE=3D2>I am with Walter on this one, whether LDAP is =
implemented at the client or at the server you are going to need it in =
their somewhere, certificates are stored in a directory that exposes =
its data via LDAP and some form of LDAP interface will be required =
between the Directory and web server. Yes you can use HTTP to retrieve =
certificates but this is not the way the market has gone, all of the =
major SMIME clients available on the market today will retrieve =
certificates using the LDAP protocol quickly and efficiently, off =
course this has the added advantage that all directories should support =
LDAP, not all companies that you will communicate with will have tied =
their directory to a web server.</FONT></P>

<P><FONT SIZE=3D2>Stuart Ross</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked].=
nz</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, May 12, 2000 7:06 AM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Border directories</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&quot;Walter Williams&quot; =
&lt;[email-masked]&gt; writes:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;The major problem I see with using HTML is the =
need for the email client to</FONT>
<BR><FONT SIZE=3D2>&gt;retrieve the public key.&nbsp; They are designed =
to do this over LDAP.&nbsp; Not all</FONT>
<BR><FONT SIZE=3D2>&gt;email clients are integrated with a HTML =
reader.&nbsp; The LDAP query is not</FONT>
<BR><FONT SIZE=3D2>&gt;significant overhead and checks for public key =
data very transparently.</FONT>
</P>

<P><FONT SIZE=3D2>Uhh... anything which can talk TCP/IP can do an HTML =
GET in about 10 lines</FONT>
<BR><FONT SIZE=3D2>of code and about 5 minutes of work.&nbsp; When used =
as a cert-grabbing mechanism,</FONT>
<BR><FONT SIZE=3D2>I'd estimate that LDAP has about four orders of =
magnitude more overhead (in</FONT>
<BR><FONT SIZE=3D2>terms of code complexity) than HTML (probably more =
like five or six, going</FONT>
<BR><FONT SIZE=3D2>by the size of LDAP binaries).&nbsp; I'm not sure =
what the performance overhead is </FONT>
<BR><FONT SIZE=3D2>but I can imagine that'd also be vastly =
higher.</FONT>
</P>

<P><FONT SIZE=3D2>Given that in the end all you're doing is a 'SELECT =
cert WHERE name =3D foo',</FONT>
<BR><FONT SIZE=3D2>doing it via an HTTP GET makes much more sense than =
rewriting it into an</FONT>
<BR><FONT SIZE=3D2>LDAP query in the client, communicating it via an =
enormously complex and</FONT>
<BR><FONT SIZE=3D2>heavyweight protocol to the server, having the =
server rewrite it back into </FONT>
<BR><FONT SIZE=3D2>its original form so it can do something useful with =
it, and then reversing </FONT>
<BR><FONT SIZE=3D2>the process to return the result.&nbsp; Sure, you =
get to say &quot;We're using LDAP&quot;,</FONT>
<BR><FONT SIZE=3D2>but wouldn't it make more sense to cut out the =
middleman and do things</FONT>
<BR><FONT SIZE=3D2>directly?</FONT>
</P>

<P><FONT SIZE=3D2>Peter.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFBBF6.63333534--

From: "Walter Williams" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Border directories
Date: Thu, 11 May 2000 22:14:25 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01BFBB96.441F8C70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Peter,

The problem of your model is you presume two things that don't exist:
uniformity in data store behind the directory and uniformity in access
control.  LDAP exists, as does DAP (the OSI heavier Directory Access
Protocol which LDAP somewhat replaced) to provide uniformity in data access
when you know nothing about the data store, but you know what you want.
Under your model, you would have to write different HTTP applets for each
different backend.  They would need to authenticate with the back end, using
a mechanism which is proprietary.  LDAP handles the authentication, makes it
as strong (need a cert to bind) or as week (anonymous bind) as you need, and
returns the same set of data from no matter how it is stored in no matter
what database.  LDAP is not all things for all people, but it does allow
email systems to quickly access data regarding people including but not
limited to their public key.  It also allows the users to quickly find a
person's email alias and their public key and Use it to create a encrypted
or just signed message.

By the way, I can retrieve a user's certificate and any other relevant data
in about 10 lines of properly written LDAP code in either C, Perl, or Java.
Why you keep on talking about megabytes of code, I don't know.  I would
recommend you to read up on the standard and its API.  Coding LDAP is as
simple as coding HTTP.  Perhaps you are confusing the LDAP Protocol with
SLAPD, the LDAP based Directory.  While the directory is indeed megabytes of
code, the API is rather small, the relevant .JAR files for java take up a
cumulative 60 kb or so, I can't imagine the C libraries are any bigger, if
anything I would imagine that they are smaller.

I would recommend that if you feel that what you propose is so superior that
you write up some IETF Drafts and try to productize your ideas.  See how
well they sell.  If you're right, you'll make a fortune.  Lets kill this
thread as it is getting us no where.  The initial questions have nothing to
do with the use of LDAP as an API or directory access mechanism, and you
seem to be a little misinformed about what LDAP is and how it is used.

Walt Williams
TSD-Systems
Senior IT Analyst
Genuity
www.genuity.com

Please note: GTE Internetworking is now Genuity.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Peter Gutmann
> Sent: Friday, May 12, 2000 7:23 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Border directories
>
>
> "Walter Williams" <[email-masked]> writes:
>
> >And LDAP is already built into the client to do exactly what you
> are asking
> >some one to write code to do.  Yes it can be done.  Yes it will
> be done.
> >But most are doing this through LDAP for very good reasons.
> Keep in mind
> >that many email clients do not do HTTP, so then you would have a
> flow path
> >of: to create s/mime email, don't create a new email in client,
> open browser,
> >browse to proper link, run query, have email aware http
> application you have
> >to now write create your email.  This application should idealy
> call your
> >default email package, but how will it tell Outlook as an
> example about the
> >certificate it just found?  I can't see that as a natural flow of work.
> >Yes, if you are using an web based email service such as
> hotmail.  No if you
> >are using a corporate solution.
>
> Just because it's possible to push a pea up a mountain with your
> nose doesn't
> mean that that's the best way to get it there.  Certainly if you
> go with this
> amazing inverted world view in which 10 lines of code added to an
> existing
> TCP/IP-aware app is more work than integrating a multimegabyte LDAP client
> library with its enormously complex programming interface and config
> requirements, then LDAP is simpler and easier than HTTP.  In my
> world however,
> doing it via HTTP from the email client would be the easier
> option (although
> it's certainly possible to invent arbitrarily awkward scenarios
> for HTTP if
> your goal is to make LDAP look good in comparison).
>
> Peter.
>

------=_NextPart_000_0004_01BFBB96.441F8C70
Content-Type: text/x-vcard;
	name="Walter B Williams.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Walter B Williams.vcf"

BEGIN:VCARD
VERSION:2.1
N:Williams;Walter;B;Mr.
FN:Walter B Williams
NICKNAME:Walt
ORG:Genuity Inc.;TSD
TITLE:Senior IT Analyst
TEL;WORK;VOICE:617-873-5888
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;2/221B;50 Moulton St=3D0D=3D0AMS =
2/2A;Cambridge;MA;02138;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:2/221B=3D0D=3D0A50 Moulton =
St=3D0D=3D0AMS 2/2A=3D0D=3D0ACambridge, MA 02138=3D0D=3D0AUSA
URL:
URL:http://www.genuity.com
EMAIL;PREF;INTERNET:[email-masked]
REV:20000407T003737Z
END:VCARD

------=_NextPart_000_0004_01BFBB96.441F8C70--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Border directories
Reply-To: [email-masked]
Date: Fri, 12 May 2000 07:22:53 (NZST)
Sender: [email-masked]

"Walter Williams" <[email-masked]> writes:

>And LDAP is already built into the client to do exactly what you are asking 
>some one to write code to do.  Yes it can be done.  Yes it will be done.  
>But most are doing this through LDAP for very good reasons.  Keep in mind 
>that many email clients do not do HTTP, so then you would have a flow path 
>of: to create s/mime email, don't create a new email in client, open browser,
>browse to proper link, run query, have email aware http application you have 
>to now write create your email.  This application should idealy call your 
>default email package, but how will it tell Outlook as an example about the 
>certificate it just found?  I can't see that as a natural flow of work.  
>Yes, if you are using an web based email service such as hotmail.  No if you 
>are using a corporate solution.

Just because it's possible to push a pea up a mountain with your nose doesn't
mean that that's the best way to get it there.  Certainly if you go with this
amazing inverted world view in which 10 lines of code added to an existing 
TCP/IP-aware app is more work than integrating a multimegabyte LDAP client
library with its enormously complex programming interface and config 
requirements, then LDAP is simpler and easier than HTTP.  In my world however,
doing it via HTTP from the email client would be the easier option (although 
it's certainly possible to invent arbitrarily awkward scenarios for HTTP if 
your goal is to make LDAP look good in comparison).

Peter.

From: "Walter Williams" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Border directories
Date: Thu, 11 May 2000 14:37:50 -0400
Importance: Normal
Sender: [email-masked]

Unfortunately for your model, there are a variety of directory vendors which
do not store in either Berkeley DB or in a RDBMS datastore.  Microsoft is
one.  Novell another, Lotus a third.  There are others.  LDAP is certainly
less overhead than MAPI or what ever Novell's and Lotus's equivilent API
would be.  And LDAP is already built into the client to do exactly what you
are asking some one to write code to do.  Yes it can be done.  Yes it will
be done.  But most are doing this through LDAP for very good reasons.  Keep
in mind that many email clients do not do HTTP, so then you would have a
flow path of: to create s/mime email, don't create a new email in client,
open browser, browse to proper link, run query, have email aware http
application you have to now write create your email.  This application
should idealy call your default email package, but how will it tell Outlook
as an example about the certificate it just found?  I can't see that as a
natural flow of work.  Yes, if you are using an web based email service such
as hotmail.  No if you are using a corporate solution.

Walt

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 12, 2000 6:33 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Border directories
>
>
> "Walter Williams" <[email-masked]> writes:
>
> >Last I checked, as the information is stored in a directory to
> begin with,
>
> Last I checked all the LDAP directories I could find used either
> Berkeley DB or an RDBMS to store information.  With LDAP you have:
>
>  client -> LDAP (client) -> LDAP (server) -> RDBMS
>
> What I was suggesting is:
>
>  client -> HTTP GET -> RDBMS
>
> cutting out the superfluous LDAP bloat in the middle.
>
> Peter.
>

From: "Walter Williams" <[email-masked]>
To: <[email-masked]>, "'Laurent Deffranne'" <[email-masked]>
Cc: "'ietf-smime'" <[email-masked]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 14:26:29 -0400
Importance: Normal
Sender: [email-masked]

Free only if you own Windows 2000, but yes that means free for most folks
eventually.  However, most of the costs associated with a PKI are not in the
actual technology, but rather in the legal side of things.  Outsourcing to a
CA vendor such as Baltimore, Entrust or Verisign allows you to offset the
soft costs to a company which has already done its legal home work for you.
There is a lot of discussion on the cost/benefits on inhousing a CA which
can be found in EMA sessions, often available on www.ema.org.  Also look at
www.pki.org for interoperability testing (not just white papers here).  EMA
has recently published the findings of a large test regarding PKI interop
which involved many vendors, the federal government and this is available
again at www.ema.org.  I don't know if the tests have included W2K in the
past but we can ask Microsoft to participate as they are an ongoing process.

Walt

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Piers Chivers
> Sent: Thursday, May 11, 2000 1:17 PM
> To: 'Laurent Deffranne'; 'walter.williams'
> Cc: 'ietf-smime'
> Subject: RE: Does Smime works fine with Windows 2000 PKI
>
>
> MS have published a White Paper on Win2k PKI interoperability with other
> leading PKI vendor products.  The WP is available on their MSDN website
> (can't remember where but it's called win2kpkinterop.doc).
>
> In my experience Win2k PKI is excellent as choice for an
> Enterprise PKI.  It
> integrates well with AD (not surprisingly).  However, as a commercial PKI
> the best thing that can be said about it is that it is free.  And that
> probably sums it up succintly.
>
> Piers
>
> -----Original Message-----
> From: Laurent Deffranne [mailto:[email-masked]]
> Sent: 11 May 2000 14:19
> To: walter.williams
> Cc: ietf-smime
> Subject: RE: Does Smime works fine with Windows 2000 PKI
>
>
> Walt,
>
> Do you mean that there are difficulties to access through LDAP an Active
> Directory, as you want to read or use X509 certificates ?
>
> By the way,does somebody know issues about Active Directory LDAP, or
> issues to read a certificate in an Active Directory ?
>
> For me it would be a mistake to use now the "brand new" Active
> Directory, but if someone could tell me where I can find proofs of lack
> of compatibility (from Microsoft, there must be surely one of two), this
> would interrest me.
>
> Laurent
>
>
>
>
>
> walter.williams%genuity.com@Internet
> 11/05/2000 14:54
> To:	Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
> cc:
>
> Subject:	RE: Does Smime works fine with Windows 2000 PKI
>
> Laurent;
>
> Yes, certs issued from a W2K CA can be used for S/MIME, and no less so
> than
> certs issued from Baltimore, Iplanet or any other CA vendor or product.
> The
> main issue is not will they work, but will you be able to validate the
> certs.  Unless the person issuing the cert from W2K has provided you
> with
> their server's cert, or they have certified their CA with the signature
> of
> the publicly known CAs you will not be able to easily verify the
> signature
> to its source.  This is not the most technically acurate way of saying
> this
> but I'm not awake yet.  Baltimore has preregistered there CA with the
> vendors distributing products, as has Verisign, Thaught, and many
> others.
> Just make certain that you have the certificates for the W2K CA, and
> access
> to its revocation list so you can validate properly and you'll be fine.
>
> Walt Williams
> TSD-Systems
> Senior IT Analyst
> Genuity
> www.genuity.com
>
> Please note: GTE Internetworking is now Genuity.
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Laurent Deffranne
> > Sent: Thursday, May 11, 2000 5:45 AM
> > To: ietf-smime
> > Subject: Does Smime works fine with Windows 2000 PKI
> >
> >
> > Hi everybody,
> >
> > Just a question :
> >
> > Is there any known issues using S/MIME with Win2000PKI-certificates ?
> > More generally, are Win2000 certificates usable with (and
> > understood by ) the others mailers (especially Lotus Notes,
> > Netscape, Eudora +plug-in?)
> >
> > Isn't Baltimore Unicert a "better choice" due to its greater
> > compatibility ?
> >
> > Any advices are welcome.
> >
> > Regards,
> >
> > Laurent Deffranne
>
>
>
>
>

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Border directories
Reply-To: [email-masked]
Date: Fri, 12 May 2000 06:32:36 (NZST)
Sender: [email-masked]

"Walter Williams" <[email-masked]> writes:

>Last I checked, as the information is stored in a directory to begin with,

Last I checked all the LDAP directories I could find used either
Berkeley DB or an RDBMS to store information.  With LDAP you have:

 client -> LDAP (client) -> LDAP (server) -> RDBMS

What I was suggesting is:

 client -> HTTP GET -> RDBMS

cutting out the superfluous LDAP bloat in the middle.

Peter.

From: "Walter Williams" <[email-masked]>
To: "Philip Hallam-Baker" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Does Slime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 14:20:09 -0400
Importance: Normal
Sender: [email-masked]

This is why SRV records of the type _LDAP exist after all.

Walt

PS: Agree strongly about the security thing!

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Philip Hallam-Baker
> Sent: Thursday, May 11, 2000 12:51 PM
> To: [email-masked]'; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Does Slime works fine with Windows 2000 PKI
> 
> 
> 
> 
> >One would think that if you have no control over what is shown and what
> is not
> >shown, that you have effectively lost control of your LDAP systems. 
> 
> Hey, misconfigured 'stuff' is a major cause of security problems.
> 
> The problem I encounter very often is the cost of making sure that
> 'stuff' remains well configured.
> 
> That is why I prefer infrastructure that is narrowly focused on a 
> single function rather than broad-band approaches. 
> 
> Regarless of whether the border directory speaks LDAP or HTTP the 
> S/MIME client still needs a way to locate it via DNS. I do not believe
> that the global X.500 namespace is going to ever exist and even if
> it did, DNS and RFC822 are the Internet namespace. Hence the SRV
> record is still relevant.
> 
> 		Phill
> 

From: "Walter Williams" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Border directories
Date: Thu, 11 May 2000 14:19:05 -0400
Importance: Normal
Sender: [email-masked]

Last I checked, as the information is stored in a directory to begin with,
LDAP is not a middleman, but is doing things rather directly.  Doing an HTTP
Get presumes that this will find it in a Directory.  Probably you will find
that your HTTP needs a perl cgi which actually talks LDAP behind the scenes.
Don't forget HTTP is not a Directory Access Protocol, LDAP is, and the certs
are stored in a Directory.

Walt

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 12, 2000 6:06 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Border directories
>
>
> "Walter Williams" <[email-masked]> writes:
>
> >The major problem I see with using HTML is the need for the
> email client to
> >retrieve the public key.  They are designed to do this over
> LDAP.  Not all
> >email clients are integrated with a HTML reader.  The LDAP query is not
> >significant overhead and checks for public key data very transparently.
>
> Uhh... anything which can talk TCP/IP can do an HTML GET in about 10 lines
> of code and about 5 minutes of work.  When used as a
> cert-grabbing mechanism,
> I'd estimate that LDAP has about four orders of magnitude more
> overhead (in
> terms of code complexity) than HTML (probably more like five or six, going
> by the size of LDAP binaries).  I'm not sure what the performance
> overhead is
> but I can imagine that'd also be vastly higher.
>
> Given that in the end all you're doing is a 'SELECT cert WHERE
> name = foo',
> doing it via an HTTP GET makes much more sense than rewriting it into an
> LDAP query in the client, communicating it via an enormously complex and
> heavyweight protocol to the server, having the server rewrite it
> back into
> its original form so it can do something useful with it, and then
> reversing
> the process to return the result.  Sure, you get to say "We're
> using LDAP",
> but wouldn't it make more sense to cut out the middleman and do things
> directly?
>
> Peter.
>

From: "Walter Williams" <[email-masked]>
To: "Philip Hallam-Baker" <[email-masked]>, "ietf-smime" <[email-masked]>
Subject: RE: Border directories
Date: Thu, 11 May 2000 14:15:46 -0400
Importance: Normal
Sender: [email-masked]

The lovely thing about directories is that they can be chained rather easily
(Netscape as an exception here but that is one of the reasons Sun bought
Innosoft) so if you have access to one directory, that one might be chained
to one hundred and you would never know it.  I obviously need to give you
access to my directory to make this work.  Directories have not been over
sold, they've been under implemented.  That is changing fast.

Walt

> -----Original Message-----
> From: Philip Hallam-Baker [mailto:[email-masked]]
> Sent: Thursday, May 11, 2000 1:49 PM
> To: 'Walter Williams'; Philip Hallam-Baker; ietf-smime
> Subject: RE: Border directories
>
>
> HTTP, not HTML. An HTTP retrieval protocol can be written in 100
> lines by any competent coder in less than a day.
>
> And no, the email clients ability to do this over LDAP is not
> currently enough. My email client will not locate your cert because
> it is chained to only 8 directories.
>
> There is a need for email clients to be able to use SRV records to
> locate directories.
>
>
> My problem is not with the LDAP technology though but the market
> understanding thereof. Directories have been vastly oversold as
> a panacea for every IT problem.
>
> 		Phill
>
> -----Original Message-----
> From: Walter Williams [mailto:[email-masked]]
> Sent: Thursday, May 11, 2000 1:19 PM
> To: Philip Hallam-Baker; ietf-smime
> Subject: RE: Border directories
>
>
> The major problem I see with using HTML is the need for the email client
> to
> retrieve the public key.  They are designed to do this over LDAP.  Not
> all
> email clients are integrated with a HTML reader.  The LDAP query is not
> significant overhead and checks for public key data very transparently.
>
> While SMTP and LDAP have different name spaces, it is the responsibility
> of
> the directory manager to provide a mechanism to unify the name space of
> the
> SMTP alias in the certificate with the SMTP alias available in the
> directory.  Once this is done (rather simple actually) everything works,
> no
> matter how the DN is formatted.
>
> I strongly disagree that LDAP can not be used as an internet
> infrastructure
> by leveraging its use in the enterprise, and the market for various
> metadirectory products seems to back me up some what.
>
> Walt
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Philip Hallam-Baker
> > Sent: Thursday, May 11, 2000 11:13 AM
> > To: ietf-smime
> > Subject: Border directories
> >
> >
> > Re the W2K discussion:
> >
> > There is a problem with S/MIME's interaction with LDAP in general that
> > is certainly not unique to W2K. LDAP operates off a completely
> different
> > namespace to that of SMTP / RFC822. Furthermore there is no single
> > authoritative registrar for the X.500 namespace as there is for DNS
> (yes
> > I know that there are groups who claim that role but as far as I know
> > their authority is not generally observed).
> >
> > The application of LDAP as an enterprise infrastructure is not
> > compatible with its use as an internet infrastructure. An enterprise
> > directory has much more information than anyone is going to make
> > available outside the company for the likes of headhunters and
> > competitors.
> >
> >
> > The use of border directories is one possible solution. The DNS SRV
> > record provides a convenient means of locating a border directory.
> >
> > If however the border directory is only goiung to provide a
> certificate
> > lookup service why use LDAP when one can use HTTP with vastly less
> > overhead and pain? If one is not going to support indexing and search
> > facilities for the certificate repository why make them available at
> > all?
> >
> > I would quite like to see an SRV information service of the following
> > form defined:
> >
> >
> > Service Name _SMIME-HTTP
> >
> > Protocol function: For an RFC822 address of the form [email-masked] one
> or
> > more digital certificates are returned that provide a binding between
> > the name [email-masked] and one or more public keys.
> >
> > Protocol:
> >
> > 1) Obtain the SRV record _SMIME-HTTP.xyz.com
> > 	This contains the IP address a.b.c.d and the port p
> >
> > 2) Perform a retrieval query on http://a.b.c.d:p/ <name> ? <params>
> > 	The result of the query is the necessary S/MIME certificate (s)
> >
> > where <name> =
> > 	"mailto:[email-masked]" or Base64 ( SHA1 ( "mailto:[email-masked]"))
> > (which TBD)
> >
> > where <params> =
> > 	"something to do with specifying an acceptable certificate root"
> > 	"something to do with whether intermediate certs are required"
> > 	"something to do with the acceptable certificate format -
> > default X.509v3 but support DNSSEC, PGP, SPKI, NYI etc"
> > 	"something that we thought up in the bar late one night at the
> > IETF"
> >
> >
> > My personal prefferance would be fgor the SHA1 blinded query since it
> > compresses the querry and emphasizes the fact that searching for names
> > ain't going to be a supported feature but it does not really make the
> > job of searching any harder in reality.
> >
> >
> > 		Phill
> >
>

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Border directories
Reply-To: [email-masked]
Date: Fri, 12 May 2000 06:06:19 (NZST)
Sender: [email-masked]

"Walter Williams" <[email-masked]> writes:

>The major problem I see with using HTML is the need for the email client to
>retrieve the public key.  They are designed to do this over LDAP.  Not all
>email clients are integrated with a HTML reader.  The LDAP query is not
>significant overhead and checks for public key data very transparently.

Uhh... anything which can talk TCP/IP can do an HTML GET in about 10 lines
of code and about 5 minutes of work.  When used as a cert-grabbing mechanism,
I'd estimate that LDAP has about four orders of magnitude more overhead (in
terms of code complexity) than HTML (probably more like five or six, going
by the size of LDAP binaries).  I'm not sure what the performance overhead is 
but I can imagine that'd also be vastly higher.

Given that in the end all you're doing is a 'SELECT cert WHERE name = foo',
doing it via an HTTP GET makes much more sense than rewriting it into an
LDAP query in the client, communicating it via an enormously complex and
heavyweight protocol to the server, having the server rewrite it back into 
its original form so it can do something useful with it, and then reversing 
the process to return the result.  Sure, you get to say "We're using LDAP",
but wouldn't it make more sense to cut out the middleman and do things
directly?

Peter.

From: Philip Hallam-Baker <[email-masked]>
To: "'Walter Williams'" <[email-masked]>, Philip Hallam-Baker <[email-masked]>, ietf-smime <[email-masked]>
Subject: RE: Border directories
Date: Thu, 11 May 2000 10:48:34 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_003E_01BFBB4F.C00FE1A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

HTTP, not HTML. An HTTP retrieval protocol can be written in 100
lines by any competent coder in less than a day.

And no, the email clients ability to do this over LDAP is not
currently enough. My email client will not locate your cert because
it is chained to only 8 directories.

There is a need for email clients to be able to use SRV records to
locate directories.

My problem is not with the LDAP technology though but the market 
understanding thereof. Directories have been vastly oversold as
a panacea for every IT problem.

		Phill

-----Original Message-----
From: Walter Williams [mailto:[email-masked]]
Sent: Thursday, May 11, 2000 1:19 PM
To: Philip Hallam-Baker; ietf-smime
Subject: RE: Border directories

The major problem I see with using HTML is the need for the email client
to
retrieve the public key.  They are designed to do this over LDAP.  Not
all
email clients are integrated with a HTML reader.  The LDAP query is not
significant overhead and checks for public key data very transparently.

While SMTP and LDAP have different name spaces, it is the responsibility
of
the directory manager to provide a mechanism to unify the name space of
the
SMTP alias in the certificate with the SMTP alias available in the
directory.  Once this is done (rather simple actually) everything works,
no
matter how the DN is formatted.

I strongly disagree that LDAP can not be used as an internet
infrastructure
by leveraging its use in the enterprise, and the market for various
metadirectory products seems to back me up some what.

Walt

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Philip Hallam-Baker
> Sent: Thursday, May 11, 2000 11:13 AM
> To: ietf-smime
> Subject: Border directories
>
>
> Re the W2K discussion:
>
> There is a problem with S/MIME's interaction with LDAP in general that
> is certainly not unique to W2K. LDAP operates off a completely
different
> namespace to that of SMTP / RFC822. Furthermore there is no single
> authoritative registrar for the X.500 namespace as there is for DNS
(yes
> I know that there are groups who claim that role but as far as I know
> their authority is not generally observed).
>
> The application of LDAP as an enterprise infrastructure is not
> compatible with its use as an internet infrastructure. An enterprise
> directory has much more information than anyone is going to make
> available outside the company for the likes of headhunters and
> competitors.
>
>
> The use of border directories is one possible solution. The DNS SRV
> record provides a convenient means of locating a border directory.
>
> If however the border directory is only goiung to provide a
certificate
> lookup service why use LDAP when one can use HTTP with vastly less
> overhead and pain? If one is not going to support indexing and search
> facilities for the certificate repository why make them available at
> all?
>
> I would quite like to see an SRV information service of the following
> form defined:
>
>
> Service Name _SMIME-HTTP
>
> Protocol function: For an RFC822 address of the form [email-masked] one
or
> more digital certificates are returned that provide a binding between
> the name [email-masked] and one or more public keys.
>
> Protocol:
>
> 1) Obtain the SRV record _SMIME-HTTP.xyz.com
> 	This contains the IP address a.b.c.d and the port p
>
> 2) Perform a retrieval query on http://a.b.c.d:p/ <name> ? <params>
> 	The result of the query is the necessary S/MIME certificate (s)
>
> where <name> =
> 	"mailto:[email-masked]" or Base64 ( SHA1 ( "mailto:[email-masked]"))
> (which TBD)
>
> where <params> =
> 	"something to do with specifying an acceptable certificate root"
> 	"something to do with whether intermediate certs are required"
> 	"something to do with the acceptable certificate format -
> default X.509v3 but support DNSSEC, PGP, SPKI, NYI etc"
> 	"something that we thought up in the bar late one night at the
> IETF"
>
>
> My personal prefferance would be fgor the SHA1 blinded query since it
> compresses the querry and emphasizes the fact that searching for names
> ain't going to be a supported feature but it does not really make the
> job of searching any harder in reality.
>
>
> 		Phill
>

------=_NextPart_000_003E_01BFBB4F.C00FE1A0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_003E_01BFBB4F.C00FE1A0--

From: "Walter Williams" <[email-masked]>
To: "Philip Hallam-Baker" <[email-masked]>, "ietf-smime" <[email-masked]>
Subject: RE: Border directories
Date: Thu, 11 May 2000 13:19:17 -0400
Importance: Normal
Sender: [email-masked]

The major problem I see with using HTML is the need for the email client to
retrieve the public key.  They are designed to do this over LDAP.  Not all
email clients are integrated with a HTML reader.  The LDAP query is not
significant overhead and checks for public key data very transparently.

While SMTP and LDAP have different name spaces, it is the responsibility of
the directory manager to provide a mechanism to unify the name space of the
SMTP alias in the certificate with the SMTP alias available in the
directory.  Once this is done (rather simple actually) everything works, no
matter how the DN is formatted.

I strongly disagree that LDAP can not be used as an internet infrastructure
by leveraging its use in the enterprise, and the market for various
metadirectory products seems to back me up some what.

Walt

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Philip Hallam-Baker
> Sent: Thursday, May 11, 2000 11:13 AM
> To: ietf-smime
> Subject: Border directories
>
>
> Re the W2K discussion:
>
> There is a problem with S/MIME's interaction with LDAP in general that
> is certainly not unique to W2K. LDAP operates off a completely different
> namespace to that of SMTP / RFC822. Furthermore there is no single
> authoritative registrar for the X.500 namespace as there is for DNS (yes
> I know that there are groups who claim that role but as far as I know
> their authority is not generally observed).
>
> The application of LDAP as an enterprise infrastructure is not
> compatible with its use as an internet infrastructure. An enterprise
> directory has much more information than anyone is going to make
> available outside the company for the likes of headhunters and
> competitors.
>
>
> The use of border directories is one possible solution. The DNS SRV
> record provides a convenient means of locating a border directory.
>
> If however the border directory is only goiung to provide a certificate
> lookup service why use LDAP when one can use HTTP with vastly less
> overhead and pain? If one is not going to support indexing and search
> facilities for the certificate repository why make them available at
> all?
>
> I would quite like to see an SRV information service of the following
> form defined:
>
>
> Service Name _SMIME-HTTP
>
> Protocol function: For an RFC822 address of the form [email-masked] one or
> more digital certificates are returned that provide a binding between
> the name [email-masked] and one or more public keys.
>
> Protocol:
>
> 1) Obtain the SRV record _SMIME-HTTP.xyz.com
> 	This contains the IP address a.b.c.d and the port p
>
> 2) Perform a retrieval query on http://a.b.c.d:p/ <name> ? <params>
> 	The result of the query is the necessary S/MIME certificate (s)
>
> where <name> =
> 	"mailto:[email-masked]" or Base64 ( SHA1 ( "mailto:[email-masked]"))
> (which TBD)
>
> where <params> =
> 	"something to do with specifying an acceptable certificate root"
> 	"something to do with whether intermediate certs are required"
> 	"something to do with the acceptable certificate format -
> default X.509v3 but support DNSSEC, PGP, SPKI, NYI etc"
> 	"something that we thought up in the bar late one night at the
> IETF"
>
>
> My personal prefferance would be fgor the SHA1 blinded query since it
> compresses the querry and emphasizes the fact that searching for names
> ain't going to be a supported feature but it does not really make the
> job of searching any harder in reality.
>
>
> 		Phill
>

Reply-to: [email-masked]
From: "Piers Chivers" <[email-masked]>
To: "'Walter Williams'" <[email-masked]>, "'Dennis Glatting'" <[email-masked]>
cc: "'Laurent Deffranne'" <[email-masked]>, "'ietf-smime'" <[email-masked]>
Subject: RE: Does Slime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 18:26:42 +0100
Importance: Normal
Sender: [email-masked]

Win2k and hence AD has a good level of security granularity on objects and
attributes that are exposed in the directory.  For instance, you could
configure AD to expose only the LDAP attributes that should be publicly
available when a user binds anonymously (eg comes in other the Internet).
Having said that, it would be a brave person who 'trusts' Win2k enough to
co-locate their corporate data with public data.  The proxy is probably a
better idea.

Piers

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Walter Williams
Sent: 11 May 2000 15:39
To: Dennis Glatting
Cc: Laurent Deffranne; ietf-smime
Subject: RE: Does Slime works fine with Windows 2000 PKI

Again, all this depends on content made available through the proxy.  You
can, of course require access to any directory to be over authenticated bind
into the directory, but that requires maintaing a user id and pw for anyone
external to your company who wants to use s/mime.  This is one of the
reasons for Directory sync, it allows business partners to share directory
information.  That is why standards compliance is an issue here, and again,
active directory will require a metadirectory connector to many of the
directories already deployed.

Walt

> -----Original Message-----
> From: Dennis Glatting [mailto:[email-masked]]
> Sent: Thursday, May 11, 2000 10:36 AM
> To: Walter Williams
> Cc: Laurent Deffranne; ietf-smime
> Subject: Re: Does Slime works fine with Windows 2000 PKI
>
>
> Walter Williams wrote:
> >
> > Active directory would expose a significant amount of
> information you might
> > not want the external world to know, such as a complete listing
> of all your
> > w2k computers and their roles in your network.  You could use a
> LDAP proxy
> > server to provide what you want to the internet and keep the
> data in active
> > directory.  Innosoft (Now purchased by IPlanet) makes such a
> product.  There
> > are probably others on the market.
> >
>
> Question:
> 	Would it also disclose the name of all of the
> 	employees and their roles, something many
> 	outside recruiters would love to know?
>
>
> > > -----Original Message-----
> > > From: Laurent Deffranne [mailto:[email-masked]]
> > > Sent: Thursday, May 11, 2000 9:48 AM
> > > To: walter.williams
> > > Cc: ietf-smime
> > > Subject: RE: Does Smime works fine with Windows 2000 PKI
> > >
> > >
> > > What would happen if you want to open the directory to anonymous
> > > access to the Web ?
> > > In such a way that you could exchange S/MIME certs with
> outside people ?
> > >
> > >
> > >
> > >
> > >
> > >
> > > walter.williams%genuity.com@Internet
> > > 11/05/2000 15:35
> > > To:   Laurent Deffranne/GKBCCB@GKBCCB
> > > cc:   ietf-smime%imc.org@Internet
> > >
> > > Subject:      RE: Does Smime works fine with Windows 2000 PKI
> > >
> > > Let me take the points one at a time and inline:
> > >
> > > > -----Original Message-----
> > > > From: Laurent Deffranne [mailto:[email-masked]]
> > > > Sent: Thursday, May 11, 2000 9:19 AM
> > > > To: walter.williams
> > > > Cc: ietf-smime
> > > > Subject: RE: Does Smime works fine with Windows 2000 PKI
> > > >
> > > >
> > > > Walt,
> > > >
> > > > Do you mean that there are difficulties to access through LDAP an
> > > > Active Directory, as you want to read or use X509 certificates ?
> > > >
> > >
> > > No.  However, are you going to open your active directory to
> > > anonymous LDAP
> > > queries over the Internet?  If not, are you limiting S/MIME to
> > > internal use
> > > only?  If not then you are somewhat back to square one.
> > >
> > > > By the way,does somebody know issues about Active Directory LDAP,
> > > > or issues to read a certificate in an Active Directory ?
> > >
> > > This worked just fine for us here, but the problem we had
> with AD was that
> > > it does not support inetOrgPerson, and thus can't easily be
> > > synched up with
> > > most external LDAP directories.  You'll find you'll want a
> metadirectory
> > > connector to synch it with any external directory.  Again,
> this is not an
> > > issue if you're willing to directly expose AD to internet use.
> > > >
> > > > For me it would be a mistake to use now the "brand new" Active
> > > > Directory, but if someone could tell me where I can find proofs
> > > > of lack of compatibility (from Microsoft, there must be surely
> > > > one of two), this would interrest me.
> > > >
> > > AD seems to work just fine, if you don't mind working with
> > > something with a
> > > proprietary schema.  Any LDAP and S/MIME aware client we pointed at it
> > > understood the contents just fine, so the schema does not
> seem to impact
> > > client interoperability.
> > >
> > > > Laurent
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > walter.williams%genuity.com@Internet
> > > > 11/05/2000 14:54
> > > > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
> > > > cc:
> > > >
> > > > Subject:    RE: Does Smime works fine with Windows 2000 PKI
> > > >
> > > > Laurent;
> > > >
> > > > Yes, certs issued from a W2K CA can be used for S/MIME, and no
> > > > less so than
> > > > certs issued from Baltimore, Iplanet or any other CA vendor or
> > > > product.  The
> > > > main issue is not will they work, but will you be able to
> validate the
> > > > certs.  Unless the person issuing the cert from W2K has
> > > provided you with
> > > > their server's cert, or they have certified their CA with the
> > > signature of
> > > > the publicly known CAs you will not be able to easily verify
> > > the signature
> > > > to its source.  This is not the most technically acurate way of
> > > > saying this
> > > > but I'm not awake yet.  Baltimore has preregistered there
> CA with the
> > > > vendors distributing products, as has Verisign, Thaught, and
> > > many others.
> > > > Just make certain that you have the certificates for the W2K CA,
> > > > and access
> > > > to its revocation list so you can validate properly and
> you'll be fine.
> > > >
> > > > Walt Williams
> > > > TSD-Systems
> > > > Senior IT Analyst
> > > > Genuity
> > > > www.genuity.com
> > > >
> > > > Please note: GTE Internetworking is now Genuity.
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]]On Behalf Of
> Laurent Deffranne
> > > > > Sent: Thursday, May 11, 2000 5:45 AM
> > > > > To: ietf-smime
> > > > > Subject: Does Smime works fine with Windows 2000 PKI
> > > > >
> > > > >
> > > > > Hi everybody,
> > > > >
> > > > > Just a question :
> > > > >
> > > > > Is there any known issues using S/MIME with
> Win2000PKI-certificates ?
> > > > > More generally, are Win2000 certificates usable with (and
> > > > > understood by ) the others mailers (especially Lotus Notes,
> > > > > Netscape, Eudora +plug-in?)
> > > > >
> > > > > Isn't Baltimore Unicert a "better choice" due to its greater
> > > > > compatibility ?
> > > > >
> > > > > Any advices are welcome.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Laurent Deffranne
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
>
>
> --
> Dennis Glatting
> Copyright (c) 2000 Software Munitions
>

Reply-to: [email-masked]
From: "Piers Chivers" <[email-masked]>
To: "'Laurent Deffranne'" <[email-masked]>, "'walter.williams'" <[email-masked]>
cc: "'ietf-smime'" <[email-masked]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 18:16:59 +0100
Importance: Normal
Sender: [email-masked]

MS have published a White Paper on Win2k PKI interoperability with other
leading PKI vendor products.  The WP is available on their MSDN website
(can't remember where but it's called win2kpkinterop.doc).

In my experience Win2k PKI is excellent as choice for an Enterprise PKI.  It
integrates well with AD (not surprisingly).  However, as a commercial PKI
the best thing that can be said about it is that it is free.  And that
probably sums it up succintly.

Piers

-----Original Message-----
From: Laurent Deffranne [mailto:[email-masked]]
Sent: 11 May 2000 14:19
To: walter.williams
Cc: ietf-smime
Subject: RE: Does Smime works fine with Windows 2000 PKI

Walt,

Do you mean that there are difficulties to access through LDAP an Active
Directory, as you want to read or use X509 certificates ?

By the way,does somebody know issues about Active Directory LDAP, or
issues to read a certificate in an Active Directory ?

For me it would be a mistake to use now the "brand new" Active
Directory, but if someone could tell me where I can find proofs of lack
of compatibility (from Microsoft, there must be surely one of two), this
would interrest me.

Laurent

walter.williams%genuity.com@Internet
11/05/2000 14:54
To:	Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
cc:

Subject:	RE: Does Smime works fine with Windows 2000 PKI

Laurent;

Yes, certs issued from a W2K CA can be used for S/MIME, and no less so
than
certs issued from Baltimore, Iplanet or any other CA vendor or product.
The
main issue is not will they work, but will you be able to validate the
certs.  Unless the person issuing the cert from W2K has provided you
with
their server's cert, or they have certified their CA with the signature
of
the publicly known CAs you will not be able to easily verify the
signature
to its source.  This is not the most technically acurate way of saying
this
but I'm not awake yet.  Baltimore has preregistered there CA with the
vendors distributing products, as has Verisign, Thaught, and many
others.
Just make certain that you have the certificates for the W2K CA, and
access
to its revocation list so you can validate properly and you'll be fine.

Walt Williams
TSD-Systems
Senior IT Analyst
Genuity
www.genuity.com

Please note: GTE Internetworking is now Genuity.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Laurent Deffranne
> Sent: Thursday, May 11, 2000 5:45 AM
> To: ietf-smime
> Subject: Does Smime works fine with Windows 2000 PKI
>
>
> Hi everybody,
>
> Just a question :
>
> Is there any known issues using S/MIME with Win2000PKI-certificates ?
> More generally, are Win2000 certificates usable with (and
> understood by ) the others mailers (especially Lotus Notes,
> Netscape, Eudora +plug-in?)
>
> Isn't Baltimore Unicert a "better choice" due to its greater
> compatibility ?
>
> Any advices are welcome.
>
> Regards,
>
> Laurent Deffranne

From: Philip Hallam-Baker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: Does Slime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 09:50:50 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01BFBB47.B056BD90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>One would think that if you have no control over what is shown and what
is not
>shown, that you have effectively lost control of your LDAP systems. 

Hey, misconfigured 'stuff' is a major cause of security problems.

The problem I encounter very often is the cost of making sure that
'stuff' remains well configured.

That is why I prefer infrastructure that is narrowly focused on a 
single function rather than broad-band approaches. 

Regarless of whether the border directory speaks LDAP or HTTP the 
S/MIME client still needs a way to locate it via DNS. I do not believe
that the global X.500 namespace is going to ever exist and even if
it did, DNS and RFC822 are the Internet namespace. Hence the SRV
record is still relevant.

		Phill

------=_NextPart_000_000B_01BFBB47.B056BD90
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_000B_01BFBB47.B056BD90--

From: [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Date: Thu, 11 May 2000 12:13:17 -0400
Subject: Re: Does Slime works fine with Windows 2000 PKI
Sender: [email-masked]

One would think that if you have no control over what is shown and what is not
shown, that you have effectively lost control of your LDAP systems. Which any
outside anyone would love to know, competitors, recruiters, hackers. Just look
at the locator info for some places over the web, you can get info down to the
room number, telephone, wifes name, everything without even trying too hard.
(You just have to be able to type M* to get all names with M in it).

Great fun. I wonder if you could front end the whole thing via HTML/XML so any
request on the LDAP or for S/Mime services would be directed to the web front
end, with the proper controls?

r/
Dan Morrill
CSC

[email-masked] on 05/11/2000 10:35:42 AM

To:   [email-masked]
cc:   [email-masked], [email-masked] (bcc: Ralph D
      Morrill/DEF/CSC)
Subject:  Re: Does Slime works fine with Windows 2000 PKI

Walter Williams wrote:
>
> Active directory would expose a significant amount of information you might
> not want the external world to know, such as a complete listing of all your
> w2k computers and their roles in your network.  You could use a LDAP proxy
> server to provide what you want to the internet and keep the data in active
> directory.  Innosoft (Now purchased by IPlanet) makes such a product.  There
> are probably others on the market.
>

Question:
     Would it also disclose the name of all of the
     employees and their roles, something many
     outside recruiters would love to know?

> > -----Original Message-----
> > From: Laurent Deffranne [mailto:[email-masked]]
> > Sent: Thursday, May 11, 2000 9:48 AM
> > To: walter.williams
> > Cc: ietf-smime
> > Subject: RE: Does Smime works fine with Windows 2000 PKI
> >
> >
> > What would happen if you want to open the directory to anonymous
> > access to the Web ?
> > In such a way that you could exchange S/MIME certs with outside people ?
> >
> >
> >
> >
> >
> >
> > walter.williams%genuity.com@Internet
> > 11/05/2000 15:35
> > To:   Laurent Deffranne/GKBCCB@GKBCCB
> > cc:   ietf-smime%imc.org@Internet
> >
> > Subject:      RE: Does Smime works fine with Windows 2000 PKI
> >
> > Let me take the points one at a time and inline:
> >
> > > -----Original Message-----
> > > From: Laurent Deffranne [mailto:[email-masked]]
> > > Sent: Thursday, May 11, 2000 9:19 AM
> > > To: walter.williams
> > > Cc: ietf-smime
> > > Subject: RE: Does Smime works fine with Windows 2000 PKI
> > >
> > >
> > > Walt,
> > >
> > > Do you mean that there are difficulties to access through LDAP an
> > > Active Directory, as you want to read or use X509 certificates ?
> > >
> >
> > No.  However, are you going to open your active directory to
> > anonymous LDAP
> > queries over the Internet?  If not, are you limiting S/MIME to
> > internal use
> > only?  If not then you are somewhat back to square one.
> >
> > > By the way,does somebody know issues about Active Directory LDAP,
> > > or issues to read a certificate in an Active Directory ?
> >
> > This worked just fine for us here, but the problem we had with AD was that
> > it does not support inetOrgPerson, and thus can't easily be
> > synched up with
> > most external LDAP directories.  You'll find you'll want a metadirectory
> > connector to synch it with any external directory.  Again, this is not an
> > issue if you're willing to directly expose AD to internet use.
> > >
> > > For me it would be a mistake to use now the "brand new" Active
> > > Directory, but if someone could tell me where I can find proofs
> > > of lack of compatibility (from Microsoft, there must be surely
> > > one of two), this would interrest me.
> > >
> > AD seems to work just fine, if you don't mind working with
> > something with a
> > proprietary schema.  Any LDAP and S/MIME aware client we pointed at it
> > understood the contents just fine, so the schema does not seem to impact
> > client interoperability.
> >
> > > Laurent
> > >
> > >
> > >
> > >
> > >
> > > walter.williams%genuity.com@Internet
> > > 11/05/2000 14:54
> > > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
> > > cc:
> > >
> > > Subject:    RE: Does Smime works fine with Windows 2000 PKI
> > >
> > > Laurent;
> > >
> > > Yes, certs issued from a W2K CA can be used for S/MIME, and no
> > > less so than
> > > certs issued from Baltimore, Iplanet or any other CA vendor or
> > > product.  The
> > > main issue is not will they work, but will you be able to validate the
> > > certs.  Unless the person issuing the cert from W2K has
> > provided you with
> > > their server's cert, or they have certified their CA with the
> > signature of
> > > the publicly known CAs you will not be able to easily verify
> > the signature
> > > to its source.  This is not the most technically acurate way of
> > > saying this
> > > but I'm not awake yet.  Baltimore has preregistered there CA with the
> > > vendors distributing products, as has Verisign, Thaught, and
> > many others.
> > > Just make certain that you have the certificates for the W2K CA,
> > > and access
> > > to its revocation list so you can validate properly and you'll be fine.
> > >
> > > Walt Williams
> > > TSD-Systems
> > > Senior IT Analyst
> > > Genuity
> > > www.genuity.com
> > >
> > > Please note: GTE Internetworking is now Genuity.
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]]On Behalf Of Laurent Deffranne
> > > > Sent: Thursday, May 11, 2000 5:45 AM
> > > > To: ietf-smime
> > > > Subject: Does Smime works fine with Windows 2000 PKI
> > > >
> > > >
> > > > Hi everybody,
> > > >
> > > > Just a question :
> > > >
> > > > Is there any known issues using S/MIME with Win2000PKI-certificates ?
> > > > More generally, are Win2000 certificates usable with (and
> > > > understood by ) the others mailers (especially Lotus Notes,
> > > > Netscape, Eudora +plug-in?)
> > > >
> > > > Isn't Baltimore Unicert a "better choice" due to its greater
> > > > compatibility ?
> > > >
> > > > Any advices are welcome.
> > > >
> > > > Regards,
> > > >
> > > > Laurent Deffranne
> > >
> > >
> > >
> > >
> >
> >
> >

--
Dennis Glatting
Copyright (c) 2000 Software Munitions

Reply-To: "Colin.Robbins" <[email-masked]>
From: Colin Robbins <[email-masked]>
To: "'Philip Hallam-Baker'" <[email-masked]>, "'ietf-smime'" <[email-masked]>
Subject: RE: Border directories
Date: Thu, 11 May 2000 17:19:32 +0100
Importance: Normal
Sender: [email-masked]

Phill,

This looks like a potential approach if you consider certificate recovery
only.   However, there are several other reasons why Border Directories are
required in a corporate infrastructure.
E.g., Sharing directory information with business partners - you many want
them to have access to email addresses, but not home telephone numbers.
E.g., Providing different access to employees depending on whether they are
currently inside or outside of your firewall.
E.g., Allowing different access modes, for example preventing LDAP modify
operations entering your network from untrusted sites.

Colin

And just to add our name to the list -  NEXOR has an LDAP proxy product as
well!

>
> The use of border directories is one possible solution. The DNS SRV
> record provides a convenient means of locating a border directory.
>
> If however the border directory is only goiung to provide a
> certificate
> lookup service why use LDAP when one can use HTTP with vastly less
> overhead and pain? If one is not going to support indexing and search
> facilities for the certificate repository why make them available at
> all?
>
> I would quite like to see an SRV information service of the following
> form defined:
>
>
> Service Name _SMIME-HTTP
>
> Protocol function: For an RFC822 address of the form
> [email-masked] one or
> more digital certificates are returned that provide a binding between
> the name [email-masked] and one or more public keys.
>
> Protocol:
>
> 1) Obtain the SRV record _SMIME-HTTP.xyz.com
> 	This contains the IP address a.b.c.d and the port p
>
> 2) Perform a retrieval query on http://a.b.c.d:p/ <name> ? <params>
> 	The result of the query is the necessary S/MIME certificate (s)
>
> where <name> =
> 	"mailto:[email-masked]" or Base64 ( SHA1 ( "mailto:[email-masked]"))
> (which TBD)
>
> where <params> =
> 	"something to do with specifying an acceptable certificate root"
> 	"something to do with whether intermediate certs are required"
> 	"something to do with the acceptable certificate format -
> default X.509v3 but support DNSSEC, PGP, SPKI, NYI etc"
> 	"something that we thought up in the bar late one night at the
> IETF"
>
>
> My personal prefferance would be fgor the SHA1 blinded query since it
> compresses the querry and emphasizes the fact that searching for names
> ain't going to be a supported feature but it does not really make the
> job of searching any harder in reality.
>
>
> 		Phill
>

From: "Frank W. Nolden" <[email-masked]>
To: "Walter Williams" <[email-masked]>, "Laurent Deffranne" <[email-masked]>
Cc: "ietf-smime" <[email-masked]>
Subject: Re: Does Slime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 17:17:27 +0200
Sender: [email-masked]

Sorry for jumping into this discussion, which I find very interesting. There
is a way of publishing certificates to the outside world without opening up
the AD. I think Walter mentioned in already and that is replicating only the
certificate information (with some minor additional information like
emailaddress, distinguished name, surname, tc) to an (LDAP) directory that
is connected to the internet. Replicating this information cannot be done
using the standard X.500 DISP protocol since Microsoft does not support
that, but you can use LDIF files and other more sophisticated tools like our
MaXware Directory Sync Engine. You could put LDAP proxy servers (MaXware
also has these available as Innosoft does) in front of that for security
purposes and attribute mapping.

A major advantage is that you do not permit anyone in real time either via a
proxy or not to access information in the AD. An extra (LDAP) directory is
an extra security barrier to your AD and it will only publish the
information you want to be available on the web, without risking access to
your AD and without configuring the Access Control in AD.
Regards,

Frank Nolden

----- Original Message -----
From: "Walter Williams" <[email-masked]>
To: "Laurent Deffranne" <[email-masked]>
Cc: "ietf-smime" <[email-masked]>
Sent: Thursday, May 11, 2000 15:57
Subject: RE: Does Slime works fine with Windows 2000 PKI

> Active directory would expose a significant amount of information you
might
> not want the external world to know, such as a complete listing of all
your
> w2k computers and their roles in your network.  You could use a LDAP proxy
> server to provide what you want to the internet and keep the data in
active
> directory.  Innosoft (Now purchased by IPlanet) makes such a product.
There
> are probably others on the market.
>
> > -----Original Message-----
> > From: Laurent Deffranne [mailto:[email-masked]]
> > Sent: Thursday, May 11, 2000 9:48 AM
> > To: walter.williams
> > Cc: ietf-smime
> > Subject: RE: Does Smime works fine with Windows 2000 PKI
> >
> >
> > What would happen if you want to open the directory to anonymous
> > access to the Web ?
> > In such a way that you could exchange S/MIME certs with outside people ?
> >
> >
> >
> >
> >
> >
> > walter.williams%genuity.com@Internet
> > 11/05/2000 15:35
> > To: Laurent Deffranne/GKBCCB@GKBCCB
> > cc: ietf-smime%imc.org@Internet
> >
> > Subject: RE: Does Smime works fine with Windows 2000 PKI
> >
> > Let me take the points one at a time and inline:
> >
> > > -----Original Message-----
> > > From: Laurent Deffranne [mailto:[email-masked]]
> > > Sent: Thursday, May 11, 2000 9:19 AM
> > > To: walter.williams
> > > Cc: ietf-smime
> > > Subject: RE: Does Smime works fine with Windows 2000 PKI
> > >
> > >
> > > Walt,
> > >
> > > Do you mean that there are difficulties to access through LDAP an
> > > Active Directory, as you want to read or use X509 certificates ?
> > >
> >
> > No.  However, are you going to open your active directory to
> > anonymous LDAP
> > queries over the Internet?  If not, are you limiting S/MIME to
> > internal use
> > only?  If not then you are somewhat back to square one.
> >
> > > By the way,does somebody know issues about Active Directory LDAP,
> > > or issues to read a certificate in an Active Directory ?
> >
> > This worked just fine for us here, but the problem we had with AD was
that
> > it does not support inetOrgPerson, and thus can't easily be
> > synched up with
> > most external LDAP directories.  You'll find you'll want a metadirectory
> > connector to synch it with any external directory.  Again, this is not
an
> > issue if you're willing to directly expose AD to internet use.
> > >
> > > For me it would be a mistake to use now the "brand new" Active
> > > Directory, but if someone could tell me where I can find proofs
> > > of lack of compatibility (from Microsoft, there must be surely
> > > one of two), this would interrest me.
> > >
> > AD seems to work just fine, if you don't mind working with
> > something with a
> > proprietary schema.  Any LDAP and S/MIME aware client we pointed at it
> > understood the contents just fine, so the schema does not seem to impact
> > client interoperability.
> >
> > > Laurent
> > >
> > >
> > >
> > >
> > >
> > > walter.williams%genuity.com@Internet
> > > 11/05/2000 14:54
> > > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
> > > cc:
> > >
> > > Subject: RE: Does Smime works fine with Windows 2000 PKI
> > >
> > > Laurent;
> > >
> > > Yes, certs issued from a W2K CA can be used for S/MIME, and no
> > > less so than
> > > certs issued from Baltimore, Iplanet or any other CA vendor or
> > > product.  The
> > > main issue is not will they work, but will you be able to validate the
> > > certs.  Unless the person issuing the cert from W2K has
> > provided you with
> > > their server's cert, or they have certified their CA with the
> > signature of
> > > the publicly known CAs you will not be able to easily verify
> > the signature
> > > to its source.  This is not the most technically acurate way of
> > > saying this
> > > but I'm not awake yet.  Baltimore has preregistered there CA with the
> > > vendors distributing products, as has Verisign, Thaught, and
> > many others.
> > > Just make certain that you have the certificates for the W2K CA,
> > > and access
> > > to its revocation list so you can validate properly and you'll be
fine.
> > >
> > > Walt Williams
> > > TSD-Systems
> > > Senior IT Analyst
> > > Genuity
> > > www.genuity.com
> > >
> > > Please note: GTE Internetworking is now Genuity.
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]]On Behalf Of Laurent Deffranne
> > > > Sent: Thursday, May 11, 2000 5:45 AM
> > > > To: ietf-smime
> > > > Subject: Does Smime works fine with Windows 2000 PKI
> > > >
> > > >
> > > > Hi everybody,
> > > >
> > > > Just a question :
> > > >
> > > > Is there any known issues using S/MIME with Win2000PKI-certificates
?
> > > > More generally, are Win2000 certificates usable with (and
> > > > understood by ) the others mailers (especially Lotus Notes,
> > > > Netscape, Eudora +plug-in?)
> > > >
> > > > Isn't Baltimore Unicert a "better choice" due to its greater
> > > > compatibility ?
> > > >
> > > > Any advices are welcome.
> > > >
> > > > Regards,
> > > >
> > > > Laurent Deffranne
> > >
> > >
> > >
> > >
> >
> >
> >
>
>

From: Philip Hallam-Baker <[email-masked]>
To: "'Walter Williams'" <[email-masked]>, Laurent Deffranne <[email-masked]>, ietf-smime <[email-masked]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 08:12:48 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01BFBB39.FDB94250
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Actually it is possible to issue certs with W2K that are recognized
automatically by other mail recipients with the VeriSign Gateway CA 
product. In practice however this does not remove the obligation to
employ the required authentication standards...

In general however interroperability is not a market differentiator
that should provide a major competative advantage. If only one vendor
can claim to be interoperable something odd is happening.

It is failure to interoperate that is a market disadvantage!

IETF mailing lists are not a good place for discussing, plugging 
specific vendor products (although most folk feel free to correct
erroneous statements about their product like I did). 

		Phill

------=_NextPart_000_000A_01BFBB39.FDB94250
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_000A_01BFBB39.FDB94250--

From: Philip Hallam-Baker <[email-masked]>
To: ietf-smime <[email-masked]>
Subject: Border directories
Date: Thu, 11 May 2000 08:13:27 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01BFBB3A.158A5DB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Re the W2K discussion:

There is a problem with S/MIME's interaction with LDAP in general that
is certainly not unique to W2K. LDAP operates off a completely different
namespace to that of SMTP / RFC822. Furthermore there is no single
authoritative registrar for the X.500 namespace as there is for DNS (yes
I know that there are groups who claim that role but as far as I know
their authority is not generally observed).

The application of LDAP as an enterprise infrastructure is not
compatible with its use as an internet infrastructure. An enterprise
directory has much more information than anyone is going to make
available outside the company for the likes of headhunters and
competitors.

The use of border directories is one possible solution. The DNS SRV
record provides a convenient means of locating a border directory.

If however the border directory is only goiung to provide a certificate
lookup service why use LDAP when one can use HTTP with vastly less
overhead and pain? If one is not going to support indexing and search
facilities for the certificate repository why make them available at
all?

I would quite like to see an SRV information service of the following
form defined:

Service Name _SMIME-HTTP

Protocol function: For an RFC822 address of the form [email-masked] one or
more digital certificates are returned that provide a binding between
the name [email-masked] and one or more public keys.

Protocol:

1) Obtain the SRV record _SMIME-HTTP.xyz.com
	This contains the IP address a.b.c.d and the port p

2) Perform a retrieval query on http://a.b.c.d:p/ <name> ? <params>
	The result of the query is the necessary S/MIME certificate (s)

where <name> =
	"mailto:[email-masked]" or Base64 ( SHA1 ( "mailto:[email-masked]"))
(which TBD)

where <params> =
	"something to do with specifying an acceptable certificate root"
	"something to do with whether intermediate certs are required"
	"something to do with the acceptable certificate format -
default X.509v3 but support DNSSEC, PGP, SPKI, NYI etc"
	"something that we thought up in the bar late one night at the
IETF"

My personal prefferance would be fgor the SHA1 blinded query since it
compresses the querry and emphasizes the fact that searching for names
ain't going to be a supported feature but it does not really make the
job of searching any harder in reality.

		Phill

------=_NextPart_000_000F_01BFBB3A.158A5DB0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_000F_01BFBB3A.158A5DB0--

From: "Walter Williams" <[email-masked]>
To: "Dennis Glatting" <[email-masked]>
Cc: "Laurent Deffranne" <[email-masked]>, "ietf-smime" <[email-masked]>
Subject: RE: Does Slime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 10:39:21 -0400
Importance: Normal
Sender: [email-masked]

Again, all this depends on content made available through the proxy.  You
can, of course require access to any directory to be over authenticated bind
into the directory, but that requires maintaing a user id and pw for anyone
external to your company who wants to use s/mime.  This is one of the
reasons for Directory sync, it allows business partners to share directory
information.  That is why standards compliance is an issue here, and again,
active directory will require a metadirectory connector to many of the
directories already deployed.

Walt

> -----Original Message-----
> From: Dennis Glatting [mailto:[email-masked]]
> Sent: Thursday, May 11, 2000 10:36 AM
> To: Walter Williams
> Cc: Laurent Deffranne; ietf-smime
> Subject: Re: Does Slime works fine with Windows 2000 PKI
>
>
> Walter Williams wrote:
> >
> > Active directory would expose a significant amount of
> information you might
> > not want the external world to know, such as a complete listing
> of all your
> > w2k computers and their roles in your network.  You could use a
> LDAP proxy
> > server to provide what you want to the internet and keep the
> data in active
> > directory.  Innosoft (Now purchased by IPlanet) makes such a
> product.  There
> > are probably others on the market.
> >
>
> Question:
> 	Would it also disclose the name of all of the
> 	employees and their roles, something many
> 	outside recruiters would love to know?
>
>
> > > -----Original Message-----
> > > From: Laurent Deffranne [mailto:[email-masked]]
> > > Sent: Thursday, May 11, 2000 9:48 AM
> > > To: walter.williams
> > > Cc: ietf-smime
> > > Subject: RE: Does Smime works fine with Windows 2000 PKI
> > >
> > >
> > > What would happen if you want to open the directory to anonymous
> > > access to the Web ?
> > > In such a way that you could exchange S/MIME certs with
> outside people ?
> > >
> > >
> > >
> > >
> > >
> > >
> > > walter.williams%genuity.com@Internet
> > > 11/05/2000 15:35
> > > To:   Laurent Deffranne/GKBCCB@GKBCCB
> > > cc:   ietf-smime%imc.org@Internet
> > >
> > > Subject:      RE: Does Smime works fine with Windows 2000 PKI
> > >
> > > Let me take the points one at a time and inline:
> > >
> > > > -----Original Message-----
> > > > From: Laurent Deffranne [mailto:[email-masked]]
> > > > Sent: Thursday, May 11, 2000 9:19 AM
> > > > To: walter.williams
> > > > Cc: ietf-smime
> > > > Subject: RE: Does Smime works fine with Windows 2000 PKI
> > > >
> > > >
> > > > Walt,
> > > >
> > > > Do you mean that there are difficulties to access through LDAP an
> > > > Active Directory, as you want to read or use X509 certificates ?
> > > >
> > >
> > > No.  However, are you going to open your active directory to
> > > anonymous LDAP
> > > queries over the Internet?  If not, are you limiting S/MIME to
> > > internal use
> > > only?  If not then you are somewhat back to square one.
> > >
> > > > By the way,does somebody know issues about Active Directory LDAP,
> > > > or issues to read a certificate in an Active Directory ?
> > >
> > > This worked just fine for us here, but the problem we had
> with AD was that
> > > it does not support inetOrgPerson, and thus can't easily be
> > > synched up with
> > > most external LDAP directories.  You'll find you'll want a
> metadirectory
> > > connector to synch it with any external directory.  Again,
> this is not an
> > > issue if you're willing to directly expose AD to internet use.
> > > >
> > > > For me it would be a mistake to use now the "brand new" Active
> > > > Directory, but if someone could tell me where I can find proofs
> > > > of lack of compatibility (from Microsoft, there must be surely
> > > > one of two), this would interrest me.
> > > >
> > > AD seems to work just fine, if you don't mind working with
> > > something with a
> > > proprietary schema.  Any LDAP and S/MIME aware client we pointed at it
> > > understood the contents just fine, so the schema does not
> seem to impact
> > > client interoperability.
> > >
> > > > Laurent
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > walter.williams%genuity.com@Internet
> > > > 11/05/2000 14:54
> > > > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
> > > > cc:
> > > >
> > > > Subject:    RE: Does Smime works fine with Windows 2000 PKI
> > > >
> > > > Laurent;
> > > >
> > > > Yes, certs issued from a W2K CA can be used for S/MIME, and no
> > > > less so than
> > > > certs issued from Baltimore, Iplanet or any other CA vendor or
> > > > product.  The
> > > > main issue is not will they work, but will you be able to
> validate the
> > > > certs.  Unless the person issuing the cert from W2K has
> > > provided you with
> > > > their server's cert, or they have certified their CA with the
> > > signature of
> > > > the publicly known CAs you will not be able to easily verify
> > > the signature
> > > > to its source.  This is not the most technically acurate way of
> > > > saying this
> > > > but I'm not awake yet.  Baltimore has preregistered there
> CA with the
> > > > vendors distributing products, as has Verisign, Thaught, and
> > > many others.
> > > > Just make certain that you have the certificates for the W2K CA,
> > > > and access
> > > > to its revocation list so you can validate properly and
> you'll be fine.
> > > >
> > > > Walt Williams
> > > > TSD-Systems
> > > > Senior IT Analyst
> > > > Genuity
> > > > www.genuity.com
> > > >
> > > > Please note: GTE Internetworking is now Genuity.
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]]On Behalf Of
> Laurent Deffranne
> > > > > Sent: Thursday, May 11, 2000 5:45 AM
> > > > > To: ietf-smime
> > > > > Subject: Does Smime works fine with Windows 2000 PKI
> > > > >
> > > > >
> > > > > Hi everybody,
> > > > >
> > > > > Just a question :
> > > > >
> > > > > Is there any known issues using S/MIME with
> Win2000PKI-certificates ?
> > > > > More generally, are Win2000 certificates usable with (and
> > > > > understood by ) the others mailers (especially Lotus Notes,
> > > > > Netscape, Eudora +plug-in?)
> > > > >
> > > > > Isn't Baltimore Unicert a "better choice" due to its greater
> > > > > compatibility ?
> > > > >
> > > > > Any advices are welcome.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Laurent Deffranne
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
>
>
> --
> Dennis Glatting
> Copyright (c) 2000 Software Munitions
>

Date: Thu, 11 May 2000 07:35:42 -0700
From: Dennis Glatting <[email-masked]>
To: Walter Williams <[email-masked]>
CC: Laurent Deffranne <[email-masked]>, ietf-smime <[email-masked]>
Subject: Re: Does Slime works fine with Windows 2000 PKI
Sender: [email-masked]

Walter Williams wrote:
> 
> Active directory would expose a significant amount of information you might
> not want the external world to know, such as a complete listing of all your
> w2k computers and their roles in your network.  You could use a LDAP proxy
> server to provide what you want to the internet and keep the data in active
> directory.  Innosoft (Now purchased by IPlanet) makes such a product.  There
> are probably others on the market.
> 

Question:
	Would it also disclose the name of all of the
	employees and their roles, something many
	outside recruiters would love to know?

> > -----Original Message-----
> > From: Laurent Deffranne [mailto:[email-masked]]
> > Sent: Thursday, May 11, 2000 9:48 AM
> > To: walter.williams
> > Cc: ietf-smime
> > Subject: RE: Does Smime works fine with Windows 2000 PKI
> >
> >
> > What would happen if you want to open the directory to anonymous
> > access to the Web ?
> > In such a way that you could exchange S/MIME certs with outside people ?
> >
> >
> >
> >
> >
> >
> > walter.williams%genuity.com@Internet
> > 11/05/2000 15:35
> > To:   Laurent Deffranne/GKBCCB@GKBCCB
> > cc:   ietf-smime%imc.org@Internet
> >
> > Subject:      RE: Does Smime works fine with Windows 2000 PKI
> >
> > Let me take the points one at a time and inline:
> >
> > > -----Original Message-----
> > > From: Laurent Deffranne [mailto:[email-masked]]
> > > Sent: Thursday, May 11, 2000 9:19 AM
> > > To: walter.williams
> > > Cc: ietf-smime
> > > Subject: RE: Does Smime works fine with Windows 2000 PKI
> > >
> > >
> > > Walt,
> > >
> > > Do you mean that there are difficulties to access through LDAP an
> > > Active Directory, as you want to read or use X509 certificates ?
> > >
> >
> > No.  However, are you going to open your active directory to
> > anonymous LDAP
> > queries over the Internet?  If not, are you limiting S/MIME to
> > internal use
> > only?  If not then you are somewhat back to square one.
> >
> > > By the way,does somebody know issues about Active Directory LDAP,
> > > or issues to read a certificate in an Active Directory ?
> >
> > This worked just fine for us here, but the problem we had with AD was that
> > it does not support inetOrgPerson, and thus can't easily be
> > synched up with
> > most external LDAP directories.  You'll find you'll want a metadirectory
> > connector to synch it with any external directory.  Again, this is not an
> > issue if you're willing to directly expose AD to internet use.
> > >
> > > For me it would be a mistake to use now the "brand new" Active
> > > Directory, but if someone could tell me where I can find proofs
> > > of lack of compatibility (from Microsoft, there must be surely
> > > one of two), this would interrest me.
> > >
> > AD seems to work just fine, if you don't mind working with
> > something with a
> > proprietary schema.  Any LDAP and S/MIME aware client we pointed at it
> > understood the contents just fine, so the schema does not seem to impact
> > client interoperability.
> >
> > > Laurent
> > >
> > >
> > >
> > >
> > >
> > > walter.williams%genuity.com@Internet
> > > 11/05/2000 14:54
> > > To: Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
> > > cc:
> > >
> > > Subject:    RE: Does Smime works fine with Windows 2000 PKI
> > >
> > > Laurent;
> > >
> > > Yes, certs issued from a W2K CA can be used for S/MIME, and no
> > > less so than
> > > certs issued from Baltimore, Iplanet or any other CA vendor or
> > > product.  The
> > > main issue is not will they work, but will you be able to validate the
> > > certs.  Unless the person issuing the cert from W2K has
> > provided you with
> > > their server's cert, or they have certified their CA with the
> > signature of
> > > the publicly known CAs you will not be able to easily verify
> > the signature
> > > to its source.  This is not the most technically acurate way of
> > > saying this
> > > but I'm not awake yet.  Baltimore has preregistered there CA with the
> > > vendors distributing products, as has Verisign, Thaught, and
> > many others.
> > > Just make certain that you have the certificates for the W2K CA,
> > > and access
> > > to its revocation list so you can validate properly and you'll be fine.
> > >
> > > Walt Williams
> > > TSD-Systems
> > > Senior IT Analyst
> > > Genuity
> > > www.genuity.com
> > >
> > > Please note: GTE Internetworking is now Genuity.
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]]On Behalf Of Laurent Deffranne
> > > > Sent: Thursday, May 11, 2000 5:45 AM
> > > > To: ietf-smime
> > > > Subject: Does Smime works fine with Windows 2000 PKI
> > > >
> > > >
> > > > Hi everybody,
> > > >
> > > > Just a question :
> > > >
> > > > Is there any known issues using S/MIME with Win2000PKI-certificates ?
> > > > More generally, are Win2000 certificates usable with (and
> > > > understood by ) the others mailers (especially Lotus Notes,
> > > > Netscape, Eudora +plug-in?)
> > > >
> > > > Isn't Baltimore Unicert a "better choice" due to its greater
> > > > compatibility ?
> > > >
> > > > Any advices are welcome.
> > > >
> > > > Regards,
> > > >
> > > > Laurent Deffranne
> > >
> > >
> > >
> > >
> >
> >
> >

-- 
Dennis Glatting
Copyright (c) 2000 Software Munitions

From: "Walter Williams" <[email-masked]>
To: "Laurent Deffranne" <[email-masked]>
Cc: "ietf-smime" <[email-masked]>
Subject: RE: Does Slime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 09:57:09 -0400
Importance: Normal
Sender: [email-masked]

Active directory would expose a significant amount of information you might
not want the external world to know, such as a complete listing of all your
w2k computers and their roles in your network.  You could use a LDAP proxy
server to provide what you want to the internet and keep the data in active
directory.  Innosoft (Now purchased by IPlanet) makes such a product.  There
are probably others on the market.

> -----Original Message-----
> From: Laurent Deffranne [mailto:[email-masked]]
> Sent: Thursday, May 11, 2000 9:48 AM
> To: walter.williams
> Cc: ietf-smime
> Subject: RE: Does Smime works fine with Windows 2000 PKI
>
>
> What would happen if you want to open the directory to anonymous
> access to the Web ?
> In such a way that you could exchange S/MIME certs with outside people ?
>
>
>
>
>
>
> walter.williams%genuity.com@Internet
> 11/05/2000 15:35
> To:	Laurent Deffranne/GKBCCB@GKBCCB
> cc:	ietf-smime%imc.org@Internet
>
> Subject:	RE: Does Smime works fine with Windows 2000 PKI
>
> Let me take the points one at a time and inline:
>
> > -----Original Message-----
> > From: Laurent Deffranne [mailto:[email-masked]]
> > Sent: Thursday, May 11, 2000 9:19 AM
> > To: walter.williams
> > Cc: ietf-smime
> > Subject: RE: Does Smime works fine with Windows 2000 PKI
> >
> >
> > Walt,
> >
> > Do you mean that there are difficulties to access through LDAP an
> > Active Directory, as you want to read or use X509 certificates ?
> >
>
> No.  However, are you going to open your active directory to
> anonymous LDAP
> queries over the Internet?  If not, are you limiting S/MIME to
> internal use
> only?  If not then you are somewhat back to square one.
>
> > By the way,does somebody know issues about Active Directory LDAP,
> > or issues to read a certificate in an Active Directory ?
>
> This worked just fine for us here, but the problem we had with AD was that
> it does not support inetOrgPerson, and thus can't easily be
> synched up with
> most external LDAP directories.  You'll find you'll want a metadirectory
> connector to synch it with any external directory.  Again, this is not an
> issue if you're willing to directly expose AD to internet use.
> >
> > For me it would be a mistake to use now the "brand new" Active
> > Directory, but if someone could tell me where I can find proofs
> > of lack of compatibility (from Microsoft, there must be surely
> > one of two), this would interrest me.
> >
> AD seems to work just fine, if you don't mind working with
> something with a
> proprietary schema.  Any LDAP and S/MIME aware client we pointed at it
> understood the contents just fine, so the schema does not seem to impact
> client interoperability.
>
> > Laurent
> >
> >
> >
> >
> >
> > walter.williams%genuity.com@Internet
> > 11/05/2000 14:54
> > To:	Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
> > cc:
> >
> > Subject:	RE: Does Smime works fine with Windows 2000 PKI
> >
> > Laurent;
> >
> > Yes, certs issued from a W2K CA can be used for S/MIME, and no
> > less so than
> > certs issued from Baltimore, Iplanet or any other CA vendor or
> > product.  The
> > main issue is not will they work, but will you be able to validate the
> > certs.  Unless the person issuing the cert from W2K has
> provided you with
> > their server's cert, or they have certified their CA with the
> signature of
> > the publicly known CAs you will not be able to easily verify
> the signature
> > to its source.  This is not the most technically acurate way of
> > saying this
> > but I'm not awake yet.  Baltimore has preregistered there CA with the
> > vendors distributing products, as has Verisign, Thaught, and
> many others.
> > Just make certain that you have the certificates for the W2K CA,
> > and access
> > to its revocation list so you can validate properly and you'll be fine.
> >
> > Walt Williams
> > TSD-Systems
> > Senior IT Analyst
> > Genuity
> > www.genuity.com
> >
> > Please note: GTE Internetworking is now Genuity.
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of Laurent Deffranne
> > > Sent: Thursday, May 11, 2000 5:45 AM
> > > To: ietf-smime
> > > Subject: Does Smime works fine with Windows 2000 PKI
> > >
> > >
> > > Hi everybody,
> > >
> > > Just a question :
> > >
> > > Is there any known issues using S/MIME with Win2000PKI-certificates ?
> > > More generally, are Win2000 certificates usable with (and
> > > understood by ) the others mailers (especially Lotus Notes,
> > > Netscape, Eudora +plug-in?)
> > >
> > > Isn't Baltimore Unicert a "better choice" due to its greater
> > > compatibility ?
> > >
> > > Any advices are welcome.
> > >
> > > Regards,
> > >
> > > Laurent Deffranne
> >
> >
> >
> >
>
>
>

Date: 11 May 2000 15:48:21 +0200
From: Laurent Deffranne <[email-masked]>
To: "walter.williams" <[email-masked]>
cc: ietf-smime <[email-masked]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Sender: [email-masked]

What would happen if you want to open the directory to anonymous access to the Web ?
In such a way that you could exchange S/MIME certs with outside people ?

walter.williams%genuity.com@Internet
11/05/2000 15:35
To:	Laurent Deffranne/GKBCCB@GKBCCB
cc:	ietf-smime%imc.org@Internet 

Subject:	RE: Does Smime works fine with Windows 2000 PKI

Let me take the points one at a time and inline:

> -----Original Message-----
> From: Laurent Deffranne [mailto:[email-masked]]
> Sent: Thursday, May 11, 2000 9:19 AM
> To: walter.williams
> Cc: ietf-smime
> Subject: RE: Does Smime works fine with Windows 2000 PKI
>
>
> Walt,
>
> Do you mean that there are difficulties to access through LDAP an
> Active Directory, as you want to read or use X509 certificates ?
>

No.  However, are you going to open your active directory to anonymous LDAP
queries over the Internet?  If not, are you limiting S/MIME to internal use
only?  If not then you are somewhat back to square one.

> By the way,does somebody know issues about Active Directory LDAP,
> or issues to read a certificate in an Active Directory ?

This worked just fine for us here, but the problem we had with AD was that
it does not support inetOrgPerson, and thus can't easily be synched up with
most external LDAP directories.  You'll find you'll want a metadirectory
connector to synch it with any external directory.  Again, this is not an
issue if you're willing to directly expose AD to internet use.
>
> For me it would be a mistake to use now the "brand new" Active
> Directory, but if someone could tell me where I can find proofs
> of lack of compatibility (from Microsoft, there must be surely
> one of two), this would interrest me.
>
AD seems to work just fine, if you don't mind working with something with a
proprietary schema.  Any LDAP and S/MIME aware client we pointed at it
understood the contents just fine, so the schema does not seem to impact
client interoperability.

> Laurent
>
>
>
>
>
> walter.williams%genuity.com@Internet
> 11/05/2000 14:54
> To:	Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
> cc:
>
> Subject:	RE: Does Smime works fine with Windows 2000 PKI
>
> Laurent;
>
> Yes, certs issued from a W2K CA can be used for S/MIME, and no
> less so than
> certs issued from Baltimore, Iplanet or any other CA vendor or
> product.  The
> main issue is not will they work, but will you be able to validate the
> certs.  Unless the person issuing the cert from W2K has provided you with
> their server's cert, or they have certified their CA with the signature of
> the publicly known CAs you will not be able to easily verify the signature
> to its source.  This is not the most technically acurate way of
> saying this
> but I'm not awake yet.  Baltimore has preregistered there CA with the
> vendors distributing products, as has Verisign, Thaught, and many others.
> Just make certain that you have the certificates for the W2K CA,
> and access
> to its revocation list so you can validate properly and you'll be fine.
>
> Walt Williams
> TSD-Systems
> Senior IT Analyst
> Genuity
> www.genuity.com
>
> Please note: GTE Internetworking is now Genuity.
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Laurent Deffranne
> > Sent: Thursday, May 11, 2000 5:45 AM
> > To: ietf-smime
> > Subject: Does Smime works fine with Windows 2000 PKI
> >
> >
> > Hi everybody,
> >
> > Just a question :
> >
> > Is there any known issues using S/MIME with Win2000PKI-certificates ?
> > More generally, are Win2000 certificates usable with (and
> > understood by ) the others mailers (especially Lotus Notes,
> > Netscape, Eudora +plug-in?)
> >
> > Isn't Baltimore Unicert a "better choice" due to its greater
> > compatibility ?
> >
> > Any advices are welcome.
> >
> > Regards,
> >
> > Laurent Deffranne
>
>
>
>

From: "Walter Williams" <[email-masked]>
To: "Laurent Deffranne" <[email-masked]>
Cc: "ietf-smime" <[email-masked]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 09:26:44 -0400
Importance: Normal
Sender: [email-masked]

Let me take the points one at a time and inline:

> -----Original Message-----
> From: Laurent Deffranne [mailto:[email-masked]]
> Sent: Thursday, May 11, 2000 9:19 AM
> To: walter.williams
> Cc: ietf-smime
> Subject: RE: Does Smime works fine with Windows 2000 PKI
>
>
> Walt,
>
> Do you mean that there are difficulties to access through LDAP an
> Active Directory, as you want to read or use X509 certificates ?
>

No.  However, are you going to open your active directory to anonymous LDAP
queries over the Internet?  If not, are you limiting S/MIME to internal use
only?  If not then you are somewhat back to square one.

> By the way,does somebody know issues about Active Directory LDAP,
> or issues to read a certificate in an Active Directory ?

This worked just fine for us here, but the problem we had with AD was that
it does not support inetOrgPerson, and thus can't easily be synched up with
most external LDAP directories.  You'll find you'll want a metadirectory
connector to synch it with any external directory.  Again, this is not an
issue if you're willing to directly expose AD to internet use.
>
> For me it would be a mistake to use now the "brand new" Active
> Directory, but if someone could tell me where I can find proofs
> of lack of compatibility (from Microsoft, there must be surely
> one of two), this would interrest me.
>
AD seems to work just fine, if you don't mind working with something with a
proprietary schema.  Any LDAP and S/MIME aware client we pointed at it
understood the contents just fine, so the schema does not seem to impact
client interoperability.

> Laurent
>
>
>
>
>
> walter.williams%genuity.com@Internet
> 11/05/2000 14:54
> To:	Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
> cc:
>
> Subject:	RE: Does Smime works fine with Windows 2000 PKI
>
> Laurent;
>
> Yes, certs issued from a W2K CA can be used for S/MIME, and no
> less so than
> certs issued from Baltimore, Iplanet or any other CA vendor or
> product.  The
> main issue is not will they work, but will you be able to validate the
> certs.  Unless the person issuing the cert from W2K has provided you with
> their server's cert, or they have certified their CA with the signature of
> the publicly known CAs you will not be able to easily verify the signature
> to its source.  This is not the most technically acurate way of
> saying this
> but I'm not awake yet.  Baltimore has preregistered there CA with the
> vendors distributing products, as has Verisign, Thaught, and many others.
> Just make certain that you have the certificates for the W2K CA,
> and access
> to its revocation list so you can validate properly and you'll be fine.
>
> Walt Williams
> TSD-Systems
> Senior IT Analyst
> Genuity
> www.genuity.com
>
> Please note: GTE Internetworking is now Genuity.
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Laurent Deffranne
> > Sent: Thursday, May 11, 2000 5:45 AM
> > To: ietf-smime
> > Subject: Does Smime works fine with Windows 2000 PKI
> >
> >
> > Hi everybody,
> >
> > Just a question :
> >
> > Is there any known issues using S/MIME with Win2000PKI-certificates ?
> > More generally, are Win2000 certificates usable with (and
> > understood by ) the others mailers (especially Lotus Notes,
> > Netscape, Eudora +plug-in?)
> >
> > Isn't Baltimore Unicert a "better choice" due to its greater
> > compatibility ?
> >
> > Any advices are welcome.
> >
> > Regards,
> >
> > Laurent Deffranne
>
>
>
>

Date: 11 May 2000 15:19:05 +0200
From: Laurent Deffranne <[email-masked]>
To: "walter.williams" <[email-masked]>
cc: ietf-smime <[email-masked]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Sender: [email-masked]

--PART.BOUNDARY.spdl113.58e8.391ab34c.0001
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: Quoted-Printable
Content-Disposition: inline

Walt,

Do you mean that there are difficulties to access through LDAP an Active Di=
rectory, as you want to read or use X509 certificates ?

By the way,does somebody know issues about Active Directory LDAP, or issues=
 to read a certificate in an Active Directory ?

For me it would be a mistake to use now the "brand new" Active Directory, b=
ut if someone could tell me where I can find proofs of lack of compatibilit=
y (from Microsoft, there must be surely one of two), this would interrest m=
e.=20

Laurent

walter.williams%genuity.com@Internet
11/05/2000 14:54
To:=09Laurent Deffranne/GKBCCB@GKBCCB, ietf-smime%imc.org@Internet
cc:=09=20

Subject:=09RE: Does Smime works fine with Windows 2000 PKI

Laurent;

Yes, certs issued from a W2K CA can be used for S/MIME, and no less so than=

certs issued from Baltimore, Iplanet or any other CA vendor or product.  Th=
e
main issue is not will they work, but will you be able to validate the
certs.  Unless the person issuing the cert from W2K has provided you with
their server's cert, or they have certified their CA with the signature of
the publicly known CAs you will not be able to easily verify the signature
to its source.  This is not the most technically acurate way of saying this=

but I'm not awake yet.  Baltimore has preregistered there CA with the
vendors distributing products, as has Verisign, Thaught, and many others.
Just make certain that you have the certificates for the W2K CA, and access=

to its revocation list so you can validate properly and you'll be fine.

Walt Williams
TSD-Systems
Senior IT Analyst
Genuity
www.genuity.com

Please note: GTE Internetworking is now Genuity.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Laurent Deffranne
> Sent: Thursday, May 11, 2000 5:45 AM
> To: ietf-smime
> Subject: Does Smime works fine with Windows 2000 PKI
>
>
> Hi everybody,
>
> Just a question :
>
> Is there any known issues using S/MIME with Win2000PKI-certificates ?
> More generally, are Win2000 certificates usable with (and
> understood by ) the others mailers (especially Lotus Notes,
> Netscape, Eudora +plug-in?)
>
> Isn't Baltimore Unicert a "better choice" due to its greater
> compatibility ?
>
> Any advices are welcome.
>
> Regards,
>
> Laurent Deffranne

--PART.BOUNDARY.spdl113.58e8.391ab34c.0001
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="Walter B Williams.vcf"
Content-Description: Walter B Williams.vcf
FTBP-Modification-Date: 11 May 2000 15:19:00 +0200
FTBP-Object-Size: 470

BEGIN:VCARD
VERSION:2.1
N:Williams;Walter;B;Mr.
FN:Walter B Williams
NICKNAME:Walt
ORG:Genuity Inc.;TSD
TITLE:Senior IT Analyst
TEL;WORK;VOICE:617-873-5888
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;2/221B;50 Moulton St=0D=0AMS 2/2A;Cambridge;MA;02138;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:2/221B=0D=0A50 Moulton St=0D=0AMS 2/2A=0D=0ACambridge, MA 02138=0D=0AUSA
URL:
URL:http://www.genuity.com
EMAIL;PREF;INTERNET:[email-masked]
REV:20000407T003737Z
END:VCARD

--PART.BOUNDARY.spdl113.58e8.391ab34c.0001--

From: "Walter Williams" <[email-masked]>
To: "Laurent Deffranne" <[email-masked]>, "ietf-smime" <[email-masked]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 08:44:32 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01BFBB25.20A8F130
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Laurent;

Yes, certs issued from a W2K CA can be used for S/MIME, and no less so than
certs issued from Baltimore, Iplanet or any other CA vendor or product.  The
main issue is not will they work, but will you be able to validate the
certs.  Unless the person issuing the cert from W2K has provided you with
their server's cert, or they have certified their CA with the signature of
the publicly known CAs you will not be able to easily verify the signature
to its source.  This is not the most technically acurate way of saying this
but I'm not awake yet.  Baltimore has preregistered there CA with the
vendors distributing products, as has Verisign, Thaught, and many others.
Just make certain that you have the certificates for the W2K CA, and access
to its revocation list so you can validate properly and you'll be fine.

Walt Williams
TSD-Systems
Senior IT Analyst
Genuity
www.genuity.com

Please note: GTE Internetworking is now Genuity.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Laurent Deffranne
> Sent: Thursday, May 11, 2000 5:45 AM
> To: ietf-smime
> Subject: Does Smime works fine with Windows 2000 PKI
>
>
> Hi everybody,
>
> Just a question :
>
> Is there any known issues using S/MIME with Win2000PKI-certificates ?
> More generally, are Win2000 certificates usable with (and
> understood by ) the others mailers (especially Lotus Notes,
> Netscape, Eudora +plug-in?)
>
> Isn't Baltimore Unicert a "better choice" due to its greater
> compatibility ?
>
> Any advices are welcome.
>
> Regards,
>
> Laurent Deffranne

------=_NextPart_000_0000_01BFBB25.20A8F130
Content-Type: text/x-vcard;
	name="Walter B Williams.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Walter B Williams.vcf"

BEGIN:VCARD
VERSION:2.1
N:Williams;Walter;B;Mr.
FN:Walter B Williams
NICKNAME:Walt
ORG:Genuity Inc.;TSD
TITLE:Senior IT Analyst
TEL;WORK;VOICE:617-873-5888
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;2/221B;50 Moulton St=3D0D=3D0AMS =
2/2A;Cambridge;MA;02138;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:2/221B=3D0D=3D0A50 Moulton =
St=3D0D=3D0AMS 2/2A=3D0D=3D0ACambridge, MA 02138=3D0D=3D0AUSA
URL:
URL:http://www.genuity.com
EMAIL;PREF;INTERNET:[email-masked]
REV:20000407T003737Z
END:VCARD

------=_NextPart_000_0000_01BFBB25.20A8F130--

Date: 11 May 2000 11:44:37 +0200
From: Laurent Deffranne <[email-masked]>
To: ietf-smime <[email-masked]>
Subject: Does Smime works fine with Windows 2000 PKI
Sender: [email-masked]

Hi everybody,

Just a question :

Is there any known issues using S/MIME with Win2000PKI-certificates ?
More generally, are Win2000 certificates usable with (and understood by ) the others mailers (especially Lotus Notes, Netscape, Eudora +plug-in?)

Isn't Baltimore Unicert a "better choice" due to its greater compatibility ?

Any advices are welcome.

Regards,

Laurent Deffranne

From: "Charlie Fletcher - www.ukdata.com" <[email-masked]>
To: "Finance Director" <[email-masked]>
Subject: Instant On-Line Credit Reports
Date: Tue, 9 May 2000 16:34:00 +0100
Sender: [email-masked]

Do you need fast accurate information to assist you when appraising
potential customers, and suppliers?

The UK Data internet website www.ukdata.com contains 28 million pages of
data with full information on every UK company!

Credit Reports-Director Searches-Accounts-Annual Returns

All of these products and many more are available to you immediately, and
can be downloaded to and printed from your personal computer.

Free samples of all reports are available at www.ukdata.com.

Please also visit www.formacompany.co.uk the on-line company formation
website

Thank You

Charles Fletcher
www.ukdata.com an instant report on every UK business
www.formacompany.co.uk the on-line company formation site
www.irishdata.ie - instant reports on all Irish companies

From: Raviv Karnieli<[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: S/MIME IDEA Draft
Date: Tue, 09 MAY 2000 16:44:00 -0000 
Sender: [email-masked]

This is a multi-part message in MIME format.

--<<-- MailGuardian RTF boundary -->>
Content-Type: text/plain; charset="ISO-8859-8"
Content-Transfer-Encoding: base64

--<<-- MailGuardian RTF boundary -->>
Content-Type: application/X-MAILguardian-rtf; charset="ISO-8859-8"
Content-Transfer-Encoding: base64

DQp7XHJ0ZjFcYW5zaVxhbnNpY3Bn

--<<-- MailGuardian RTF boundary -->>--

Date: Tue, 9 May 2000 09:06:12 -0400 (EDT)
From: "David M. Balenson" <[email-masked]>
To: [email-masked]
Subject: CFP: ISOC Netw & Distr Sys Security Symp (NDSS'01)
Sender: [email-masked]

            C  A  L  L       F  O  R       P  A  P  E  R  S

                          The Internet Society
         2001 Network and Distributed System Security Symposium
                               (NDSS'01)

                           February 7-9, 2001

                Catamaran Resort, San Diego, California

                            IMPORTANT DATES
          Paper Submission due:           August 2, 2000
          Author Notification:            September 27, 2000
          Camera-ready final papers due:  October 31, 2000

GOAL: 
  This symposium will foster information exchange among researchers 
  and practioners of network and distributed system security 
  services.  The intended audience includes those who are interested 
  in the practical aspects of network and distributed system security,
  focusing on actual system design and implementation, rather than
  theory.  A major goal of the symposium is to encourage and enable 
  the Internet community to apply, deploy, and advance the state of
  available security technology.  The proceedings of the symposium 
  will be published by the Internet Society.

Submissions are solicited for, but are not limited to, the following
topics:
 * Secure Electronic Commerce: e.g., payment, barter, EDI,
   notarization/timestamping, endorsement and licensing.
 * Intellectual Property Protection: protocols, schemas,
   implementations, metering, watermarking, other forms of rights
   management.
 * Implementation, deployment and management of network security
   policies.
 * Integrating Security in Internet protocols: routing, naming,
   TCP/IP, multicast, network management, and the Web.
 * Attack-resistant protocols and services.
 * Special problems and case studies: e.g., interplay and tradeoffs
   between security and efficiency, usability, reliability and cost.
 * Security for collaborative applications and services: tele- and
   video-conferencing, groupwork, etc.
 * Fundamental services: authentication, data integrity,
   confidentiality, authorization, non-repudiation, and availability.
 * Supporting mechanisms and APIs: key management and certification,
   revocation, audit trails and accountability.
 * Public Key Infrastructure.
 * Integrating security services with system and application security
   facilities and protocols: e.g., message handling, file
   transport/access, directories, time synchronization, database
   management, boot services, mobile computing.
 * Security for emerging technologies: sensor networks, specialized
   testbeds, wireless/mobile (and ad hoc) networks, personal
   communication systems, and large heterogeneous distributed systems.
 * Intrusion Avoidance, Detection, and Response: systems, experiences
   and architectures.
 * Network Perimeter Controls: firewalls, packet filters, application
   gateways.
 * Virtual Private Networks.

BEST PAPER AWARD:
  There will be a best paper award again this year. The award will
  be presented at the symposium to the authors of the best overall
  paper as selected by the Program Committee.

SUBMISSIONS:
  The Program Committee invites both technical papers and panel
  proposals. Technical papers should be at most 20 pages long. Panel
  proposals should be at most two pages and should describe the
  topic, identify the panel chair, explain the format of the panel,
  and list three to four potential panelists. Technical papers will
  appear in the proceedings. A description of each panel will appear
  in the proceedings, and may - at the discretion of the panel chair
  - include written position statements from the panelists.

  Each submission must contain a separate title page with the type
  of submission (paper or panel), the title or topic, the names of
  the author(s), organizational affiliation(s), telephone and FAX
  numbers, postal addresses, e-mail addresses, and must specify the
  contact author in case of multi-author submissions. The names of
  authors, affiliations, and other identifying information should
  appear only on the separate title page. Submissions must be
  received by August 2, 2000, and must be made via electronically
  in either PostScript or ASCII format. If the Committee is unable
  to print a PostScript submission, a hardcopy will be requested.
  Therefore, PostScript submissions must arrive well before the
  deadline.

  Submission information can be found at
  http://www.isoc.org/ndss01/cfp. Dates, final call for papers,
  advance program, and registration information will be available
  soon at http://www.isoc.org/ndss01.

  Each submission will be acknowledged by e-mail. If acknowledgment
  is not received within seven days, please contact the program
  Co-chairs as indicated below. Authors and panelists will be
  notified of acceptance by September 27, 2000. Instructions for
  preparing camera-ready copy for the proceedings will be sent at
  that time. The camera-ready copy must be received by October 31,
  2000.

GENERAL CHAIR: 
  Stephen Welke, Trusted Computer Solutions

PROGRAM CO-CHAIRS:
  Avi Rubin, AT&T Labs - Research
  Paul Van Oorschot, Entrust Technologies

TUTORIAL CHAIR:
  Eric Harder, National Security Agency

LOCAL ARRANGEMENTS CHAIR:
  Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
  Mahesh Tripunitara, Purdue University

PUBLICITY CHAIR:
  David Balenson, NAI Labs, Network Associates

LOGISTICS CHAIR:
  Carla Rosenfeld, Internet Society

PROGRAM COMMITTEE:
  Bennet Yee, University of California San Diego
  Bill Cheswick, Bell Labs
  Dave Kormann, AT&T Labs - Research
  David Aucksmith, Intel Corportation
  David P. Maher, Intertrust
  David Wagner, UC Berkeley
  Edward W. Felten, Princeton University
  Fabian Monrose, Bell Labs
  Gary McGraw, Reliable Software Technologies
  James Ellis, Sun Microsystems
  Kevin McCurley, IBM Almaden Research Center
  Matt Bishop, UC Davis
  Mudge, L0pht Heavy Industries, Inc.
  Peter Gutmann, University of Auckland, New Zealand
  Radia Perlman, Sun Microsystems
  Sandra Murphy, Network Associates
  Tom Berson, Anagram Laboratories
  Virgil D. Gligor, University of Maryland

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cmskea-05.txt
Date: Tue, 09 May 2000 06:36:40 -0400
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		: Use of the KEA and SKIPJACK Algorithms in CMS	 
        Author(s)	: J. Pawling
	Filename	: draft-ietf-smime-cmskea-05.txt
	Pages		: 10
	Date		: 08-May-00
	
This document describes the conventions for using the Key Exchange 
Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data 
content types.
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-cmskea-05.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-cmskea-05.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-cmskea-05.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-cmskea-05.txt

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

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

--OtherAccess--

--NextPart--

From: "Pawling, John" <[email-masked]>
To: "SMIME WG (E-mail)" <[email-masked]>
Subject: Final 29 March 2000 S/MIME WG Minutes
Date: Mon, 8 May 2000 16:51:27 -0400 
Sender: [email-masked]

This message includes the minutes of the IETF S/MIME Working Group
meeting held on 29 March 2000 in Adelaide, Australia.  All briefing
slides will be stored at: ftp://ftp.ietf.org/ietf/smime/.  These
minutes include comments from the briefing presenters.  
Reported by John Pawling.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Introductions - Russ Housley
 
Russ reviewed the agenda as follows.  Nobody objected to the agenda.

Introductions				Russ Housley
Working Group Status			Russ Housley
Security Policies and Labels		Russ Housley
CERTDIST Draft Discussion 		Jim Schaad
Symmetric Key Distribution		Sean Turner
DOMSEC Draft Discussion 		Bill Ottaway
Interoperability Matrix 		Jim Schaad
CMS/ESS Examples				Paul Hoffman
Crypto Algorithm Documents		Russ Housley
E-mail Addresses & Certificates	Greg Colla
S/MIME Freeware Library			John Pawling
Electronic Signature Formats		John Ross
Wrap up					Russ Housley

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

S/MIME Working Group Status - Russ Housley

Russ outlined the strategy for advancing the following RFCs from
Internet Proposed Standards to Internet Draft Standards:
RFC 2630  Cryptographic Message Syntax, R. Housley, June 1999
RFC 2631  Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999
RFC 2632  S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999
RFC 2633  S/MIME Version 3 Message Specification, B. Ramsdell, June 1999
RFC 2634  Enhanced Security Services for S/MIME, P. Hoffman, June 1999
RFC 2785  Methods for Avoiding the "Small-Subgroup" Attacks on the
          Diffie-Hellman Key Agreement Method for S/MIME. 
          R. Zuccherato.  March 2000. [Informational]

The aforementioned documents must meet the following requirements to
become Draft Standards:
1) Meet requirements documented in RFC 2026
2) Stable, mature, and useful specification
3) At least two independent and interoperable implementations
   from different code bases
4) Draft Standards cannot reference Proposed Standard RFCs or 
   Experimental RFCs, so the aforementioned RFCs are blocked
   until the PKIX Certificate and CRL Profile "Son-of-RFC 2459"
   Internet-Draft (I-D) (draft-ietf-pkix-new-part1-01.txt) 
   progresses to Draft Standard.
 
Russ stated that Jim Schaad has developed an interoperability matrix
for RFCs 2630 through 2634.  Once completed, the matrix will 
indicate which features have and have not been implemented.  So far,
Microsoft and J.G. Van Dyke and Associates (VDA) have provided input
to the interoperability matrix.  Russ asked that other organizations
that have developed S/MIME v3 capabilities should contribute to the
matrix.     

Russ stated that testing of the example data included in the 
"Examples of S/MIME Messages" I-D is providing informal inputs for
the matrix.  Paul Hoffman stated that that other code bases also 
need to be tested.  He welcomed feedback from novice developers.  
He has offered to coordinate interoperability testing.  In the past,
Paul has coordinated face-to-face SecureConnect interoperability
events.  He believes that future interoperability testing will not
be face-to-face, but will be supported via a bulletin board or e-mail.
He will announce any S/MIME inter events on the S/MIME WG mail list.
Those events will be discussed in detail on the S/MIME developers 
mail list <[email-masked]>

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Mapping Company Classification Policy to the S/MIME Security Label
- Russ Housley

The "Implementing Company Classification Policy with the S/MIME 
Security Label" I-D, <draft-ietf-smime-seclabel-00.txt>, December 
1999, was authored by Weston Nicolls.  It is planned that the document
will become an Informational RFC.  It describes how the ESS Security
Label can be used to implement an organizational security policy.  
It includes three organizational examples: Whirlpool, Caterpillar 
and Amoco.  One use of this document is to provide sample policies
for interoperability testing.

The document includes the security policy for Amoco Corporation
as follows: 
  - Confidentiality: General, Confidential, Highly Confidential
  - Integrity: Minimum, Medium, Maximum

It includes the security policy for Caterpillar Inc as follows: 
  - Confidentiality: Public, Confidential Green, 
        Confidential Yellow, Confidential Red

It includes the security policy for Whirlpool Corporation 
as follows: 
  - Confidentiality: Public, Internal, Confidential
  - Additional marks at discretion of owner:
    - Privacy Marks?  
    - Security Categories?
    - Do they require access control?

Way Forward:
- Support interoperability testing
- Need to assign Object Identifiers: IETF values for this document
    and testing
- Organizations assign their own

After discussion with Weston Nicolls, who could not be present at 
this meeting, three object identifiers were assigned to permit the
Whirlpool, Caterpillar and Amoco security policies to be used in 
interoperability testing.  These object identifiers are not the 
ones that will be used by the companies, rather they are 
intended for testing.  The object identifiers are:

 -- S/MIME Working Group Object Identifier Registry
    id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 
             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

 -- Test Security Policies Arc
    id-tsp  OBJECT IDENTIFIER ::= { id-smime 7 }

 -- Test Security Policies
    id-tsp-TEST-Amoco          OBJECT IDENTIFIER ::= { id-tsp 1 }
    id-tsp-TEST-Caterpillar    OBJECT IDENTIFIER ::= { id-tsp 2 }
    id-tsp-TEST-Whirlpool      OBJECT IDENTIFIER ::= { id-tsp 3 } 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CERTDIST Draft Discussion - Jim Schaad

Jim discussed the Certificate Distribution Specification I-D 
<draft-ietf-smime-certdist-04.txt>, October 20, 1999.  The CERTDIST
I-D was submitted for S/MIME WG "last call" for comments on 22 October
1999.  Jim stated that he received comments regarding the following
topics:
- LDAP Directory Attribute layout
- Additional arguments against CERTDIST Section 2 (current methods
  of publishing certificates)
- miscellaneous minor comments

Jims stated that he plans to publish an updated version of the
CERTDIST I-D soon.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Symmetric Key Distribution - Sean Turner

Sean discussed the S/MIME Symmetric Key Distribution I-D, 
<draft-ietf-smime-symkeydist-00.txt>, December 20, 1999.  He stated
that the design goals are to provide a transport independent
mechanism for distribution of symmetric keys to a group of users.
The mechanism must use RFC 2630.  It must maximize the reuse of
existing group/list management techniques (listserv, majordomo, etc).
Seam explained the diagrams included in the I-D.  

Sean stated that he did not know of any patents regarding the secure
distribution of symmetric keys.  He asked if anybody else knew of
any patents.  Nobody replied.

Paul Hoffman pointed out that the majordomo mail list server 
software does not support all mail list features.  He stated that
the SYMPA mail list server includes a database and rich set of 
features.

Paul also pointed out that customers ask him on a monthly 
basis for secure mail list capabilities, so he knows that there
are real requirements for these capabilities. 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

DOMSEC Draft Discussion - Bill Ottaway

Bill presented a briefing regarding the "Domain Security Services Using
S/MIME" I-D <draft-ietf-smime-domsec-04.txt>.  He stated that there 
are minor differences between the -03 and -04 drafts as follows:
- DOMSEC signatures are now added by encapsulation only. (Used to
  allow parallel signatures). 
   - Allows order of third party signature application to be known.
   - More secure.
- Section four re-written to aid understanding

Bill discussed the proposed solution to an issue raised during the
December 1999 S/MIME WG meeting.  From those minutes: "Jim Schaad
recommended that the domain name should be exactly matched.
Jim also pointed out that RFC 2630 states that the content type 
should be id-data when there are no signers of a signedData object."
Bill proposes that the original domain naming conventions should be
preserved.  Bill briefed that the users "must always rely on the CA
to police naming conventions."

Bill addressed Jim's other comment by adding text to the case when
no originator signature is present to state that the eContentType
will be id-data as specified in CMS.  However, the eContent will
contain the unsigned message instead of being left empty as 
suggested in CMS (section 2).  This allows the DOMSEC signature 
to cover the message which does not have an originator signature.

Bill stated that an object identifier must be obtained for the
id-signatureType attribute.  He believes that the document is
ready for working group last call.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Interoperability Matrix - Jim Schaad

Jim developed an interoperability matrix for RFCs 2630 through 2634.
Jim has documented the features supported by Microsoft.  VDA provided
input to Jim regarding the capabilities of the S/MIME Freeware 
Library (SFL).  VDA also provided input regarding interoperability
testing conducted between the SFL and Microsoft.  Jim asked for others 
to submit input to him at [email-masked].  Jim also pointed out that
there are some minor comments/questions to the RFCs that accompany 
the matrix.
  
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Examples of S/MIME Messages - Paul Hoffman

Paul stated that the "Examples of S/MIME Messages" I-D needs more
input.  He stated that VDA had tested the samples in the document
and was planning to provide further sample data for inclusion in 
the document.  He stated that the document is valuable because it
includes the ASN.1 encoded examples.  He stated that there is sample
data that can be extracted using a Perl script that is also
included in the document.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

S/MIME WG Cryptographic Algorithm Specification - Russ Housley

Russ briefed that the current S/MIME WG charter states: "The 
Cryptographic Message Syntax (CMS) is cryptographic algorithm 
independent, yet there is always more than one way to use any algorithm.
To ensure interoperability, each algorithm should have a specification
that describes its use with CMS.  Specifications for the use of 
additional cryptographic algorithms will be developed.  An 
additional suite of  "mandatory to implement" algorithms may be
selected."

Russ briefed that the following I-Ds document the use of crypto
algorithms with RFC 2630:
 1) Use of the CAST-128 Encryption Algorithm in CMS, 
     <draft-ietf-smime-cast-128-01.txt>
 2) CMS KEA and SKIPJACK Conventions,
     <draft-ietf-smime-cmskea-04.txt>
 3) CMS RSAES-OAEP Conventions, 
     <draft-ietf-smime-cms-rsaes-oaep-00.txt>
 4) Elliptic Curve S/MIME, 
     <draft-ietf-smime-ecc-00.txt>
 5) Incorporation of IDEA Encryption Algorithm in S/MIME
     <draft-ietf-smime-idea-02.txt>

Russ said that the following question was raised on the S/MIME WG
mail list: "Should the specifications be published as Standards 
Track RFCs or Informational RFCs?"  Russ stated that "mandatory-to-
implement" algorithms will be published as Standards Track RFCs.
He pointed out that the current S/MIME WG charter also states that
complete algorithm specifications will be published as Standards
Track RFCs.  

Jeff Schiller stated that he believes that all drafts describing
the details of a crypto algorithm must be Informational because
the IETF cannot control the definition of the crypto algorithms.
Jeff further stated that he believes that all documents describing
how crypto algorithms can be used with an IETF protocol can be
Standards Track because the IETF can control the use of the 
crypto algorithms.  He further stated that all documents describing
how secret or proprietary crypto algorithms can be used can not be
Standards Track.   

Russ applied Jeff's recommendations to the aforementioned list
of I-Ds:

 1) The "Use of the CAST-128 Encryption Algorithm in CMS" I-D can
    be a Standards Track document because the CAST 128 algorithm
    description is freely available.

 2) The "CMS KEA and SKIPJACK Conventions" I-D can not be a Standards
    Track document because the U.S. Government has not freely 
    published the description of the FORTEZZA 80-bit wrap function
    used to wrap the 80-bit SKIPJACK content encryption key.  

 3) The "CMS RSAES-OAEP Conventions" I-D can be a Standards Track 
    document because the PKCS #1 v2.0 algorithm description is 
    freely available.  

 4) The "Elliptic Curve S/MIME" I-D can be a Standards Track 
    document because the algorithms are documented in ANSI X9.62
    and ANSI X9.63.  Paul Hoffman said that someone told him that  
    Certicom has patents or pending patents on all of the "interesting
    and useful" curves.  Russ agreed that Standards Track could only
    be achieved if the appropriate patent statements were made by 
    Certicom or any other patent holder. 
    
 5) The "Incorporation of IDEA Encryption Algorithm in S/MIME" I-D 
    can not be a Standards Track document because the IDEA 
    crypto algorithm description is not freely available.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Application of Attribute Certificates (AC) in S/MIME - Greg Colla

Greg's briefing addressed the topic of checking the e-mail address
of the signedData signer against the e-mail address in the signer's
certificate.

Greg briefed that there are problems with binding the subject's e-mail
address with the subject's public key in an X.509 public key certificate
such as:
- Multiple e-mail addresses
- Maintenance of e-mail addresses
- Security Proxy (a proxy signs and decrypts on behalf of many users)
- Privacy/Spam

Greg briefed the following requirements:
Address Aliasing: Associate a single entity with multiple e-mail
    addresses, with a single PKC.
Secure Proxying: Associate multiple entities, each with their own
    e-mail address,  with a common PKC.
Address Sharing: Associate multiple entities, each with their own PKC,
    with a single e-mail address.

Greg proposed the following:
- Maintenance of e-mail addresses limits S/MIME usability
- ACs can be used to cryptographically bind e-mail addresses with PK
   certificates
- E-mail ACs provide a flexible solution for maintaining e-mail 
   addresses
- Supplements current infrastructure
- Localized modifications required to S/MIME components to use 
   E-mail ACs
- E-mail ACs can be used to solve other S/MIME limitations

Greg summarized by stating that his proposal provides a strategy
for removing email addresses from PK certificates.  Greg's briefing
is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional
details regarding his proposal.

Paul Hoffman stated that there are not many deployed ACs and that
most companies have not implemented ACs.  Paul stated his concern
that the AC proposal will add confusion to and delay the deployment
of S/MIME v3.  He stated that ACs can be used in the future to solve
problems.  Greg Colla rebutted that they face these problems today
(i.e. associated with binding e-mail addresses with public keys).

Jim Schaad stated the following comments/questions regarding Greg's
proposal:
1) Two directory lookups will be required for each recipient of
   an encrypted message.  This added time delay will decrease 
   overall performance.
2) How does this help keep email addresses private?  People will
   mail ACs in messages.  A "spam harvester" could obtain the
   e-mail addresses out of messages in transit or out of the 
   directory.
3) Solves internal/external problem.
4) Favors this approach for gateway address identification.
5) Agrees with Paul Hoffman's comments regarding adding confusion.

An attendee stated that CAs issue certificates and ISPs issue addresses.
He asked whether Greg's proposal assumes that these two entities work
closely together.  Greg answered that an ISP could use an RA to create
certificates.  A system administrator could generate the AC.  He made
the point that the public key certificate generation is much more 
important.

Another attendee stated that he doesn't agree that including e-mail 
addresses in certs is a problem.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

S/MIME Freeware Library (SFL) - John Pawling

John provided an update briefing regarding the SFL which is a freeware
implementation of RFC 2630 and RFC 2634.  The SFL can be used with the
Crypto++ freeware library to implement RFC 2631.  The SFL provides
functions to support use of RFC 2632 and RFC 2633.  The goal of the SFL
is to provide a reference implementation of RFC 2630 and RFC 2634 to
encourage their acceptance as Internet Standards.  VDA is developing
the SFL.

John briefed that on 14 January 2000, the U.S. Department of Commerce
published revisions to the Export Administration Regulations that 
changed the U.S. Government's encryption export policy. In accordance
with these revised regulations, the unencumbered SFL source code is 
now freely available to everyone at:
http://www.armadillo.huntsville.al.us/software/smime.
Organizations can use the SFL as part of their applications 
without paying any royalties or licensing fees.  There is a public 
license associated the SFL.

The SFL implements the optional RFC 2634 security services such as signed
receipts, security labels, mail list information, signing certificate
attribute and equivalent security labels.  It has been used with the RSA
BSAFE v4.2, Crypto++ v3.1, Fortezza CI and SPYRUS SPEX/ libraries.  VDA
is developing the capability for the SFL to use any security library
that provides a PKCS #11 interface.

John stated that VDA had used the SFL to perform a significant amount
of S/MIME v3 interop testing. VDA tested the majority of features
in RFCs 2630, 2631 and 2634 as well as some of the features in RFCs
2632 and 2633.  

VDA used the SFL to successfully process and produce the majority
of features documented in "Examples of S/MIME Messages".  A summary
of the test results was sent to the S/MIME WG examples mail list 
<[email-masked]>.  Complete test drivers and test data
is available with the SFL.  

S/MIME v3 interoperability testing between the SFL and Microsoft 
successfully tested almost all signedData and envelopedData features
using mandatory, RSA and Fortezza algorithm suites.  For example, 
the SFL (using Crypto++) exchanged E-S D-H-protected envelopedData
with Microsoft. Almost all of the ESS features were tested.  For 
example, successful signed receipt interoperability testing was 
performed between the SFL and Microsoft.  

VDA verified that the SFL can produce and process the majority of 
the features documented in Jim Schaad's S/MIME v3 interoperability
matrix. John sent the matrix to which VDA added the SFL test results
to Jim Schaad for incorporation into the master S/MIME WG matrix.
VDA developed sample objects that illustrate each feature in the
matrix that the SFL supports.  Complete test drivers and test data
are available with the SFL.

SFL interoperability testing is automated through use of test drivers
and configuration files so it can be easily repeated and modified by 
VDA or independently by a third party.  A third party could enhance
the test drivers or incorporate them in an application such as an
S/MIME interoperability testing auto-responder which organizations
could use to test their S/MIME implementations. 

John also provided information regarding the Certificate Management 
Library (CML) that is a freeware implementation of X.509 version 3
certification path verification as specified in the 1997 X.509
Recommendation (except Delta CRLs are not implemented).  
The CML: validates X.509 certification paths and CRLs; provides
local certificate/CRL storage functions; and provides remote
directory retrieval via LDAP.  The CML uses the Certificate Path
Development Library (CPDL) developed by Cygnacom Solutions to
robustly build certification paths including cross certificates.
The CML complies with the majority of the RFC 2459 requirements.
Organizations can use the CML as part of their applications without
paying any royalties or licensing fees (see CML Public License).
All CML source code is provided.  CML is available at:
http://www.armadillo.huntsville.al.us/software.

John also discussed the VDA-enhanced SNACC Abstract Syntax Notation
One (ASN.1) library that implements the Distinguished Encoding
Rules (DER).

John's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ 
and includes additional details regarding the SFL and CML.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

ETSI Electronic Signature Formats - John Ross

John briefed regarding electronic signature formats for long term 
electronic signatures as part of the ETSI Electronic Signature 
Infrastructure Standardisation.

John briefed that Special Task Force (STF) 155 includes:
Task 1: Policies for Certificate Service Providers (CSP).
	Policy Requirements on CSP issuing Qualified Certificates
Task 2: Electronic Signature Formats
	ETSI ES 201 733 & this Informational RFC
Task 3: Profile for Qualified Certificates
Task 4: Profile for TimeStamping Services

John discussed the "Electronic Signature Formats for long term
electronic signature" I-D, <draft-ietf-smime-esformats-00.txt>.
John briefed that this document is proposed as an Informational RFC. 
It defines the format of an electronic signature that can remain
valid over long periods.  It includes features which can provide 
evidence as to its validity even if the signer later attempts 
to deny (repudiate) the validity of the signature.

John stated that the contents of this Informational RFC will be
technically equivalent to ETSI ES 201 733 V.1.1.1 Copyright (C). 
He noted that the authors do not provide the IETF with any rights
other than to publish as an Internet-Draft.  

John briefed that this document builds on other IETF standards
such as RFC 2630 and RFC 2459.  It will also build on coming 
standards such as the PKIX Timestamping protocol and PKIX AC 
profile.

John discussed the proposal to split the draft document into
two RFCs: one RFC dealing only with ES formats, the other one
dealing only with a Signature Policy format.  In such a case, 
the basis of this split will be, sections 6 and annex C will
be removed from this document and placed in another RFC
dealing with Signature policies.  Also, the signature policy
ASN.1 will be removed the current ASN.1 modules in annex A 
and placed in a new ASN.1 module in the other RFC dealing 
with Signature Policies.  A separate OID for the Signature 
Policy arc would ease separation.

Denis Pinkas made the point that the SigningCertificate signed
attribute provides information about the signer and indicates the
signer's AC that indicates which role the signer used to sign the 
data.

The point was made that the Signature policy Identifier attribute
is used by the signer to indicate the signature policy under which
he is signing.  The Signature policy Identifier attribute will 
contain a hash of the signature policy.  The esformats-00 I-D 
provides further details regarding the definition and use of 
signature policies.

John made the point that the esformats-00 I-D must be equivalent
ETSI ES 201 733 V.1.1.1, so major changes can't be made to the 
esformats-00 I-D.

Sean Turner asked how the ETSI Electronic Signature format relates
to the timestamping work being done in the PKIX WG.  Denis Pinkas
answered that the ETSI Electronic Signature work uses CMS and will
build on the PKIX Timestamping protocol.

Mike Myers asked if the PKIX Data Validation and Certification Server
(DVCS) Protocols would satisfy the ETSI Electronic Signature 
requirements.  Peter Sylvester said that the DVCS protocol could
include the ETSI Electronic Signature information.  Denis stated the
protocols could be used together, but don't have to be.

Sean Turner asked if the S/MIME WG cared about the contents of the 
esformats-00 I-D, since they can't change it anyway.  John Ross
replied that the signature policy portion of the I-D can be changed,
but that the Electronic Signature format can not be changed.  John
welcomed input to the signature policy portion of the I-D.

Russ Housley asked if the signature policy portion of the I-D was
covered under the ETSI copyright.  John Ross said that it was.  He 
further stated that they are working on getting the copyright rules 
relaxed regarding this topic.  ETSI may split the ES 201 733 V.1.1.1 
document into two parts to be consistent with a split in the 
esformats-00 I-D.  A straw poll of the attendees favored splitting 
the esformats-00 I-D.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Wrap Up - Russ Housley

Russ stated that the "Use of the CAST-128 Encryption Algorithm in
CMS" I-D was in working group last call.  Jim Schaad stated that
he had provided comments to the document.  Russ stated that 
a new draft of the I-D will be submitted for IETF-wide last call.
 
Russ stated that he would like to issue last call for the 
"Password-based Encryption for S/MIME" I-D.  Jim Schaad stated that
he had provided significant comments to the document.  John Pawling
pointed out that several people had questioned why the I-D defined
yet another key wrapping algorithm.  Russ said that Peter Gutmann
needs to address these comments on the mail list.  Russ pointed
out that the process of transforming a password to a key would
be documented in a separate RFC.

Russ discussed the "Compressed Data Content Type for S/MIME" I-D.  
Peter Gutmann sent a message to the S/MIME WG mail list asking:
"Does anyone have any further thoughts on compression as a CMS 
content type vs a MIME type?"  Russ said that the S/MIME WG
needed to make a decision regarding Peter's question. Paul 
Hoffman stated that compression has been discussed on the
MIME mail list, but it has not been standardized.  He said that
the issue needs to get resolved.  Russ stated that Jeff Schiller
recommended that the S/MIME WG "just do it" because the issue 
needs to be resolved for efficiency purposes.  Russ took a straw
poll and only three people expressed an opinion.

Meeting adjourned.

Date: Mon, 08 May 2000 10:38:31 -0400
From: "Nida Sun" <[email-masked]>
Organization: Fannie Mae
To: <[email-masked]>
Subject: Delete
Sender: [email-masked]

Date: Mon, 08 May 2000 09:36:38 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: S/MIME IDEA Draft
Sender: [email-masked]

I have just been made aware that the IDEA encryption algorithm has been 
posted on the "IETF Page of Intellectual Property Rights Notices" web site:
	http://www.ietf.org/ietf/IPR/ASCOM-IDEA

Also, Stephan tells me that a new Internet-Draft will be posted in the next 
few days.  Once it is posted, I will be calling for Working Group Last Call 
on this document.

By the way, I have asked the authors to change the title.  The new title 
will be:
	Use of the IDEA Encryption Algorithm in CMS

Russ

From: "Tony Meyer" <[email-masked]>
Subject: Its A New World  A New Economy
To: new39s
Date: Sun, 07 May 2000 13:32:39 -0500
Sender: [email-masked]

Today It’s Cell Phones and the Internet – What Is The 
Next Big Thing?
 
Have you ever wondered why so many tech and e-business-related 
stocks just keep  bouncing back or why many Internet businesses 
have billion-dollar market caps?
 
Simply stated:  the numbers are staggering.  The market analysts 
and the smart  money know that there is a huge amount of money 
to be made.  It is conservatively  estimated that in 2004 there
will be over 7 Trillion dollars in Internet business-to-business
transactions.  This year there will be less than a quarter of 
a Trillion B2B transactions but even a quarter of a Trillion is a
staggering sum.   In three years the B2B market is expected to 
expand by over 28 times!  The numbers are staggering!
 
If you have a minimum of $25,000.00 to loan, short term; send 
an e-mail to us at:
mailto:[email-masked]?subject=Biz_Plan

requesting a copy of our business plan.  To see it you must 
state in your e-mail  that you are capable of comfortably 
loaning $25,000.00 in support of the right  business plan.  
Prior to receiving our plan you will be required to sign
a nondisclosure  agreement.  When you do you will discover 
that we have it right.  The right contacts, products, vision,
management and the right marketing plan all at the right time!  
You can be a part of the “Next Big Thing”!
 
No more than ten people will have the chance to take advantage 
of this opportunity.   They will receive 20% interest on their 
money and stock options with very lucrative  possibilities.  
When you see our plan you will realize that investors
will be standing in line to purchase the stock at private 
placement and/or IPO prices. Through the stock options we are 
offering ten or fewer visionary business partners will 
enjoy stock options at a price far below private placement 
or IPO prices.  If you are serious and you can comfortably 
loan a minimum of $25,000.00 act now!
 
Are you just curious?  Please . . . Do not waste your time 
or ours if you do not have  the investment credentials mentioned 
above

PLEASE NOTE:  
Further transmissions to you by the sender of this email may be 
stopped at no cost  to you by sending a reply to:

mailto:[email-masked]?subject=remove

You have received this offer because your email address is part 
of our "in House" list.  You or someone you know  has sent your 
email address to us in the past.  Our team promotes professional 
and responsible use of   email marketing.
If this  message is in error we apologize. 

From: "Rene Brir" <[email-masked]>
Subject: You Can Win
To: [email-masked]
Date: Sat, 06 May 2000 16:49:56 -0500
Sender: [email-masked]

Are you interested in increasing your odds in
winning a lottery?  To find out how, reply to:
mailto:[email-masked]?subject=How_to_win
We will only respond if all of the
information below is completed.
Thanks for your time.

Name: _________________________________________

Email Address: __________________________________

Address __________________________________________

City ________________________ ST _____ ZIP __________

Phone  (_______)  ______________________Best time to call.

*****************************************************************
This message is sent in compliance of the new email bill section 301.
PerSection 301, Paragraph (a)(2)(C) of S. 1618, further transmissions
to
you by the sender of this email may be stopped
at no cost to you. This message is not intended for residents in
the State of WA, CA & VA Screening of addresses has been
done to the best of our technical ability.  If you are a Washington,
Virginia, or California resident please remove yourself.
=================================================================
If you wish to be removed from future mailings,
please Reply to:mailto:[email-masked]?subject=remove

From: [email-masked]
Date: Wed, 3 May 2000 16:52:33 -0400 (EDT)
To: <[email-masked]>
Subject: 50 Megs of web space for $9.95 a month!
Sender: [email-masked]

50 Megs of web space for $9.95 a month!!!! 
Unlimited E-Mail boxes at yourdomain.com 
and much more!
We offer web hosting in a number of 
different packages. Tired of paying alot 
for web hosting and not recieving quality
customer service? Try out our hosting 
services, and see the difference of a web
hosting company run by computer technicians.

Call 1-888-682-5214 for more information.

Ask about our dedicated servers and reseller
package. $99.95 a month Colo and Dedicated
Servers.

To be removed from this list reply to 
[email-masked] with the header of Delete