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

[The IESG <[e-mail]>]

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.




Received: by ns.secondary.com (8.9.3/8.9.3) id XAA06497 for ietf-smime-bks; Wed, 31 May 2000 23:03:15 -0700 (PDT)
Received: from vejlehs.vejlehs.dk (vejlehs.vejlehs.dk [194.182.192.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA06493 for <[e-mail]>; Wed, 31 May 2000 23:03:13 -0700 (PDT)
Received: from host (ip57.providence11.ri.pub-ip.psi.net [38.26.242.57]) by vejlehs.vejlehs.dk (8.8.5/SCO5) with ESMTP id IAA15934; Thu, 1 Jun 2000 08:10:30 +0200 (CETDST)
Message-Id: <[e-mail]>
From: "Rob Saky" <[e-mail]>
Subject: FREE INFORMATION # DED
To: [e-mail]
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date: Wed, 31 May 2000 21:25:21 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA06494
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

    HOW TO SUBSTANTIALLY INCREASE SALES:

Easily accept major credit cards right away!

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

call our [phone] 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 [phone] and ask for extension FBK for free
setup!




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





Received: by ns.secondary.com (8.9.3/8.9.3) id GAA07287 for ietf-smime-bks; Wed, 31 May 2000 06:42:26 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07283 for <[e-mail]>; Wed, 31 May 2000 06:42:24 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09713; Wed, 31 May 2000 09:50:03 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: Use of the KEA and SKIPJACK Algorithms in CMS to Informational
Date: Wed, 31 May 2000 09:50:02 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.



Received: by ns.secondary.com (8.9.3/8.9.3) id FAA05026 for ietf-smime-bks; Tue, 30 May 2000 05:28:19 -0700 (PDT)
Received: from bart.callnet0800.com (bart.callnet0800.com [212.67.128.108]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA05019 for <[e-mail]>; Tue, 30 May 2000 05:26:57 -0700 (PDT)
Received: from smtp.callnetuk.com [212.67.128.5] by bart.callnet0800.com with ESMTP (SMTPD32-5.05) id A56DAD0011A; Tue, 30 May 2000 13:34:53 +0100
Received: from develera [212.67.132.137] by smtp.callnetuk.com (SMTPD32-5.05) id A54328D10242; Tue, 30 May 2000 13:34:11 +0100
From: "Frank O'Dwyer" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: RE: Border directories
Date: Tue, 30 May 2000 13:34:48 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <[e-mail]>
Importance: Normal
Disposition-Notification-To: "Frank O'Dwyer" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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
[e-mail] 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" <[e-mail]>
> >
> > 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
> > [e-mail]
>
> ---
> 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



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA00635 for ietf-smime-bks; Tue, 30 May 2000 03:27:17 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00630 for <[e-mail]>; Tue, 30 May 2000 03:27:15 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22839; Tue, 30 May 2000 06:34:53 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-domsec-05.txt
Date: Tue, 30 May 2000 06:34:53 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id LAA11596 for ietf-smime-bks; Fri, 26 May 2000 11:39:36 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11592 for <[e-mail]>; Fri, 26 May 2000 11:39:35 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.206]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA01022; Fri, 26 May 2000 11:46:17 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 26 May 2000 14:33:20 -0400
To: William Whyte <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: draft-ietf-smime-idea-04.txt: parameters question
Cc: [e-mail]
In-Reply-To: <[e-mail] ltimore.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: by ns.secondary.com (8.9.3/8.9.3) id JAA09587 for ietf-smime-bks; Fri, 26 May 2000 09:42:56 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09583 for <[e-mail]>; Fri, 26 May 2000 09:42:55 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.206]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA29115; Fri, 26 May 2000 09:49:39 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 26 May 2000 12:23:33 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: WG LAST CALL: draft-ietf-smime-idea-04.txt
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: by ns.secondary.com (8.9.3/8.9.3) id LAA17280 for ietf-smime-bks; Thu, 25 May 2000 11:35:27 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA17276 for <[e-mail]>; Thu, 25 May 2000 11:35:26 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id OAA28258 for <[e-mail]>; Thu, 25 May 2000 14:36:58 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 25 May 2000 14:39:25 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Border directories
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: oz/RB+nFzxs/srk0673F5g==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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" <[e-mail]>
> 
> 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
> [e-mail]



Received: by ns.secondary.com (8.9.3/8.9.3) id IAA13387 for ietf-smime-bks; Thu, 25 May 2000 08:37:17 -0700 (PDT)
Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13382 for <[e-mail]>; Thu, 25 May 2000 08:37:13 -0700 (PDT)
Received: by balinese.baltimore.ie; id QAA15783; Thu, 25 May 2000 16:44:24 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma015713; Thu, 25 May 00 16:43:25 +0100
Received: from irlbdc.irl.emea (irlbdc.baltimore.ie [192.168.20.3]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA32503 for <[e-mail]>; Thu, 25 May 2000 16:43:25 +0100
Received: by irlbdc.cdsemea.baltimore.com with Internet Mail Service (5.5.2448.0) id <J5VJJ8YX>; Thu, 25 May 2000 16:44:13 +0100
Message-ID: <[e-mail]>
From: William Whyte <[e-mail]>
To: [e-mail]
Subject: draft-ietf-smime-idea-04.txt: parameters question
Date: Thu, 25 May 2000 16:44:18 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: by ns.secondary.com (8.9.3/8.9.3) id DAA03166 for ietf-smime-bks; Thu, 25 May 2000 03:48:30 -0700 (PDT)
Received: from bart.callnet0800.com (bart.callnet0800.com [212.67.128.108]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA03161 for <[e-mail]>; Thu, 25 May 2000 03:48:28 -0700 (PDT)
Received: from smtp.callnetuk.com [212.67.128.5] by bart.callnet0800.com with ESMTP (SMTPD32-5.05) id A69431F000EE; Thu, 25 May 2000 11:55:25 +0100
Received: from develera [212.67.129.83] by smtp.callnetuk.com (SMTPD32-5.05) id A65610B901FA; Thu, 25 May 2000 11:54:14 +0100
From: "Frank O'Dwyer" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Border directories
Date: Thu, 25 May 2000 11:54:53 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Disposition-Notification-To: "Frank O'Dwyer" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
[e-mail]

---
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



Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15415 for ietf-smime-bks; Tue, 23 May 2000 07:22:37 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15411 for <[e-mail]>; Tue, 23 May 2000 07:22:36 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id KAA16812 for <[e-mail]>; Tue, 23 May 2000 10:24:13 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 23 May 2000 10:26:31 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Border directories
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: +Os8NFXnHjLZTpqzx2st+A==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] (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.



Received: by ns.secondary.com (8.9.3/8.9.3) id DAA11334 for ietf-smime-bks; Tue, 23 May 2000 03:28:54 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11330 for <[e-mail]>; Tue, 23 May 2000 03:28:52 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29393; Tue, 23 May 2000 06:35:56 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-idea-04.txt
Date: Tue, 23 May 2000 06:35:56 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id RAA06760 for ietf-smime-bks; Sun, 21 May 2000 17:44:50 -0700 (PDT)
Received: from interser.www2.opegieka.com.pl (interser.opegieka.com.pl [195.116.116.121] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA06756 for <[e-mail]>; Sun, 21 May 2000 17:44:44 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from host (1Cust17.tnt1.providence.ri.da.uu.net [63.21.181.17]) by interser.www2.opegieka.com.pl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id KKLWWV2Q; Mon, 22 May 2000 03:00:31 +0200
From: "Wendy Steiner" <[e-mail]>
Subject: A Must See #2199
To: op29s
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date: Sun, 21 May 2000 18:18:47 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id RAA06757
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]?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:[e-mail]?subject=remove
///////////////////////////////////////////////////





Received: by ns.secondary.com (8.9.3/8.9.3) id VAA17870 for ietf-smime-bks; Fri, 19 May 2000 21:17:21 -0700 (PDT)
Received: from platon.becomsys.de ([e-mail] [194.162.52.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA17866 for <[e-mail]>; Fri, 19 May 2000 21:17:20 -0700 (PDT)
Received: from host (1Cust24.tnt2.providence.ri.da.uu.net [63.21.182.24]) by platon.becomsys.de (8.8.8/8.8.8) with ESMTP id GAA27685; Sat, 20 May 2000 06:12:39 +0200
Message-Id: <[e-mail]>
From: "Karl Serny" <[e-mail]>
Subject: You Can Win... # 37B
To: [e-mail]
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date: Fri, 19 May 2000 23:02:17 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA17867
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 
Are you interested in increasing your odds in
winning a lottery?  To find out how, reply to:
mailto:[e-mail]?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:[e-mail]?subject=remove






Received: by ns.secondary.com (8.9.3/8.9.3) id DAA01789 for ietf-smime-bks; Fri, 19 May 2000 03:45:18 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01783 for <[e-mail]>; Fri, 19 May 2000 03:45:17 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02537; Fri, 19 May 2000 06:52:00 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-certdist-05.txt
Date: Fri, 19 May 2000 06:51:59 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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 <[e-mail]> 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA19492 for ietf-smime-bks; Thu, 18 May 2000 07:51:10 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19488 for <[e-mail]>; Thu, 18 May 2000 07:51:09 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id KAA10259; Thu, 18 May 2000 10:52:55 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 18 May 2000 10:54:13 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Cert Dist Changes
To: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: w1MWkw8LYbFIlVAPH9/bVQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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" <[e-mail]>
> To: [e-mail]
> 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.
> ******************************************************************************



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA13378 for ietf-smime-bks; Wed, 17 May 2000 21:35:05 -0700 (PDT)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA13371 for <[e-mail]>; Wed, 17 May 2000 21:35:03 -0700 (PDT)
Received: from nwlink.com (listserv.nwlink.com [209.20.130.70]) by smtp.nwlink.com (8.9.3/8.9.3) with SMTP id VAA15900 for <[e-mail]>; Wed, 17 May 2000 21:41:41 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
Reply-to: [e-mail]
To: [e-mail]
Date: Wed, 17 May 2000 21:41:41 +0800
Subject: Cert Dist Changes
Message-id: <[e-mail]>
X-User-Info: 131.107.3.84
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: by ns.secondary.com (8.9.3/8.9.3) id IAA23264 for ietf-smime-bks; Mon, 15 May 2000 08:10:03 -0700 (PDT)
Received: from hen.scotland.net (phys-hen2.scotland.net [194.247.65.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23254 for <[e-mail]>; Mon, 15 May 2000 08:10:00 -0700 (PDT)
Received: from [148.176.234.79] (helo=jrwork) by hen.scotland.net with smtp (Exim 2.12 #2) id 12rMXm-0004Lt-00; Mon, 15 May 2000 16:12:31 +0100
Message-ID: <002c01bfbe7f$4031e900$0400000a@jrwork>
From: "John Ross" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: "s/mime list" <[e-mail]>
Subject: Fw:      ETSI ES 201 733 Electronic Signature Formats
Date: Mon, 15 May 2000 16:07:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <[e-mail]>
To: [e-mail] <[e-mail]>
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: [phone]
>
>Technical news from ETSI:
> http://www.etsi.org/tbnews/ta_news.htm
>



Received: by ns.secondary.com (8.9.3/8.9.3) id GAA21349 for ietf-smime-bks; Mon, 15 May 2000 06:23:30 -0700 (PDT)
Received: from mail.bsb.zaz.com.br (mail.bsb.nutecnet.com.br [200.252.253.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA21341 for <[e-mail]>; Mon, 15 May 2000 06:23:25 -0700 (PDT)
Received: from default (dl5014-bsb.bsb.nutecnet.com.br [200.252.15.14]) by mail.bsb.zaz.com.br (8.9.3/8.9.3) with SMTP id KAA11957 for <[e-mail]>; Mon, 15 May 2000 10:32:15 -0300
Message-ID: <000c01bfbe59$154d0880$0d01a8c0@default>
From: "Wellington Alencar" <[e-mail]>
To: <[e-mail]>
Subject: S/MIME
Date: Mon, 15 May 2000 10:33:58 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01BFBE59.13BBBA20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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--



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA14951 for ietf-smime-bks; Mon, 15 May 2000 01:46:29 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA14947 for <[e-mail]>; Mon, 15 May 2000 01:46:28 -0700 (PDT)
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 May 2000 01:51:33 -0700 (Pacific Daylight Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id <KYFM8V7W>; Mon, 15 May 2000 01:51:08 -0700
Message-ID: <[e-mail]>
From: Jeff Tozzi <[e-mail]>
To: "'Andrew Ferguson'" <[e-mail]>
Cc: [e-mail]
Subject: RE: S/MIME v3 plus ESS
Date: Mon, 15 May 2000 01:52:20 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBE4A.E128AD60"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]> [e-mail] 
 

 -----Original Message-----
From: Andrew Ferguson [mailto:[e-mail]]
Sent: Monday, May 15, 2000 12:28 AM
To: [e-mail]
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: [phone] 
Fax: [phone]
Mob: [phone] 
Email: [e-mail] 
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:[e-mail]"><FONT 
face=Arial size=2><EM>[e-mail]</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:[e-mail]]<BR><B>Sent:</B> Monday, May 15, 
2000 12:28 AM<BR><B>To:</B> [e-mail]<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: [phone] <BR>Fax: [phone]<BR>Mob: [phone] 
  <BR>Email: [e-mail] <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--


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA13343 for ietf-smime-bks; Mon, 15 May 2000 00:15:52 -0700 (PDT)
Received: from fep9.mail.ozemail.net (fep9.mail.ozemail.net [203.2.192.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA13339 for <[e-mail]>; Mon, 15 May 2000 00:15:47 -0700 (PDT)
Received: from intouch1.software-aus.com.au (tforcep1.tforce.com.au [203.61.131.1]) by fep9.mail.ozemail.net (8.9.0/8.6.12) with SMTP id RAA09329 for <[e-mail]>; Mon, 15 May 2000 17:22:05 +1000 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 15 May 2000 17:27:49 +1000
To: [e-mail]
From: Andrew Ferguson <[e-mail]>
Subject: S/MIME v3 plus ESS
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_6357582==_.ALT"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--=====================_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: [phone] 
Fax: [phone]
Mob: [phone] 
Email: [e-mail] 
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: [phone] <br>
Fax: [phone]<br>
Mob: [phone] <br>
Email: [e-mail] <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--



Received: by ns.secondary.com (8.9.3/8.9.3) id WAA04735 for ietf-smime-bks; Fri, 12 May 2000 22:00:48 -0700 (PDT)
Received: from mauve.innosoft.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA04729 for <[e-mail]>; Fri, 12 May 2000 22:00:47 -0700 (PDT)
From: [e-mail]
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 12 May 2000 22:06:28 -0800 (PST)
Date: Fri, 12 May 2000 21:59:56 -0800 (PST)
Subject: RE: Border directories
In-reply-to: "Your message dated Fri, 12 May 2000 17:13:01 -0700" <[e-mail]>
To: Philip Hallam-Baker <[e-mail]>
Cc: "'Bob Jueneman'" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA03367 for ietf-smime-bks; Fri, 12 May 2000 17:08:32 -0700 (PDT)
Received: from pigeon.verisign.com ([208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA03360 for <[e-mail]>; Fri, 12 May 2000 17:08:31 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id RAA00055; Fri, 12 May 2000 17:12:17 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <KJDMFHYX>; Fri, 12 May 2000 17:13:08 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: Border directories
Date: Fri, 12 May 2000 17:13:01 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0000_01BFBC4E.9C897BB0"; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMzAwMTQwMFowIwYJKoZI
hvcNAQkEMRYEFOhArRGvX7ebQMtg7aPUvMBwDl4nMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAOZJk6KJzUa3ua3opcGoNuYNvI+0dAo7wJiW4PJLmyLIhUO58C8Pf/nl9XR1Kw4JN
ZLd9kwHuVBpiLelFZ4xgVRThAUz6yHvMC5vpzDMEq0WEgR3n5f61wdlJ6uUoOkIZV4mMkPArv2B0
bjLnURfzyKtvuMVHQz38FlEehoG8qt0AAAAAAAA=

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



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA02661 for ietf-smime-bks; Fri, 12 May 2000 16:31:00 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA02657 for <[e-mail]>; Fri, 12 May 2000 16:30:59 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 12 May 2000 17:36:29 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 12 May 2000 17:36:16 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Border directories
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_B5ED9D6D.395892DF"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <[e-mail]> 05/13/00 05:36AM >>>
"David P. Kemp" <[e-mail]> 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;[e-mail]&gt; =
05/13/00=20
05:36AM &gt;&gt;&gt;<BR>"David P. Kemp" &lt;[e-mail]&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--


Received: by ns.secondary.com (8.9.3/8.9.3) id KAA27527 for ietf-smime-bks; Fri, 12 May 2000 10:37:56 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27520 for <[e-mail]>; Fri, 12 May 2000 10:37:54 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA14512; Sat, 13 May 2000 05:43:42 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95815342211633>; Sat, 13 May 2000 05:43:42 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Border directories
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 13 May 2000 05:43:42 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Colin Robbins <[e-mail]> 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.



Received: by ns.secondary.com (8.9.3/8.9.3) id KAA27434 for ietf-smime-bks; Fri, 12 May 2000 10:30:17 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27430 for <[e-mail]>; Fri, 12 May 2000 10:30:15 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA15790; Sat, 13 May 2000 05:36:15 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95815297512191>; Sat, 13 May 2000 05:36:15 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Border directories
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 13 May 2000 05:36:15 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"David P. Kemp" <[e-mail]> 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.



Received: by ns.secondary.com (8.9.3/8.9.3) id KAA27272 for ietf-smime-bks; Fri, 12 May 2000 10:16:48 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27267 for <[e-mail]>; Fri, 12 May 2000 10:16:45 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA14617 for <[e-mail]>; Sat, 13 May 2000 05:22:53 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95815217312068>; Sat, 13 May 2000 05:22:53 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: Border directories
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 13 May 2000 05:22:53 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Walter Williams" <[e-mail]> 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).



Received: by ns.secondary.com (8.9.3/8.9.3) id KAA27130 for ietf-smime-bks; Fri, 12 May 2000 10:05:16 -0700 (PDT)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27126 for <[e-mail]>; Fri, 12 May 2000 10:05:15 -0700 (PDT)
Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id NAA26404; Fri, 12 May 2000 13:11:08 -0400 (EDT)
From: "Walter Williams" <[e-mail]>
To: "Philip Hallam-Baker" <[e-mail]>, "'David P. Kemp'" <[e-mail]>, <[e-mail]>
Subject: RE: Border directories
Date: Fri, 12 May 2000 13:01:33 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>
> 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.



Received: by ns.secondary.com (8.9.3/8.9.3) id JAA26053 for ietf-smime-bks; Fri, 12 May 2000 09:01:20 -0700 (PDT)
Received: from lancaster.nexor.co.uk (lancaster.nexor.co.uk [193.63.53.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26044 for <[e-mail]>; Fri, 12 May 2000 09:01:15 -0700 (PDT)
Received: from crusader (actually host crusader.nexor.co.uk) by lancaster.nexor.co.uk with SMTP (Mailer); Fri, 12 May 2000 17:07:04 +0100
Reply-To: "Colin.Robbins" <[e-mail]>
From: Colin Robbins <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, ietf-smime <[e-mail]>
Subject: RE: Border directories
Date: Fri, 12 May 2000 17:07:01 +0100
Message-ID: <003901bfbc2c$1c5e0590$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA25869 for ietf-smime-bks; Fri, 12 May 2000 08:50:27 -0700 (PDT)
Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25865 for <[e-mail]>; Fri, 12 May 2000 08:50:26 -0700 (PDT)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id IAA17431; Fri, 12 May 2000 08:56:24 -0700 (PDT)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <KJDK6SSK>; Fri, 12 May 2000 08:55:25 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Subject: RE: Border directories
Date: Fri, 12 May 2000 08:55:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_0014_01BFBC07.FC77DD10"; micalg=SHA1; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMjE1NDgyN1owIwYJKoZI
hvcNAQkEMRYEFCdWJOTg0Mn6FSkWc64Zzcj3dvlGMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAfkukUuFUF/bsWt/xX9WLRoCtr5zddTSW+J9HZvBIOT/FEPmuZ6rZfL/ZTnjndpII
wJZYMivdpcvqQkq37qhR00LGl2sjYF1KcnKA21NP5kzK10iCIBjYru2x/13swe+IpVwZnkOIq9LO
iFfazwYlnFPSBIrAJLr7FYU0CEOMAyAAAAAAAAA=

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



Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25172 for ietf-smime-bks; Fri, 12 May 2000 08:19:48 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25168 for <[e-mail]>; Fri, 12 May 2000 08:19:47 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id LAA01396 for <[e-mail]>; Fri, 12 May 2000 11:21:34 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 12 May 2000 11:24:14 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Border directories
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: c9yL/76h5kk9tWZa3I1ujw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] (Peter Gutmann)
>
> 
> "Walter Williams" <[e-mail]> 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.



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA25054 for ietf-smime-bks; Fri, 12 May 2000 08:14:09 -0700 (PDT)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25050 for <[e-mail]>; Fri, 12 May 2000 08:14:08 -0700 (PDT)
Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id LAA20631; Fri, 12 May 2000 11:19:54 -0400 (EDT)
From: "Walter Williams" <[e-mail]>
To: "Philip Hallam-Baker" <[e-mail]>, <[e-mail]>, "'Laurent Deffranne'" <[e-mail]>
Cc: "'ietf-smime'" <[e-mail]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Fri, 12 May 2000 11:10:19 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> Sent: Friday, May 12, 2000 10:07 AM
> To: Walter Williams; [e-mail]; '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:[e-mail]]
> Sent: Thursday, May 11, 2000 2:26 PM
> To: [e-mail]; '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: [e-mail]
> > [mailto:[e-mail]]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:[e-mail]]
> > 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: [e-mail]
> > > [mailto:[e-mail]]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
> >
> >
> >
> >
> >
>



Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25031 for ietf-smime-bks; Fri, 12 May 2000 08:12:08 -0700 (PDT)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25023 for <[e-mail]>; Fri, 12 May 2000 08:12:06 -0700 (PDT)
Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id LAA19855; Fri, 12 May 2000 11:17:44 -0400 (EDT)
From: "Walter Williams" <[e-mail]>
To: "Philip Hallam-Baker" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Border directories
Date: Fri, 12 May 2000 11:08:09 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> Sent: Friday, May 12, 2000 10:07 AM
> To: Walter Williams; [e-mail]; [e-mail];
> [e-mail]
> 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
>



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA23773 for ietf-smime-bks; Fri, 12 May 2000 07:17:33 -0700 (PDT)
Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23769 for <[e-mail]>; Fri, 12 May 2000 07:17:32 -0700 (PDT)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA14211 for <[e-mail]>; Fri, 12 May 2000 07:23:41 -0700 (PDT)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <KJDK6RXT>; Fri, 12 May 2000 07:22:42 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: [e-mail]
Subject: RE: Border directories
Date: Fri, 12 May 2000 07:22:40 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_0009_01BFBBFC.28435FC0"; micalg=SHA1; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMjE0MjM0N1owIwYJKoZI
hvcNAQkEMRYEFJ28Y033HZ25s2lOUIqdH+jgObbDMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAIj1J/TvYQymbMry8Fxccp1YarsRvFEs0udf4Z9lU4KQ9Tvrr72CF1Ca0nsoCtF8N
Qqys4qMdZY4pA+9KxQI9za1bl3qdbjkyQ3kqOyynyzzGC50nS2uXPmB66iIqZ0Tj/oYpSoAUwsUl
CjKkWQykuGn5UoO7NUsBO9NELk2EGX0AAAAAAAA=

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



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA23521 for ietf-smime-bks; Fri, 12 May 2000 07:02:19 -0700 (PDT)
Received: from pigeon.verisign.com ([208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23517 for <[e-mail]>; Fri, 12 May 2000 07:02:18 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA10483; Fri, 12 May 2000 07:06:03 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <KJDMFA0K>; Fri, 12 May 2000 07:06:53 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: Walter Williams <[e-mail]>, [e-mail], "'Laurent Deffranne'" <[e-mail]>
Cc: "'ietf-smime'" <[e-mail]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Fri, 12 May 2000 07:06:43 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0005_01BFBBA4.40D932B0"; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
Sent: Thursday, May 11, 2000 2:26 PM
To: [e-mail]; '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: [e-mail]
> [mailto:[e-mail]]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:[e-mail]]
> 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: [e-mail]
> > [mailto:[e-mail]]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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMjAzNTQzMlowIwYJKoZI
hvcNAQkEMRYEFNTMUOluu1fjEtV9dmhuUxErV2SHMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAlucBtBuqN90uuReSkBH/JFyPTi2mIs7fCQWIzIFBdxixm9mtUKV6QsgpTvqzX83Y
SZxW5UlIm9phYAv34Kq07ua0mvjkWpXiBydELOFVSOCOnq9xjohn9L/OMKe3DtA1p6NwG/ausbN7
VbtveaCXJtaSYm6g1+vzn8aaYoIP5vcAAAAAAAA=

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



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA23516 for ietf-smime-bks; Fri, 12 May 2000 07:02:18 -0700 (PDT)
Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23512 for <[e-mail]>; Fri, 12 May 2000 07:02:17 -0700 (PDT)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA13536; Fri, 12 May 2000 07:07:49 -0700 (PDT)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <KJDK6RQB>; Fri, 12 May 2000 07:06:50 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: Walter Williams <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: Border directories
Date: Fri, 12 May 2000 07:06:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0000_01BFBBA2.F60F30F0"; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMjAzNDUxN1owIwYJKoZI
hvcNAQkEMRYEFOqSplfwmXLZmrEPc4YSJypgLzozMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAbToJbzvGboMoOFPCOLRCFntvQyI63VlFZ21bZNhMSpakE4o3Q4G3KkmHbb5i2C5m
KRDfpXYN7jZpnORm/PR1ZwZ7C+RwH/Nl4MyQJS+S2JohZ1u7e3952z9N18k3uVR1f+YiwZmlDgpV
cTrzk4AM0He6Q5EfBkuKcF2DGwN9bLoAAAAAAAA=

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



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA14538 for ietf-smime-bks; Fri, 12 May 2000 03:07:56 -0700 (PDT)
Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA14532 for <[e-mail]>; Fri, 12 May 2000 03:07:52 -0700 (PDT)
Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Fri, 12 May 00 11:26:00 +0100
X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2
Received: by BJEX1 with Internet Mail Service (5.5.2448.0) id <K2XJWMRF>; Fri, 12 May 2000 11:09:26 +0100
Message-ID: <608D67882786D211B1070090271E4CB94813DC@BJEX1>
From: "Stuart Ross" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Border directories
Date: Fri, 12 May 2000 11:09:25 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
X-WSS-ID: 150503B21222-01-01
Content-Type: multipart/alternative;  boundary="----_=_NextPart_001_01BFBBFA.26B7EACE"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]]
Sent: Friday, May 12, 2000 8:23 AM
To: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: RE: Border directories


"Walter Williams" <[e-mail]> 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: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail].=
nz</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, May 12, 2000 8:23 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]; [e-mail]; =
[e-mail];</FONT>
<BR><FONT SIZE=3D2>[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Border directories</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&quot;Walter Williams&quot; =
&lt;[e-mail]&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--



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA13601 for ietf-smime-bks; Fri, 12 May 2000 02:47:29 -0700 (PDT)
Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA13586 for <[e-mail]>; Fri, 12 May 2000 02:47:24 -0700 (PDT)
Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Fri, 12 May 00 11:05:33 +0100
X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2
Received: by BJEX1 with Internet Mail Service (5.5.2448.0) id <K2XJWMQP>; Fri, 12 May 2000 10:48:59 +0100
Message-ID: <608D67882786D211B1070090271E4CB94813DA@BJEX1>
From: "Stuart Ross" <[e-mail]>
To: "'Walter Williams'" <[e-mail]>, "Piers Chivers" <[e-mail]>, "'Laurent Deffranne'" <[e-mail]>
cc: "'ietf-smime'" <[e-mail]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Fri, 12 May 2000 10:48:59 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
X-WSS-ID: 150508E71069-01-01
Content-Type: multipart/alternative;  boundary="----_=_NextPart_001_01BFBBF7.4BCEA1D4"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
Sent: Thursday, May 11, 2000 7:26 PM
To: [e-mail]; '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: [e-mail]
> [mailto:[e-mail]]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:[e-mail]]
> 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: [e-mail]
> > [mailto:[e-mail]]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:[e-mail]">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: [e-mail]; '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: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:[e-mail]">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:[e-mail]">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: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [<A =
HREF=3D"mailto:[e-mail]">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--



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA13336 for ietf-smime-bks; Fri, 12 May 2000 02:41:32 -0700 (PDT)
Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA13310 for <[e-mail]>; Fri, 12 May 2000 02:41:01 -0700 (PDT)
Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Fri, 12 May 00 10:59:03 +0100
X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2
Received: by BJEX1 with Internet Mail Service (5.5.2448.0) id <K2XJWMQ2>; Fri, 12 May 2000 10:42:29 +0100
Message-ID: <608D67882786D211B1070090271E4CB94813D9@BJEX1>
From: "Stuart Ross" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: Border directories
Date: Fri, 12 May 2000 10:42:28 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
X-WSS-ID: 15050A6D1020-01-01
Content-Type: multipart/alternative;  boundary="----_=_NextPart_001_01BFBBF6.63333534"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]]
Sent: Friday, May 12, 2000 7:06 AM
To: [e-mail]; [e-mail]; [e-mail]
Subject: RE: Border directories


"Walter Williams" <[e-mail]> 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: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail].=
nz</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, May 12, 2000 7:06 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]; [e-mail]; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Border directories</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&quot;Walter Williams&quot; =
&lt;[e-mail]&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--



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA10349 for ietf-smime-bks; Thu, 11 May 2000 19:18:09 -0700 (PDT)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10344 for <[e-mail]>; Thu, 11 May 2000 19:18:07 -0700 (PDT)
Received: from wwilliams4 (wwilliams1.bbn.com [128.33.211.196]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id WAA08227; Thu, 11 May 2000 22:23:57 -0400 (EDT)
From: "Walter Williams" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Border directories
Date: Thu, 11 May 2000 22:14:25 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01BFBB96.441F8C70"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail]
> [mailto:[e-mail]]On Behalf Of Peter Gutmann
> Sent: Friday, May 12, 2000 7:23 AM
> To: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: Border directories
>
>
> "Walter Williams" <[e-mail]> 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:[e-mail]
REV:20000407T003737Z
END:VCARD

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



Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21995 for ietf-smime-bks; Thu, 11 May 2000 12:16:53 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21990 for <[e-mail]>; Thu, 11 May 2000 12:16:50 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id HAA18638; Fri, 12 May 2000 07:22:53 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95807297303945>; Fri, 12 May 2000 07:22:53 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Border directories
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 12 May 2000 07:22:53 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Walter Williams" <[e-mail]> 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.



Received: by ns.secondary.com (8.9.3/8.9.3) id LAA21311 for ietf-smime-bks; Thu, 11 May 2000 11:41:10 -0700 (PDT)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21306 for <[e-mail]>; Thu, 11 May 2000 11:41:05 -0700 (PDT)
Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id OAA13447; Thu, 11 May 2000 14:47:22 -0400 (EDT)
From: "Walter Williams" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Border directories
Date: Thu, 11 May 2000 14:37:50 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]]
> Sent: Friday, May 12, 2000 6:33 AM
> To: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: Border directories
>
>
> "Walter Williams" <[e-mail]> 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.
>



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA21165 for ietf-smime-bks; Thu, 11 May 2000 11:29:45 -0700 (PDT)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21161 for <[e-mail]>; Thu, 11 May 2000 11:29:43 -0700 (PDT)
Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id OAA09379; Thu, 11 May 2000 14:36:01 -0400 (EDT)
From: "Walter Williams" <[e-mail]>
To: <[e-mail]>, "'Laurent Deffranne'" <[e-mail]>
Cc: "'ietf-smime'" <[e-mail]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 14:26:29 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <000301bfbb6c$b7f2ada0$[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail]
> [mailto:[e-mail]]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:[e-mail]]
> 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: [e-mail]
> > [mailto:[e-mail]]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
>
>
>
>
>



Received: by ns.secondary.com (8.9.3/8.9.3) id LAA21095 for ietf-smime-bks; Thu, 11 May 2000 11:26:37 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21087 for <[e-mail]>; Thu, 11 May 2000 11:26:33 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id GAA18072; Fri, 12 May 2000 06:32:36 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95806995603561>; Fri, 12 May 2000 06:32:36 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Border directories
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 12 May 2000 06:32:36 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Walter Williams" <[e-mail]> 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.



Received: by ns.secondary.com (8.9.3/8.9.3) id LAA21055 for ietf-smime-bks; Thu, 11 May 2000 11:24:16 -0700 (PDT)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21051 for <[e-mail]>; Thu, 11 May 2000 11:24:15 -0700 (PDT)
Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id OAA07068; Thu, 11 May 2000 14:29:41 -0400 (EDT)
From: "Walter Williams" <[e-mail]>
To: "Philip Hallam-Baker" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Does Slime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 14:20:09 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Walt

PS: Agree strongly about the security thing!

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Philip Hallam-Baker
> Sent: Thursday, May 11, 2000 12:51 PM
> To: '[e-mail]'; [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> 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
> 


Received: by ns.secondary.com (8.9.3/8.9.3) id LAA21021 for ietf-smime-bks; Thu, 11 May 2000 11:22:28 -0700 (PDT)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21016 for <[e-mail]>; Thu, 11 May 2000 11:22:26 -0700 (PDT)
Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id OAA06614; Thu, 11 May 2000 14:28:37 -0400 (EDT)
From: "Walter Williams" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Border directories
Date: Thu, 11 May 2000 14:19:05 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]]
> Sent: Friday, May 12, 2000 6:06 AM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Border directories
>
>
> "Walter Williams" <[e-mail]> 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.
>



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA20970 for ietf-smime-bks; Thu, 11 May 2000 11:19:33 -0700 (PDT)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20966 for <[e-mail]>; Thu, 11 May 2000 11:19:28 -0700 (PDT)
Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id OAA05456; Thu, 11 May 2000 14:25:18 -0400 (EDT)
From: "Walter Williams" <[e-mail]>
To: "Philip Hallam-Baker" <[e-mail]>, "ietf-smime" <[e-mail]>
Subject: RE: Border directories
Date: Thu, 11 May 2000 14:15:46 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> 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:[e-mail]]
> 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: [e-mail]
> > [mailto:[e-mail]]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 [e-mail] one
> or
> > more digital certificates are returned that provide a binding between
> > the name [e-mail] 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:[e-mail]" or Base64 ( SHA1 ( "mailto:[e-mail]"))
> > (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
> >
>



Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20648 for ietf-smime-bks; Thu, 11 May 2000 11:00:27 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20641 for <[e-mail]>; Thu, 11 May 2000 11:00:17 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id GAA16048; Fri, 12 May 2000 06:06:19 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95806837902272>; Fri, 12 May 2000 06:06:19 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Border directories
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 12 May 2000 06:06:19 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Walter Williams" <[e-mail]> 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.



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA20388 for ietf-smime-bks; Thu, 11 May 2000 10:43:33 -0700 (PDT)
Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20384 for <[e-mail]>; Thu, 11 May 2000 10:43:32 -0700 (PDT)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA16052; Thu, 11 May 2000 10:49:35 -0700 (PDT)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <KJDK62NS>; Thu, 11 May 2000 10:48:36 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Walter Williams'" <[e-mail]>, Philip Hallam-Baker <[e-mail]>, ietf-smime <[e-mail]>
Subject: RE: Border directories
Date: Thu, 11 May 2000 10:48:34 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_003E_01BFBB4F.C00FE1A0"; micalg=SHA1; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
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: [e-mail]
> [mailto:[e-mail]]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 [e-mail] one
or
> more digital certificates are returned that provide a binding between
> the name [e-mail] 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:[e-mail]" or Base64 ( SHA1 ( "mailto:[e-mail]"))
> (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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMTE3NDkzOFowIwYJKoZI
hvcNAQkEMRYEFED2oou8rKfKGUcIObn7Bc0cckvqMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAckMScqqaTEAci8NgcZMCS3dI1yIWeKCQpJvtPEwBzigabYOKG6ueMDXLJKGdBktG
heNVanGreH+XLFl+pjw779Rhy90t/UO4cjxl8QN/ZCuyvIfqEwL42CeVEvvZ9bEFltLzrMZvnv8H
NqlVi67S5hliT9XNPMeVHti6u0l+szEAAAAAAAA=

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



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA20057 for ietf-smime-bks; Thu, 11 May 2000 10:23:19 -0700 (PDT)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20053 for <[e-mail]>; Thu, 11 May 2000 10:23:18 -0700 (PDT)
Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id NAA16267; Thu, 11 May 2000 13:28:50 -0400 (EDT)
From: "Walter Williams" <[e-mail]>
To: "Philip Hallam-Baker" <[e-mail]>, "ietf-smime" <[e-mail]>
Subject: RE: Border directories
Date: Thu, 11 May 2000 13:19:17 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail]
> [mailto:[e-mail]]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 [e-mail] one or
> more digital certificates are returned that provide a binding between
> the name [e-mail] 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:[e-mail]" or Base64 ( SHA1 ( "mailto:[e-mail]"))
> (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
>



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA20013 for ietf-smime-bks; Thu, 11 May 2000 10:19:31 -0700 (PDT)
Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA20009 for <[e-mail]>; Thu, 11 May 2000 10:19:26 -0700 (PDT)
Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Thu, 11 May 00 18:37:34 +0100
X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2
Received: from piers2k (host62-6-125-135.host.btclick.com [62.6.125.135] ) by bjex1.bj.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id K2XJWL09; Thu, 11 May 2000 18:20:55 +0100
Reply-to: [e-mail]
From: "Piers Chivers" <[e-mail]>
To: "'Walter Williams'" <[e-mail]>, "'Dennis Glatting'" <[e-mail]>
cc: "'Laurent Deffranne'" <[e-mail]>, "'ietf-smime'" <[e-mail]>
Subject: RE: Does Slime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 18:26:42 +0100
Message-ID: <000501bfbb6e$141c5120$[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <[e-mail]>
X-WSS-ID: 1504305434501-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail]
[mailto:[e-mail]]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:[e-mail]]
> 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:[e-mail]]
> > > 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:[e-mail]]
> > > > 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: [e-mail]
> > > > > [mailto:[e-mail]]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
>




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA19868 for ietf-smime-bks; Thu, 11 May 2000 10:10:42 -0700 (PDT)
Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19862 for <[e-mail]>; Thu, 11 May 2000 10:10:36 -0700 (PDT)
Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Thu, 11 May 00 18:27:48 +0100
X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2
Received: from piers2k (host62-6-118-201.host.btclick.com [62.6.118.201] ) by bjex1.bj.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id K2XJWL0R; Thu, 11 May 2000 18:11:10 +0100
Reply-to: [e-mail]
From: "Piers Chivers" <[e-mail]>
To: "'Laurent Deffranne'" <[e-mail]>, "'walter.williams'" <[e-mail]>
cc: "'ietf-smime'" <[e-mail]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 18:16:59 +0100
Message-ID: <000301bfbb6c$b7f2ada0$[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <13F9A391AB349012*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=DFFRL/@MHS>
X-WSS-ID: 1504321E34444-01-01
Content-Type: text/plain;  charset=Windows-1252
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
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: [e-mail]
> [mailto:[e-mail]]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







Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA19634 for ietf-smime-bks; Thu, 11 May 2000 09:49:20 -0700 (PDT)
Received: from pigeon.verisign.com ([208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19630 for <[e-mail]>; Thu, 11 May 2000 09:49:19 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id JAA10237; Thu, 11 May 2000 09:50:08 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <KJDM1W38>; Thu, 11 May 2000 09:50:57 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: Does Slime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 09:50:50 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_000B_01BFBB47.B056BD90"; micalg=SHA1; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMTE2NTE1NlowIwYJKoZI
hvcNAQkEMRYEFExpKEwHGPqXRrrA+3U4fjPhKKQ7MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGABdpC8MH1fuq/l5oUTm9ImMzvXrQs9dkS4Wo4TkBQ5s505bpB/iXeOkdIeGbucAEp
BAYXvR3qQOOv9w/XHZAwjibv01nSfhmRJMeY7/NKQu7pwgUd3eMgsic3B1bkiW8QhhanzxU7quin
J8MKyHCo0DimFoj7fUmIfEwD6MyRIdAAAAAAAAA=

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



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA19204 for ietf-smime-bks; Thu, 11 May 2000 09:26:29 -0700 (PDT)
Received: from ponyexpress1.csc.com (ponyexpress1.csc.com [208.219.64.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19200 for <[e-mail]>; Thu, 11 May 2000 09:26:27 -0700 (PDT)
From: [e-mail]
Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress1.csc.com with smtp (Exim 2.12 #1) id 12pvsN-0001wV-00; Thu, 11 May 2000 12:31:51 -0400
Received: by csc.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568DC.005943B0 ; Thu, 11 May 2000 12:15:00 -0400
X-Lotus-FromDomain: CSC
To: [e-mail]
cc: [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 11 May 2000 12:13:17 -0400
Subject: Re: Does Slime works fine with Windows 2000 PKI
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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





[e-mail] on 05/11/2000 10:35:42 AM

To:   [e-mail]
cc:   [e-mail], [e-mail] (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:[e-mail]]
> > 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:[e-mail]]
> > > 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: [e-mail]
> > > > [mailto:[e-mail]]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






Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18905 for ietf-smime-bks; Thu, 11 May 2000 09:13:49 -0700 (PDT)
Received: from lancaster.nexor.co.uk (lancaster.nexor.co.uk [193.63.53.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18900 for <[e-mail]>; Thu, 11 May 2000 09:13:43 -0700 (PDT)
Received: from crusader (actually host crusader.nexor.co.uk) by lancaster.nexor.co.uk with SMTP (Mailer); Thu, 11 May 2000 17:19:35 +0100
Reply-To: "Colin.Robbins" <[e-mail]>
From: Colin Robbins <[e-mail]>
To: "'Philip Hallam-Baker'" <[e-mail]>, "'ietf-smime'" <[e-mail]>
Subject: RE: Border directories
Date: Thu, 11 May 2000 17:19:32 +0100
Message-ID: <003f01bfbb64$b19997a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
> [e-mail] one or
> more digital certificates are returned that provide a binding between
> the name [e-mail] 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:[e-mail]" or Base64 ( SHA1 ( "mailto:[e-mail]"))
> (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
>



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA17745 for ietf-smime-bks; Thu, 11 May 2000 08:11:20 -0700 (PDT)
Received: from brownie.maxware.nl ([212.67.163.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17737 for <[e-mail]>; Thu, 11 May 2000 08:11:17 -0700 (PDT)
X-Internal-ID: 39180590000001B4
Received: from taita (192.168.1.61) by brownie.maxware.nl (NPlex 2.0.108); 11 May 2000 17:13:30 +0200
Message-ID: <01a701bfbb5c$04dc6040$[e-mail]>
From: "Frank W. Nolden" <[e-mail]>
To: "Walter Williams" <[e-mail]>, "Laurent Deffranne" <[e-mail]>
Cc: "ietf-smime" <[e-mail]>
References: <[e-mail]>
Subject: Re: Does Slime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 17:17:27 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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" <[e-mail]>
To: "Laurent Deffranne" <[e-mail]>
Cc: "ietf-smime" <[e-mail]>
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:[e-mail]]
> > 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:[e-mail]]
> > > 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: [e-mail]
> > > > [mailto:[e-mail]]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
> > >
> > >
> > >
> > >
> >
> >
> >
>
>



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA17698 for ietf-smime-bks; Thu, 11 May 2000 08:09:14 -0700 (PDT)
Received: from pigeon.verisign.com ([208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17693 for <[e-mail]>; Thu, 11 May 2000 08:09:12 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id IAA05357; Thu, 11 May 2000 08:12:01 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <KJDM14T0>; Thu, 11 May 2000 08:12:51 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Walter Williams'" <[e-mail]>, Laurent Deffranne <[e-mail]>, ietf-smime <[e-mail]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 08:12:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_000A_01BFBB39.FDB94250"; micalg=SHA1; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMTE1MTM1M1owIwYJKoZI
hvcNAQkEMRYEFOg6u4FNZA4o0f7e4DoZIS8czsH0MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAkCQOdwEGNZVmQXLfORUP7kAVGGvN5TryNfXqpv+fR55SThgha/ZN6BS3GagTM8hc
rtiqMyO/YJVcNkASMQ66Fon2MQF4fkYOYhaU8Gr75QRW9v9etB84U/QK6rNG8BqyxPJliAZ52yD9
pX8QlhPBD8zwp1ZvXpB9h7jXTQ8iIc0AAAAAAAA=

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



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA17678 for ietf-smime-bks; Thu, 11 May 2000 08:08:30 -0700 (PDT)
Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17673 for <[e-mail]>; Thu, 11 May 2000 08:08:28 -0700 (PDT)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id IAA07924 for <[e-mail]>; Thu, 11 May 2000 08:14:30 -0700 (PDT)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <KJDK6FR5>; Thu, 11 May 2000 08:13:31 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: ietf-smime <[e-mail]>
Subject: Border directories
Date: Thu, 11 May 2000 08:13:27 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_000F_01BFBB3A.158A5DB0"; micalg=SHA1; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 [e-mail] one or
more digital certificates are returned that provide a binding between
the name [e-mail] 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:[e-mail]" or Base64 ( SHA1 ( "mailto:[e-mail]"))
(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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxMTE1MTQzM1owIwYJKoZI
hvcNAQkEMRYEFJ2PvJHLjMZfjl374PKiYf6+rN3tMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAMUWm6+gfgepc/CN1iKh6H4fQexvNKiCr8C6OTCd8ZJWKGq3nmf1iGFqw6bEd6M5y
1hhvxIgkDNQvzdJZjNxZixtOqQRUsQj9lkwa86M9pqtd3TV901JMVNJWcclGl4lI7UdryjDWIHF5
C2BCq/jDOZwlM/lVy/7sxg2A0/AGAucAAAAAAAA=

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



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA16953 for ietf-smime-bks; Thu, 11 May 2000 07:42:50 -0700 (PDT)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16949 for <[e-mail]>; Thu, 11 May 2000 07:42:49 -0700 (PDT)
Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id KAA22375; Thu, 11 May 2000 10:48:54 -0400 (EDT)
From: "Walter Williams" <[e-mail]>
To: "Dennis Glatting" <[e-mail]>
Cc: "Laurent Deffranne" <[e-mail]>, "ietf-smime" <[e-mail]>
Subject: RE: Does Slime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 10:39:21 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> 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:[e-mail]]
> > > 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:[e-mail]]
> > > > 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: [e-mail]
> > > > > [mailto:[e-mail]]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
>



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA16764 for ietf-smime-bks; Thu, 11 May 2000 07:30:57 -0700 (PDT)
Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16758 for <[e-mail]>; Thu, 11 May 2000 07:30:56 -0700 (PDT)
Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.10.1/8.10.1) with ESMTP id e4BEZgP23734; Thu, 11 May 2000 07:35:42 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 11 May 2000 07:35:42 -0700
From: Dennis Glatting <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Walter Williams <[e-mail]>
CC: Laurent Deffranne <[e-mail]>, ietf-smime <[e-mail]>
Subject: Re: Does Slime works fine with Windows 2000 PKI
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> > 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:[e-mail]]
> > > 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: [e-mail]
> > > > [mailto:[e-mail]]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


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA16388 for ietf-smime-bks; Thu, 11 May 2000 07:00:26 -0700 (PDT)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16384 for <[e-mail]>; Thu, 11 May 2000 07:00:25 -0700 (PDT)
Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id KAA06872; Thu, 11 May 2000 10:06:43 -0400 (EDT)
From: "Walter Williams" <[e-mail]>
To: "Laurent Deffranne" <[e-mail]>
Cc: "ietf-smime" <[e-mail]>
Subject: RE: Does Slime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 09:57:09 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <15306391ABA25043*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=DFFRL/@MHS>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> 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:[e-mail]]
> > 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: [e-mail]
> > > [mailto:[e-mail]]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
> >
> >
> >
> >
>
>
>



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA16171 for ietf-smime-bks; Thu, 11 May 2000 06:44:34 -0700 (PDT)
Received: from spdl113_tr0.dexia.be (hstcentd.dexia.be [193.91.97.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16167 for <[e-mail]>; Thu, 11 May 2000 06:44:32 -0700 (PDT)
Date: 11 May 2000 15:48:21 +0200
From: Laurent Deffranne <[e-mail]>
To: "walter.williams" <[e-mail]>
cc: ietf-smime <[e-mail]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Message-Id: <15306391ABA25043*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=DFFRL/@MHS>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> 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: [e-mail]
> > [mailto:[e-mail]]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
>
>
>
>





Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA15961 for ietf-smime-bks; Thu, 11 May 2000 06:30:04 -0700 (PDT)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15957 for <[e-mail]>; Thu, 11 May 2000 06:30:03 -0700 (PDT)
Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id JAA25422; Thu, 11 May 2000 09:36:18 -0400 (EDT)
From: "Walter Williams" <[e-mail]>
To: "Laurent Deffranne" <[e-mail]>
Cc: "ietf-smime" <[e-mail]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 09:26:44 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <13F9A391AB349012*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=DFFRL/@MHS>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

> -----Original Message-----
> From: Laurent Deffranne [mailto:[e-mail]]
> 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: [e-mail]
> > [mailto:[e-mail]]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
>
>
>
>



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA15752 for ietf-smime-bks; Thu, 11 May 2000 06:15:59 -0700 (PDT)
Received: from spdl113_tr0.dexia.be (hstcentd.dexia.be [193.91.97.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15748 for <[e-mail]>; Thu, 11 May 2000 06:15:57 -0700 (PDT)
Date: 11 May 2000 15:19:05 +0200
From: Laurent Deffranne <[e-mail]>
To: "walter.williams" <[e-mail]>
cc: ietf-smime <[e-mail]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Message-Id: <13F9A391AB349012*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=DFFRL/@MHS>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="PART.BOUNDARY.spdl113.58e8.391ab34c.0001"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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: [e-mail]
> [mailto:[e-mail]]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:[e-mail]
REV:20000407T003737Z
END:VCARD

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


Received: by ns.secondary.com (8.9.3/8.9.3) id FAA15143 for ietf-smime-bks; Thu, 11 May 2000 05:47:57 -0700 (PDT)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA15139 for <[e-mail]>; Thu, 11 May 2000 05:47:52 -0700 (PDT)
Received: from wwilliams4 ([171.78.1.13]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id IAA12142; Thu, 11 May 2000 08:54:05 -0400 (EDT)
From: "Walter Williams" <[e-mail]>
To: "Laurent Deffranne" <[e-mail]>, "ietf-smime" <[e-mail]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Thu, 11 May 2000 08:44:32 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01BFBB25.20A8F130"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <0D29A391A8105001*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=DFFRL/@MHS>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail]
> [mailto:[e-mail]]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:[e-mail]
REV:20000407T003737Z
END:VCARD

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



Received: by ns.secondary.com (8.9.3/8.9.3) id CAA06349 for ietf-smime-bks; Thu, 11 May 2000 02:41:38 -0700 (PDT)
Received: from spdl113_tr0.dexia.be (hstcentd.dexia.be [193.91.97.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA06343 for <[e-mail]>; Thu, 11 May 2000 02:41:36 -0700 (PDT)
Date: 11 May 2000 11:44:37 +0200
From: Laurent Deffranne <[e-mail]>
To: ietf-smime <[e-mail]>
Subject: Does Smime works fine with Windows 2000 PKI
Message-Id: <0D29A391A8105001*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=DFFRL/@MHS>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23618 for ietf-smime-bks; Tue, 9 May 2000 10:41:42 -0700 (PDT)
Received: from scooby.lineone.net ([194.75.152.224]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23520; Tue, 9 May 2000 10:39:22 -0700 (PDT)
Received: from ukd ([195.171.177.9]) by scooby.lineone.net (8.9.3/8.9.3) with SMTP id QAA21977; Tue, 9 May 2000 16:27:42 +0100 (BST)
Message-ID: <013c01bfb9cc$8f482480$09b1abc3@ukd>
From: "Charlie Fletcher - www.ukdata.com" <[e-mail]>
To: "Finance Director" <[e-mail]>
Subject: Instant On-Line Credit Reports
Date: Tue, 9 May 2000 16:34:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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













Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA21143 for ietf-smime-bks; Tue, 9 May 2000 08:40:55 -0700 (PDT)
Received: from hal9000.vguard.com (vguard.com [192.117.162.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21136 for <[e-mail]>; Tue, 9 May 2000 08:40:51 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from MGM (DEMONA [192.117.162.76]) by hal9000.vguard.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KQR623MB; Tue, 9 May 2000 18:46:06 +0200
X-MG-RegisteredMail: ReturnReceipt
From: Raviv Karnieli<[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: S/MIME IDEA Draft
Date: Tue, 09 MAY 2000 16:44:00 -0000 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="<<-- MailGuardian RTF boundary -->>"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

UnVzcywNCg0KVGhlIG5vdGUgZnJlZXMgb25seSB0aGUgbm9uIGNvbW1lcmNpYWwgdXNlIG9m
IHRoaXMgYWxnb3JpdGhtLiBJIGJlbGlldmUgbW9zdCBvZiB0aGUgaW1wbGVtZW50YXRpb25z
IG9mIFMvTUlNRXYzIHdpbGwgYmUgY29tbWVyY2lhbCBwcm9kdWN0cyBvciBzeXN0ZW1zIGZv
ciBjb21tZXJjaWFsIHVzZSBzbyB0aGlzIG5vdGUgZG9lcyBub3QgcmVsYXRlIHRvIHRoZW0u
IElzIGl0IHNvPw0KDQpSYXZpdiBLYXJuaWVsaSAtIENUTw0KVmFuZ3VhcmQgU2VjdXJpdHkg
VGVjaG5vbG9naWVzIEx0ZC4NClRlbC4gKzk3Mi00LTk4OS0xMzExICAgICAgIEZheCArOTcy
LTQtOTg5LTEzMjINCnd3dy52Z3VhcmQuY29tICAgICAgICAgICAgIHJhdml2QHZndWFyZC5j
b20NCg0KVGhpcyBtZXNzYWdlIGxlZnQgbXkgY29tcHV0ZXIgc2VjdXJlZCBzaW5jZSBJkm0g
dXNpbmcgDQpNQUlMZ3VhcmRpYW4gRW50ZXJwcmlzZSB0aGUgZmlyc3QgdHJ1ZSBlbmQgdG8g
ZW5kIGVudGVycHJpc2UgZS1tYWlsIHNlY3VyaXR5IHNvbHV0aW9uIHRoYXQgaXMgcG9saWN5
IGJhc2VkLCBjZW50cmFsbHkgbWFuYWdlZCBhbmQgdG90YWxseSB0cmFuc3BhcmVudCB0byB0
aGUgZW5kIHVzZXJzLg0KDQpZb3UgY2FuIGdldCB5b3VyIG93biBmcmVlIGV2YWx1YXRpb24g
Y29weSBvZiBNQUlMZ3VhcmRpYW4gDQphdCBodHRwOi8vd3d3LnZndWFyZC5jb20vcHJvZC5h
c3ANCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSdXNzIEhvdXNsZXkgW21h
aWx0bzpob3VzbGV5QHNweXJ1cy5jb21dDQpTZW50OiBNb25kYXksIE1heSAwOCwgMjAwMCAz
OjM3IFBNDQpUbzogaWV0Zi1zbWltZUBpbWMub3JnDQpTdWJqZWN0OiBTL01JTUUgSURFQSBE
cmFmdA0KDQoNCkkgaGF2ZSBqdXN0IGJlZW4gbWFkZSBhd2FyZSB0aGF0IHRoZSBJREVBIGVu
Y3J5cHRpb24gYWxnb3JpdGhtIGhhcyBiZWVuIA0KcG9zdGVkIG9uIHRoZSAiSUVURiBQYWdl
IG9mIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgTm90aWNlcyIgd2ViIHNpdGU6DQoJ
aHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmL0lQUi9BU0NPTS1JREVBDQoNCkFsc28sIFN0ZXBo
YW4gdGVsbHMgbWUgdGhhdCBhIG5ldyBJbnRlcm5ldC1EcmFmdCB3aWxsIGJlIHBvc3RlZCBp
biB0aGUgbmV4dCANCmZldyBkYXlzLiAgT25jZSBpdCBpcyBwb3N0ZWQsIEkgd2lsbCBiZSBj
YWxsaW5nIGZvciBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCANCm9uIHRoaXMgZG9jdW1lbnQu
DQoNCkJ5IHRoZSB3YXksIEkgaGF2ZSBhc2tlZCB0aGUgYXV0aG9ycyB0byBjaGFuZ2UgdGhl
IHRpdGxlLiAgVGhlIG5ldyB0aXRsZSANCndpbGwgYmU6DQoJVXNlIG9mIHRoZSBJREVBIEVu
Y3J5cHRpb24gQWxnb3JpdGhtIGluIENNUw0KDQpSdXNz
--<<-- MailGuardian RTF boundary -->>
Content-Type: application/X-MAILguardian-rtf; charset="ISO-8859-8"
Content-Transfer-Encoding: base64

DQp7XHJ0ZjFcYW5zaVxhbnNpY3Bn
MTI1Mlxmcm9tdGV4dCBcZGVmZjB7XGZvbnR0YmwNCntcZjBcZnN3aXNzXGZjaGFyc2V0MCBB
cmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmllciBOZXc7fQ0Ke1xmMlxmbmlsXGZjaGFyc2V0
MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5ldzt9fQ0Ke1xj
b2xvcnRibFxyZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdWMx
XHBhcmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwIFJ1c3MsXHBhcg0KXHBhcg0KVGhlIG5v
dGUgZnJlZXMgb25seSB0aGUgbm9uIGNvbW1lcmNpYWwgdXNlIG9mIHRoaXMgYWxnb3JpdGht
LiBJIGJlbGlldmUgbW9zdCBvZiB0aGUgaW1wbGVtZW50YXRpb25zIG9mIFMvTUlNRXYzIHdp
bGwgYmUgY29tbWVyY2lhbCBwcm9kdWN0cyBvciBzeXN0ZW1zIGZvciBjb21tZXJjaWFsIHVz
ZSBzbyB0aGlzIG5vdGUgZG9lcyBub3QgcmVsYXRlIHRvIHRoZW0uIElzIGl0IHNvP1xwYXIN
ClxwYXINClJhdml2IEthcm5pZWxpIC0gQ1RPXHBhcg0KVmFuZ3VhcmQgU2VjdXJpdHkgVGVj
aG5vbG9naWVzIEx0ZC5ccGFyDQpUZWwuICs5NzItNC05ODktMTMxMSAgICAgICBGYXggKzk3
Mi00LTk4OS0xMzIyXHBhcg0Kd3d3LnZndWFyZC5jb20gICAgICAgICAgICAgcmF2aXZAdmd1
YXJkLmNvbVxwYXINClxwYXINClRoaXMgbWVzc2FnZSBsZWZ0IG15IGNvbXB1dGVyIHNlY3Vy
ZWQgc2luY2UgSVwnOTJtIHVzaW5nIFxwYXINCk1BSUxndWFyZGlhbiBFbnRlcnByaXNlIHRo
ZSBmaXJzdCB0cnVlIGVuZCB0byBlbmQgZW50ZXJwcmlzZSBlLW1haWwgc2VjdXJpdHkgc29s
dXRpb24gdGhhdCBpcyBwb2xpY3kgYmFzZWQsIGNlbnRyYWxseSBtYW5hZ2VkIGFuZCB0b3Rh
bGx5IHRyYW5zcGFyZW50IHRvIHRoZSBlbmQgdXNlcnMuXHBhcg0KXHBhcg0KWW91IGNhbiBn
ZXQgeW91ciBvd24gZnJlZSBldmFsdWF0aW9uIGNvcHkgb2YgTUFJTGd1YXJkaWFuIFxwYXIN
CmF0IGh0dHA6Ly93d3cudmd1YXJkLmNvbS9wcm9kLmFzcFxwYXINCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tXHBhcg0KRnJvbTogUnVzcyBIb3VzbGV5IFttYWlsdG86aG91c2xleUBz
cHlydXMuY29tXVxwYXINClNlbnQ6IE1vbmRheSwgTWF5IDA4LCAyMDAwIDM6MzcgUE1ccGFy
DQpUbzogaWV0Zi1zbWltZUBpbWMub3JnXHBhcg0KU3ViamVjdDogUy9NSU1FIElERUEgRHJh
ZnRccGFyDQpccGFyDQpccGFyDQpJIGhhdmUganVzdCBiZWVuIG1hZGUgYXdhcmUgdGhhdCB0
aGUgSURFQSBlbmNyeXB0aW9uIGFsZ29yaXRobSBoYXMgYmVlbiBccGFyDQpwb3N0ZWQgb24g
dGhlICJJRVRGIFBhZ2Ugb2YgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBOb3RpY2Vz
IiB3ZWIgc2l0ZTpccGFyDQpcdGFiIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi9JUFIvQVND
T00tSURFQVxwYXINClxwYXINCkFsc28sIFN0ZXBoYW4gdGVsbHMgbWUgdGhhdCBhIG5ldyBJ
bnRlcm5ldC1EcmFmdCB3aWxsIGJlIHBvc3RlZCBpbiB0aGUgbmV4dCBccGFyDQpmZXcgZGF5
cy4gIE9uY2UgaXQgaXMgcG9zdGVkLCBJIHdpbGwgYmUgY2FsbGluZyBmb3IgV29ya2luZyBH
cm91cCBMYXN0IENhbGwgXHBhcg0Kb24gdGhpcyBkb2N1bWVudC5ccGFyDQpccGFyDQpCeSB0
aGUgd2F5LCBJIGhhdmUgYXNrZWQgdGhlIGF1dGhvcnMgdG8gY2hhbmdlIHRoZSB0aXRsZS4g
IFRoZSBuZXcgdGl0bGUgXHBhcg0Kd2lsbCBiZTpccGFyDQpcdGFiIFVzZSBvZiB0aGUgSURF
QSBFbmNyeXB0aW9uIEFsZ29yaXRobSBpbiBDTVNccGFyDQpccGFyDQpSdXNzXHBhcg0KfQ0K

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



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA18213 for ietf-smime-bks; Tue, 9 May 2000 06:05:48 -0700 (PDT)
Received: from sentry.gw.tislabs.com ([e-mail] [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18209 for <[e-mail]>; Tue, 9 May 2000 06:05:47 -0700 (PDT)
Received: by sentry.gw.tislabs.com; id JAA10358; Tue, 9 May 2000 09:13:30 -0400 (EDT)
Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma010342; Tue, 9 May 00 09:12:55 -0400
Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id JAA17816 for [e-mail]; Tue, 9 May 2000 09:06:12 -0400 (EDT)
Date: Tue, 9 May 2000 09:06:12 -0400 (EDT)
From: "David M. Balenson" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: CFP: ISOC Netw & Distr Sys Security Symp (NDSS'01)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

            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



Received: by ns.secondary.com (8.9.3/8.9.3) id DAA14101 for ietf-smime-bks; Tue, 9 May 2000 03:30:50 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA14097 for <[e-mail]>; Tue, 9 May 2000 03:30:48 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13950; Tue, 9 May 2000 06:36:41 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cmskea-05.txt
Date: Tue, 09 May 2000 06:36:40 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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 [e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA22990 for ietf-smime-bks; Mon, 8 May 2000 13:46:11 -0700 (PDT)
Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22986 for <[e-mail]>; Mon, 8 May 2000 13:46:09 -0700 (PDT)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <GFRJP7A6>; Mon, 8 May 2000 16:51:27 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: Final 29 March 2000 S/MIME WG Minutes
Date: Mon, 8 May 2000 16:51:27 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <[e-mail]>

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

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 [e-mail].  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 
<[e-mail]>.  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.


Received: by ns.secondary.com (8.9.3/8.9.3) id HAA16854 for ietf-smime-bks; Mon, 8 May 2000 07:34:49 -0700 (PDT)
Received: from fanniemae.com (ns1.fanniemae.com [198.204.134.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16850 for <[e-mail]>; Mon, 8 May 2000 07:34:46 -0700 (PDT)
Received: from psysadm-fw01bx.fanniemae.com (fw01b [198.204.133.71]) by fanniemae.com (8.9.1a/8.9.1) with SMTP id KAA04192 for <[e-mail]>; Mon, 8 May 2000 10:40:03 -0400 (EDT)
Received: from [158.137.199.163] by psysadm-fw01bx.fanniemae.com via smtpd (for [198.204.133.67]) with SMTP; 8 May 2000 14:40:02 UT
Received: from 158.137.199.160 by fm-mailfw1.fanniemae.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Mon, 08 May 00 10:39:17 -0400
X-Server-Uuid: 988a06f2-702d-11d2-9ff4-0008c7a4c0f1
Received: from psysadm-em01.fanniemae.com by fanniemae.com ( SMI-8.6/SMI-SVR4) id KAA29100; Mon, 8 May 2000 10:40:00 -0400
Received: from fanniemae.com ([172.25.67.245]) by psysadm-em01.fanniemae.com (Netscape Messaging Server 4.05) with ESMTP id FU8WQO00.SDO for <[e-mail]>; Mon, 8 May 2000 10:40:00 -0400
Message-ID: <[e-mail]>
Date: Mon, 08 May 2000 10:38:31 -0400
From: "Nida Sun" <[e-mail]>
Organization: Fannie Mae
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: <[e-mail]>
Subject: Delete
References: <[e-mail]>
X-WSS-ID: 15080E1F47735-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: by ns.secondary.com (8.9.3/8.9.3) id GAA16018 for ietf-smime-bks; Mon, 8 May 2000 06:32:02 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16009 for <[e-mail]>; Mon, 8 May 2000 06:31:59 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com.au ([209.172.119.206]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA06309 for <[e-mail]>; Mon, 8 May 2000 06:37:16 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 08 May 2000 09:36:38 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: S/MIME IDEA Draft
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: by ns.secondary.com (8.9.3/8.9.3) id LAA07066 for ietf-smime-bks; Sun, 7 May 2000 11:59:40 -0700 (PDT)
Received: from flamingo.mkpi.co.id ([202.155.24.179]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07062 for <[e-mail]>; Sun, 7 May 2000 11:59:36 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from kllklk (01-033.044.popsite.net [216.126.163.33]) by flamingo.mkpi.co.id with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id KFTDJL81; Mon, 8 May 2000 02:08:37 +0700
From: "Tony Meyer" <[e-mail]>
Subject: Its A New World  A New Economy
To: new39s
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date: Sun, 07 May 2000 13:32:39 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA07063
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]?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:[e-mail]?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. 







Received: by ns.secondary.com (8.9.3/8.9.3) id OAA12009 for ietf-smime-bks; Sat, 6 May 2000 14:27:41 -0700 (PDT)
Received: from odin.kubtelecom.ru ([213.132.64.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA12005 for <[e-mail]>; Sat, 6 May 2000 14:27:40 -0700 (PDT)
Received: from kllklk (01-033.044.popsite.net [216.126.163.33]) by odin.kubtelecom.ru (8.9.3/8.9.3/relay.domain) with ESMTP id BAA97867; Sun, 7 May 2000 01:33:01 +0400 (MSD)
Message-Id: <[e-mail]>
From: "Rene Brir" <[e-mail]>
Subject: You Can Win
To: [e-mail]
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date: Sat, 06 May 2000 16:49:56 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA12006
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 
Are you interested in increasing your odds in
winning a lottery?  To find out how, reply to:
mailto:[e-mail]?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:[e-mail]?subject=remove






Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15692 for ietf-smime-bks; Wed, 3 May 2000 15:53:03 -0700 (PDT)
Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15683 for <[e-mail]>; Wed, 3 May 2000 15:53:01 -0700 (PDT)
From: [e-mail]
Received: from tot-tj.proxy.aol.com (tot-tj.proxy.aol.com [152.163.213.131]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id QAA22423 for <[e-mail]>; Wed, 3 May 2000 16:52:35 -0400 (EDT)
Received: from client (98A876B0.ipt.aol.com [152.168.118.176]) by tot-tj.proxy.aol.com (8.10.0/8.10.0) with SMTP id e43KqXu19290 for [e-mail]; Wed, 3 May 2000 16:52:33 -0400 (EDT)
Date: Wed, 3 May 2000 16:52:33 -0400 (EDT)
Message-Id: <[e-mail]>
To: <[e-mail]>
Subject: 50 Megs of web space for $9.95 a month!
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 
[e-mail] with the header of Delete