Re: Comments on SecLabel draft

[Nicolls <[e-mail]>]

Jim

Thanks for your comments and questions. My responses are below >>

Jim Schaad wrote:

> SecLabel
>
> 1.  Section 1 P2 - Security labels cannot be bound to an encrypted body, only
> to a signed message.

> >> Yes.  Will reword to state that they may be included in the signed attributes
> of any
>    SignedData object.

> 2.  Please give more text explaining the difference between rank and role based
> security.  From the current description they look like the same to me.

> >> Yes, more explaination is needed.  The main different is that rank based AC is
> hierarchical while role based is not necessarily (which isnt what I wrote).
> Roles can be defined without regard to a hierarchy.  Better examples of roles
> such as  DB Administrator or Network Admin and Shipper Purchaser, which do not
> imply a hierarchy but can have their own set of information that only holders of
> that role may have access.  Another way of explaining the difference can be that
> Rank based AC is based on who you are while Role based AC is based on what you
> do.

> 3.  The Amoco policy description is not clear.  From the text I assumed that
> the confidentiality and integrity were orthogonal axis for make decisions (thus
> leading to 9 items).  Based on the conversation with you this is not true as
> the policy is choose one of the axis and then the point on the axis.  The text
> should be clarified as to which is correct.

> >> Yes, the confidentiality and integrity polices are independent so either or
> both may be chosen.  I'll add wording to 2.1.1.  I think it is also appropriate
> to remove the integrity policy values from the security classification section
> (2.2.1.2) and clearance section (2.2.2).  Integrity does not effect access
> control.  It belongs in the privacy mark section, if anywhere.

> 4. Typo - Section 1.2 last para - "while he outer signature" should be "while
> the".

>>  Yes.

> 5.  Section 2.2.1.3 -- I don't think that one should provide a syntax for the
> privacy marks.  However giving a couple of the privacy marks or guidelines from
> the policy on writting them might be useful.  Given that a privacy mark is a
> UTF8 string in the syntax, no addtional ASN syntax is really possible.

> >> Agree. Will see about on examples or guidelines.
>
> 6.  You say that categories are used informally, however without knowning how
> they would be used or specified I cannot even hope to offer syntax suggestions.
>  Given that they are informal why would they not be marked as privacy labels.
>  If they are categories then I would expect the policy module to do enforcement
> thus being informal would cause some difficulties.

>>  I meant that categories are not formally defined in the information security
policies but are used in the organization.  Project or organizations do define
their own category to limit access to data to members of an organization or a
project.  Once defined, then they are formal and are to be enforced

>> So the owner of the classification policy allows departments to define security
categories that are bound to the classification policy. A category "HR Department"
could be defined under the Company ABC classification policy OID and
CompanyABC-SecurityCategory (1) could become "HR Department Only".  Then
CompanyABC-Project NextGreatestWasher could become bound to category (2) and so
on.  The hard part being how the application knows what categories are being used
and what to display to the user.

>> As far as a syntax, would a new OID need to be defined for each category?  Does
the syntax just need to provide the application with the text to display to the
user?

> 7.  I suggest that you name Clearance in the ASN sections to be XxxxSection.
> a nd the same for the other top level items.
>

>> Will fix numbering for section 2.2.2.

>> Weston





Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA05317 for ietf-smime-bks; Mon, 17 Apr 2000 20:40:30 -0700 (PDT)
Received: from zeus.anet-chi.com ([e-mail] [207.7.4.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA05312 for <[e-mail]>; Mon, 17 Apr 2000 20:40:29 -0700 (PDT)
Received: from anet.com (as1-96.chi.il.dial.anet.com [198.92.156.96]) by zeus.anet-chi.com (8.9.3/spamfix) with ESMTP id WAA23936; Mon, 17 Apr 2000 22:44:20 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Mon, 17 Apr 2000 22:42:52 -0500
From: Nicolls <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Comments on SecLabel draft
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>

Jim

Thanks for your comments and questions. My responses are below >>

Jim Schaad wrote:

> SecLabel
>
> 1.  Section 1 P2 - Security labels cannot be bound to an encrypted body, only
> to a signed message.

> >> Yes.  Will reword to state that they may be included in the signed attributes
> of any
>    SignedData object.

> 2.  Please give more text explaining the difference between rank and role based
> security.  From the current description they look like the same to me.

> >> Yes, more explaination is needed.  The main different is that rank based AC is
> hierarchical while role based is not necessarily (which isnt what I wrote).
> Roles can be defined without regard to a hierarchy.  Better examples of roles
> such as  DB Administrator or Network Admin and Shipper Purchaser, which do not
> imply a hierarchy but can have their own set of information that only holders of
> that role may have access.  Another way of explaining the difference can be that
> Rank based AC is based on who you are while Role based AC is based on what you
> do.

> 3.  The Amoco policy description is not clear.  From the text I assumed that
> the confidentiality and integrity were orthogonal axis for make decisions (thus
> leading to 9 items).  Based on the conversation with you this is not true as
> the policy is choose one of the axis and then the point on the axis.  The text
> should be clarified as to which is correct.

> >> Yes, the confidentiality and integrity polices are independent so either or
> both may be chosen.  I'll add wording to 2.1.1.  I think it is also appropriate
> to remove the integrity policy values from the security classification section
> (2.2.1.2) and clearance section (2.2.2).  Integrity does not effect access
> control.  It belongs in the privacy mark section, if anywhere.

> 4. Typo - Section 1.2 last para - "while he outer signature" should be "while
> the".

>>  Yes.

> 5.  Section 2.2.1.3 -- I don't think that one should provide a syntax for the
> privacy marks.  However giving a couple of the privacy marks or guidelines from
> the policy on writting them might be useful.  Given that a privacy mark is a
> UTF8 string in the syntax, no addtional ASN syntax is really possible.

> >> Agree. Will see about on examples or guidelines.
>
> 6.  You say that categories are used informally, however without knowning how
> they would be used or specified I cannot even hope to offer syntax suggestions.
>  Given that they are informal why would they not be marked as privacy labels.
>  If they are categories then I would expect the policy module to do enforcement
> thus being informal would cause some difficulties.

>>  I meant that categories are not formally defined in the information security
policies but are used in the organization.  Project or organizations do define
their own category to limit access to data to members of an organization or a
project.  Once defined, then they are formal and are to be enforced

>> So the owner of the classification policy allows departments to define security
categories that are bound to the classification policy. A category "HR Department"
could be defined under the Company ABC classification policy OID and
CompanyABC-SecurityCategory (1) could become "HR Department Only".  Then
CompanyABC-Project NextGreatestWasher could become bound to category (2) and so
on.  The hard part being how the application knows what categories are being used
and what to display to the user.

>> As far as a syntax, would a new OID need to be defined for each category?  Does
the syntax just need to provide the application with the text to display to the
user?

> 7.  I suggest that you name Clearance in the ASN sections to be XxxxSection.
> a nd the same for the other top level items.
>

>> Will fix numbering for section 2.2.2.

>> Weston




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA02965 for ietf-smime-bks; Mon, 17 Apr 2000 07:45:57 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02959 for <[e-mail]>; Mon, 17 Apr 2000 07:45:52 -0700 (PDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id QAA24956; Mon, 17 Apr 2000 16:45:37 +0200 (MET DST)
Received: from ericsson.com by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA09597; Mon, 17 Apr 2000 16:45:35 +0200
Message-ID: <[e-mail]>
Date: Mon, 17 Apr 2000 16:46:31 +0200
From: Luis Barriga <[e-mail]>
Reply-To: [e-mail]
Organization: Ericsson Radio Systems
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IETF SMIME List <[e-mail]>
CC: William Ottaway <[e-mail]>
Subject: Re: Domain-to-point security services & DOMSEC
References: <000601bfa5fd$636f2300$[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>

Bill,

DOMSEC covers partially the requirements I described. Below, I explain
why and at the end I list where DOMSEC should be updated to fully
address all requirements.

DOMSEC addresses the case when an individual encrypts for a recipient's
domain and the DCA decrypts. I call this case point2domain requirement.
What I think is missing is the domain2point requirement. In this case
the domain Company.Com needs to send secure mail to one of its members
[e-mail], who is on the Internet reachable as [e-mail]. Note that
ISP.Com is considered an unstrusted domain from the Company's
perspective.

The DOMSEC draft has a very generic phrase "Messages may be encrypted
for decryption by the final recipient and/or by a DCA in the recipient's
domain". This seems to cover both point2domain and domain2point, but it
actually handles in detail only point2domain.

What I would like to see an explicit domain2point requirement, with a
more clear description how this is achieved. What I'm aiming at is that
the email from an intranet user [e-mail] would be encrypted by
the DCA for a recipient [e-mail] on behalf of the sender *using the
recipient's [e-mail] cert*. Optionally the DCA would put a domain
signature. The resulting SMIME object would then be sent to [e-mail]. A
mismatch between [e-mail] and [e-mail] has to be solved.

The following sections should be extended:

o Abstract
 - focuses on domain interoperation. Should consider domain2point.

1. Introduction
 - there are 4 issues named and the 3rd one is about PKI deployment
issues for certification paths between organizations. The domain2point
requirement is not named. The issue here is that the sender on the
Intranet can't PKI/SMIME or there is a security policy restricting it.

2.4 Domain Encryption and Decryption
  - The definition of domain encryption excludes the domain2point case,
because it assumes a domain2domain or point2domain scenario. Domain
encryption should be defined to also include the case of encryption on
behalf of a sender *using the recipient's cert*.

4. Encryption and Decryption
  - still focused on point2domain. Should consider domain2point.

4.2 Key Management for Domain Encryption
  - The key used here is a domain key which is ok for point2domain. This
section should also consider domain2point where the encryption key is
the recipient's key.

4.3. Key Management for Domain Decryption
  - This section has been written to complete 4.2. A small caveat should
probably be needed to say that no domain decryption applies for
domain2point.

--------
Luis Barriga
Ericsson Reseach
         
William Ottaway wrote:
> 
> Hi Luis,
> 
> I believe the scenario you describe is handled in a DOMSEC environment. In
> fact this is exactly the type of scenario that drove us to produce the
> DOMSEC ID.
> 
> Section 4 of DOMSEC describes a domain and/or an individual being able to
> encrypt for a recipient or the recipient's domain (DCA - Domain
> Confidentiality Authority): -
> 
> "Messages may be encrypted for decryption by the final recipient and/or by a
> DCA in the recipient's domain."
> 
> In your scenario the originator would send a message to the intended
> recipient as usual but the originator or the originator's domain encrypts
> the message so that the recipients domain (DCA) can decrypt it.  We think
> this is covered by section 4:
> 
> * Section 4.1 describes a naming convention that must be followed so that
> the certificate for the recipient's domain can be identified.
> 
> * Section 4.3 describes how a DCA decrypts a message that has been encrypted
> by an originator and/or an originator's domain.
> 
> After re-reading this section we have changed it slightly to aid clarity,
> and (hopefully!) to make it more clear that we are covering the scenario you
> describe:
> 
> -- Begin new section 4.3
> 
> "4.3 Key Management for Domain Decryption
> 
> Domain decryption uses a domain-wide decryption key from the recipient's
> domain. This key is owned by the DCA for the recipient domain. In order for
> an encrypting process to locate the correct key, the certificate
> corresponding to the DCA in the recipient's domain must be located. This is
> achieved using the naming conventions specified in 4.1. It is vital that
> these conventions are adhered to, in order to maintain confidentiality.
> 
> It should be noted that domain decryption can be performed on messages
> encrypted by the originator and/or by a DCA in the originator's domain.
> In the first case, the encryption process is described in CMS [5]; in the
> second case, the encryption process is described in 4.2.
> 
> No specific method for locating this certificate is mandated in this
> document. An implementation may choose to access a local certificate store
> to locate the correct certificate. Alternatively, a directory may be used in
> one of the following ways:
> 
> 1. The directory may store the DCA certificate in the recipient's directory
> entry. When the user certificate attribute is requested, this certificate is
> returned.
> 
> 2. The encrypting agent maps the recipient's name to the DCA name in the
> manner specified in 4.1. The user certificate attribute associated with this
> directory entry is then obtained.
> 
> This document does not mandate either of these processes. Whichever one is
> used, the name mapping conventions must be adhered to, in order to maintain
> confidentiality.
> 
> Having located the correct certificate, the encryption process is then
> performed. A recipientInfo for the DCA is then generated, as described in
> CMS [5]."
> 
> -- End new section 4.3
> 
> We see DOMSEC as a means of describing the building blocks required to
> provide secure messaging between individuals and domains using S/MIME. How
> these blocks are integrated into real systems is very much a policy matter
> and consequently we do not go into this realm within DOMSEC.
> 
> To summarise, we believe your scenario is covered by DOMSEC. Do you agree?
> Is further clarification needed? If so where?
> 
> Bill.
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Luis Barriga
> > Sent: 11 April 2000 15:16
> > To: IETF SMIME List
> > Subject: Domain-to-point security services & DOMSEC
> >
> >
> > I have a common scenario that I believe should be addressed within this
> > group. I'll refer to it as domain-to-point secure messaging and it looks
> > as follows:
> >
> > A user [e-mail] wishes to communicate *securely* with a another user
> > [e-mail]. The user [e-mail] doesn't have a cert (or if he does
> > [e-mail] doesn't know it). I see this as a common case, when companies
> > start migrating to PKI and:
> >
> > (1) [e-mail] is actually a user [e-mail], who has temporarily left
> > his corporate premises and has a public email account at an POP/IMAP
> > service provider. A wants to exchange email securely with colleagues at
> > the Company, but not all of them have certs.
> >
> > (2) [e-mail] is an external user with no association with
> > Corporate.Com, but who wants to send important secure email to
> > [e-mail]. [e-mail] can't access the Company's PKI.
> >
> > To solve this, the Company can deploy a domain securiy service, sort of
> > S/MIME proxy with public cert associated with [e-mail].
> > The user [e-mail] (the point) could then send S/MIME to this proxy (the
> > domain) with request to forward the email to the end user [e-mail].
> > If A also has a cert, then B can reply securely directly or via the
> > S/MIME proxy, provided that the proxy has access to the A's PKI
> > (Company.Com or ISP.com).
> >
> > BTW, this scheme also allows users to store corporate email on
> > unstrusted public POP/IMAP services providers. It can also be used for
> > secure mailing lists and cert distribution.
> >
> > My question to You folks is:
> >
> > 1. Is there enough interest out there to work towards a draft?
> >
> > 2. It seems that this falls within the DOMSEC draft, but the scenario
> > above is not explicitly addressed. Any opinion on this?
> >
> > 3. Anybody else done something similar?
> >
> > ------
> > Luis Barriga
> > Ericsson Research
> >


Received: by ns.secondary.com (8.9.3/8.9.3) id VAA19811 for ietf-smime-bks; Sun, 16 Apr 2000 21:14:37 -0700 (PDT)
Received: from www.pressmedia.com.pl ([195.117.30.142]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA19807 for <[e-mail]>; Sun, 16 Apr 2000 21:14:35 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from kllklk (ip217.providence11.ri.pub-ip.psi.net [38.26.242.217]) by www.pressmedia.com.pl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 28K9CBBJ; Mon, 17 Apr 2000 06:18:00 +0200
From: "Harry Trent" <[e-mail]>
Subject: Investment Marketing is Here!
To: invest28d
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, 16 Apr 2000 23:37:00 -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 VAA19808
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>

Use Investment Marketing to promote whatever investment ideas you
have to 
increase stock growth.
 
Investment Marketing uses mailings to get your ideas out there to the
people who want to read them and USE them for capital gains.
 
Our extensive lists of quality leads are compiled of people who have
asked to receive mail.
 
We use only state-of-the-art promotional software and do
all of the work for you.  You won't need any special software
or hardware.  Just send us your advertisement or HOT INVESTMENT TIP 
and we will send you an e-mail with the time and date when the
marketing mail will be sent.  Then you just keep a close eye on the
stock you picked
and watch it GROW!
 
 

Please call 401-433-5811 for more information and our rates.
 
Thank you,
Investment Marketing Specialists 

/////////////////////////////////////////////////////////////////////
///
Please remove at:
mailto:[e-mail]?subject=remove
/////////////////////////////////////////////////////////////////////
///





Received: by ns.secondary.com (8.9.3/8.9.3) id QAA07382 for ietf-smime-bks; Fri, 14 Apr 2000 16:00:30 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA07378 for <[e-mail]>; Fri, 14 Apr 2000 16:00:29 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Fri, 14 Apr 00 16:03:49 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id <H63WR71L>; Fri, 14 Apr 2000 16:03:49 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: draft-ietf-smime-idea-03
Date: Fri, 14 Apr 2000 16:03:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 14E97C5F83985-01-01
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>

Agree.  I think this should be 300D at the beginning, and trim the last two
bytes off of both examples.

Blake

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, April 14, 2000 12:35 AM
To: [e-mail]
Subject: draft-ietf-smime-idea-03


The S/MIME Capability sequences appear to be wrong.  In section 4 paragraph
2,
the text states that the parameters field must be absent, however the
encoding
sequence given has the parameters encoded as NULL.  The same is true in
paragraph
3 of the same section.

jim
http://www.nwlink.com



Received: by ns.secondary.com (8.9.3/8.9.3) id PAA06967 for ietf-smime-bks; Fri, 14 Apr 2000 15:31:17 -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 PAA06963 for <[e-mail]>; Fri, 14 Apr 2000 15:31:16 -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 PAA28123 for <[e-mail]>; Fri, 14 Apr 2000 15:35:06 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
Reply-to: [e-mail]
To: [e-mail]
Date: Fri, 14 Apr 2000 15:35:06 +0800
Subject: draft-ietf-smime-idea-03
Message-id: <[e-mail]>
X-User-Info: 203.108.193.31
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>

The S/MIME Capability sequences appear to be wrong.  In section 4 paragraph 2,
the text states that the parameters field must be absent, however the encoding
sequence given has the parameters encoded as NULL.  The same is true in paragraph
3 of the same section.

jim
http://www.nwlink.com


Received: by ns.secondary.com (8.9.3/8.9.3) id IAA29917 for ietf-smime-bks; Fri, 14 Apr 2000 08:19:05 -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 IAA29913 for <[e-mail]>; Fri, 14 Apr 2000 08:19:00 -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 DAA13315 for <[e-mail]>; Sat, 15 Apr 2000 03:22:40 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95572576004216>; Sat, 15 Apr 2000 03:22:40 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: id-ct-compressedData vs id-ct-publishCert
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 15 Apr 2000 03:22:40 (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>

Maxim Masiutin <[e-mail]> writes:

> id-ct-compressedData from draft-ietf-smime-compression-00.txt and
> id-ct-publishCert from draft-ietf-smime-certdist-04.txt has same OID

I posted a comment on this here a fortnight ago (in fact it was in reply to
a message from you), the id-ct-compressedData value was chosen when there was 
nothing else occupying that slot, it's now:

  id-ct-compressedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 7 }

(which was free as of the time of the previous posting).

Peter.



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA23982 for ietf-smime-bks; Fri, 14 Apr 2000 03:33:49 -0700 (PDT)
Received: from ns0.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA23977 for <[e-mail]>; Fri, 14 Apr 2000 03:33:47 -0700 (PDT)
Received: (qmail 23597 invoked from network); 14 Apr 2000 10:37:30 -0000
Received: from unknown (HELO mail-relay.eris.dera.gov.uk) (128.98.2.7) by ns0.eris.dera.gov.uk with SMTP; 14 Apr 2000 10:37:30 -0000
Received: (qmail 15584 invoked from network); 14 Apr 2000 10:37:29 -0000
Received: from wottoway.eris.dera.gov.uk (HELO wottaway.eris.dera.gov.uk) (128.98.10.17) by mail-relay.eris.dera.gov.uk with SMTP; 14 Apr 2000 10:37:29 -0000
From: "William Ottaway" <[e-mail]>
To: <[e-mail]>, "IETF SMIME List" <[e-mail]>
Subject: RE: Domain-to-point security services & DOMSEC
Date: Fri, 14 Apr 2000 11:37:10 +0100
Message-ID: <000601bfa5fd$636f2300$[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
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
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 Luis,

I believe the scenario you describe is handled in a DOMSEC environment. In
fact this is exactly the type of scenario that drove us to produce the
DOMSEC ID.

Section 4 of DOMSEC describes a domain and/or an individual being able to
encrypt for a recipient or the recipient's domain (DCA - Domain
Confidentiality Authority): -

"Messages may be encrypted for decryption by the final recipient and/or by a
DCA in the recipient's domain."

In your scenario the originator would send a message to the intended
recipient as usual but the originator or the originator's domain encrypts
the message so that the recipients domain (DCA) can decrypt it.  We think
this is covered by section 4:

* Section 4.1 describes a naming convention that must be followed so that
the certificate for the recipient's domain can be identified.

* Section 4.3 describes how a DCA decrypts a message that has been encrypted
by an originator and/or an originator's domain.

After re-reading this section we have changed it slightly to aid clarity,
and (hopefully!) to make it more clear that we are covering the scenario you
describe:

-- Begin new section 4.3

"4.3 Key Management for Domain Decryption

Domain decryption uses a domain-wide decryption key from the recipient's
domain. This key is owned by the DCA for the recipient domain. In order for
an encrypting process to locate the correct key, the certificate
corresponding to the DCA in the recipient's domain must be located. This is
achieved using the naming conventions specified in 4.1. It is vital that
these conventions are adhered to, in order to maintain confidentiality.

It should be noted that domain decryption can be performed on messages
encrypted by the originator and/or by a DCA in the originator's domain.
In the first case, the encryption process is described in CMS [5]; in the
second case, the encryption process is described in 4.2.

No specific method for locating this certificate is mandated in this
document. An implementation may choose to access a local certificate store
to locate the correct certificate. Alternatively, a directory may be used in
one of the following ways:

1. The directory may store the DCA certificate in the recipient's directory
entry. When the user certificate attribute is requested, this certificate is
returned.

2. The encrypting agent maps the recipient's name to the DCA name in the
manner specified in 4.1. The user certificate attribute associated with this
directory entry is then obtained.

This document does not mandate either of these processes. Whichever one is
used, the name mapping conventions must be adhered to, in order to maintain
confidentiality.

Having located the correct certificate, the encryption process is then
performed. A recipientInfo for the DCA is then generated, as described in
CMS [5]."

-- End new section 4.3

We see DOMSEC as a means of describing the building blocks required to
provide secure messaging between individuals and domains using S/MIME. How
these blocks are integrated into real systems is very much a policy matter
and consequently we do not go into this realm within DOMSEC.


To summarise, we believe your scenario is covered by DOMSEC. Do you agree?
Is further clarification needed? If so where?

Bill.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Luis Barriga
> Sent: 11 April 2000 15:16
> To: IETF SMIME List
> Subject: Domain-to-point security services & DOMSEC
>
>
> I have a common scenario that I believe should be addressed within this
> group. I'll refer to it as domain-to-point secure messaging and it looks
> as follows:
>
> A user [e-mail] wishes to communicate *securely* with a another user
> [e-mail]. The user [e-mail] doesn't have a cert (or if he does
> [e-mail] doesn't know it). I see this as a common case, when companies
> start migrating to PKI and:
>
> (1) [e-mail] is actually a user [e-mail], who has temporarily left
> his corporate premises and has a public email account at an POP/IMAP
> service provider. A wants to exchange email securely with colleagues at
> the Company, but not all of them have certs.
>
> (2) [e-mail] is an external user with no association with
> Corporate.Com, but who wants to send important secure email to
> [e-mail]. [e-mail] can't access the Company's PKI.
>
> To solve this, the Company can deploy a domain securiy service, sort of
> S/MIME proxy with public cert associated with [e-mail].
> The user [e-mail] (the point) could then send S/MIME to this proxy (the
> domain) with request to forward the email to the end user [e-mail].
> If A also has a cert, then B can reply securely directly or via the
> S/MIME proxy, provided that the proxy has access to the A's PKI
> (Company.Com or ISP.com).
>
> BTW, this scheme also allows users to store corporate email on
> unstrusted public POP/IMAP services providers. It can also be used for
> secure mailing lists and cert distribution.
>
> My question to You folks is:
>
> 1. Is there enough interest out there to work towards a draft?
>
> 2. It seems that this falls within the DOMSEC draft, but the scenario
> above is not explicitly addressed. Any opinion on this?
>
> 3. Anybody else done something similar?
>
> ------
> Luis Barriga
> Ericsson Research
>



Received: by ns.secondary.com (8.9.3/8.9.3) id HAA21692 for ietf-smime-bks; Thu, 13 Apr 2000 07:22:23 -0700 (PDT)
Received: from gate.ritlabs.com (IDENT:[e-mail] [212.56.195.233]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21688; Thu, 13 Apr 2000 07:22:15 -0700 (PDT)
Received: from ritlabs250.mldnet.com (max [212.56.194.250]) by gate.ritlabs.com (8.8.8/8.8.8) with ESMTP id RAA24796; Thu, 13 Apr 2000 17:28:34 +0300
Date: Thu, 13 Apr 2000 17:25:51 +0300
From: Maxim Masiutin <[e-mail]>
X-Mailer: The Bat! (v1.42 Beta/17)
Organization: RIT Research Labs
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Subject: id-ct-compressedData vs id-ct-publishCert
Mime-Version: 1.0
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>

Hello!

  id-ct-compressedData from draft-ietf-smime-compression-00.txt and
  id-ct-publishCert from draft-ietf-smime-certdist-04.txt has same OID

  In draft-ietf-smime-compression-00.txt, it is defined as

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 3

  In draft-ietf-smime-certdist-04.txt, it is defined as

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 3

  which is same. I've found it confusing; I would like go get a solution
  from the authors of drafts above mentioned.


-- 
Maxim Masiutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/




Received: by ns.secondary.com (8.9.3/8.9.3) id GAA20710 for ietf-smime-bks; Thu, 13 Apr 2000 06:44:40 -0700 (PDT)
Received: from gate.ritlabs.com (IDENT:[e-mail] [212.56.195.233]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA20705; Thu, 13 Apr 2000 06:44:25 -0700 (PDT)
Received: from ritlabs250.mldnet.com (max [212.56.194.250]) by gate.ritlabs.com (8.8.8/8.8.8) with ESMTP id QAA01818; Thu, 13 Apr 2000 16:50:24 +0300
Date: Thu, 13 Apr 2000 16:47:40 +0300
From: Maxim Masiutin <[e-mail]>
X-Mailer: The Bat! (v1.42 Beta/17)
Organization: RIT Research Labs
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Subject: duplicate aliases of the same OID in draft-ietf-pkix-new-part1-01.txt
Mime-Version: 1.0
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>

Hello!

  I've found duplicate aliases of the same OID in
  draft-ietf-pkix-new-part1-01.txt

  sha-1WithRSAEncryption (section 7.2.1) and sha1WithRSAEncryption
  (elsewhere).

  The first variant was also found in rfc2632, rfc2633 (along with the
  second variant).

  Second variant was also found in draft-ietf-smime-certdist-04.txt,
  draft-ietf-smime-examples-03.txt and rfc2633.

  There are also numerous duplicate OID aliases, for example
  PKCS#9-relaeted; they are different in PKIX documents, S/MIME
  documents and PKCS#9 itself.
  
  I've found it writing my ASN.1 code to work with S/MIME messages and
  X.509 certificates. Having multiple names of a same OIDS is much worse
  than having one, I think both workgroups should take care of that.
  
-- 
Maxim Masiutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/




Received: by ns.secondary.com (8.9.3/8.9.3) id FAA19947 for ietf-smime-bks; Thu, 13 Apr 2000 05:52:43 -0700 (PDT)
Received: from mars.syndata.com ([208.195.248.153]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA19942 for <[e-mail]>; Thu, 13 Apr 2000 05:52:42 -0700 (PDT)
Received: by MARS with Internet Mail Service (5.5.2650.21) id <2JTDM9CY>; Thu, 13 Apr 2000 08:56:09 -0400
Message-ID: <D92EE22C97C3D311855E005004E0CBF00336B1@MARS>
From: Aram Perez <[e-mail]>
To: [e-mail]
Subject: RE: CERTDIST
Date: Thu, 13 Apr 2000 08:56:07 -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>

> -----Original Message-----
> From: Mike Just [mailto:[e-mail]]
> Sent: Wednesday, April 12, 2000 11:47 AM
> To: [e-mail]
> Cc: '[e-mail]'; 'Russ Housley'
> Subject: RE: CERTDIST
> 
> 
> Two points.
> 
> 1) I agree with David. The document must be clear that if 
> using LDAP, user
> certificates should be in the userCertificate attribute; user 
> certificates
> MUST NOT be in the userSMimeCertificate attribute. (In other words,
> userSMimeCertificate is only used as a source of a user's S/MIME
> capabilities.)

I also agree, but shouldn't that field be called userSMimeCapabilities?
userSMimeCertificate implies that it stores a certificate.

Regards,
Aram Perez

[snip]


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA18202 for ietf-smime-bks; Wed, 12 Apr 2000 13:23:54 -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 NAA18198; Wed, 12 Apr 2000 13:23:53 -0700 (PDT)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <GFRJM7DD>; Wed, 12 Apr 2000 16:27:03 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'SMIME WG'" <[e-mail]>, [e-mail]
Subject: SNACC ASN.1 Freeware Release & Mail List
Date: Wed, 12 Apr 2000 16:27:03 -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>

All,

J. G. Van Dyke and Associates (VDA), a Wang Government Services Company, has
delivered an enhanced version of the freeware SNACC v1.3 rev 0.07 Abstract
Syntax Notation.1 (ASN.1) Compiler and Library.  In past releases, VDA
enhanced the C++ version of the SNACC library to implement the Distinguished
Encoding Rules (DER).  In the new release, VDA enhanced the C and C++
versions of the SNACC library to support PrintableString, TeletexString,
NumericString, IA5String, 
VisibileString, BMPString, UniversalString and UTF8String character string
types.  We added an optional function to SNACC that can be used to convert
ASN.1 OCTET STRINGs to single- or multi-byte character strings (as
appropriate).  This is needed to support the RFC 2459 PKIX requirements.
The SNACC enhancement is completely optional and does not impact existing
code that uses SNACC.  The SNACC library decodes an object as it always has.
If the application/library needs the ASN.1 OCTET STRINGs converted to
character strings, then it calls the new SNACC function/class to perform the
conversion.  If an application/library does not need the ASN.1 OCTET STRINGs
converted, then it does not need to call the conversion function/classes and
can use the SNACC-generated structures/classes as always.  

The VDA-enhanced SNACC compiler and C++ library is available along with the
S/MIME Freeware Library (SFL)
<http://www.armadillo.huntsville.al.us/software/smime> that uses SNACC to
implement the S/MIME v3 set of specifications.  The snacc1_6VDA.zip file
contains the SNACC v1.3 rev 0.07 ASN.1 Compiler and C++ Library source code
compilable for Unix and MS Windows NT/95/98/2000.   

The VDA-enhanced SNACC C library is available along with the freeware
Certificate Management Library (CML)
<http://www.armadillo.huntsville.al.us/software/certmgmt/index.html)> that
uses SNACC to implement the 1997 X.509 Recommendation and RFC 2459.  The
CML17sr.tar.Z file includes the source code for the CML and VDA-enhanced
SNACC C library compilable for Unix and MS Windows NT/95/98/2000. 

We plan to consolidate the enhancements made by VDA to the C and C++
versions of the SNACC source code into a single baseline that can be
delivered in a single tar/zip file.

In the new release, we also corrected a bug in the DEC_LOAD_ANYBUF macro.
We changed "bytesDecoded" to "bytesDecodedXX" to avoid conflict other SNACC
uses of the "bytesDecoded" variable.  We also enhanced the AsnOid method so
that it accepts a dynamic number of components within an object identifier. 

SNACC implements the majority of ASN.1 encoding/decoding rules.  SNACC does
not support all of
the latest ASN.1 features, but there are work-arounds that allow SNACC to be
used to produce ASN.1 hex encodings that are identical to those produced by
ASN.1 libraries that do support the latest ASN.1 features.  Also note that
many of the PKIX specs, such as RFC 2459, include 1988-compliant ASN.1
syntax modules which can be directly compiled using SNACC.

The SNACC ASN.1 library is totally unencumbered as stated in the SFL Public
License.  All source code for the VDA-enhanced SNACC software is being
provided at no cost and with no financial limitations regarding its use and
distribution.  Organizations can use the VDA-enhanced SNACC software without
paying any royalties or licensing fees.  

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

VDA welcomes all feedback regarding the VDA-enhanced SNACC software.  If
bugs are reported, then VDA will investigate each reported bug and, if
required, will produce a patch or an updated release of the software to
repair the bug.  We recommend that comments should be sent to the imc-snacc
mail list.  We will respond to all messages on that list.

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



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA17843 for ietf-smime-bks; Wed, 12 Apr 2000 13:15:10 -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 NAA17839 for <[e-mail]>; Wed, 12 Apr 2000 13:15:09 -0700 (PDT)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <GFRJM7AW>; Wed, 12 Apr 2000 16:18:19 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'SMIME WG'" <[e-mail]>
Subject: v1.6 S/MIME Freeware Library & Mail List
Date: Wed, 12 Apr 2000 16:18:20 -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>

All,

J.G. Van Dyke and Associates (VDA), a Wang Government Services Company, has 
delivered Version 1.6 of the S/MIME Freeware Library (SFL) source code and 
Application Programming Interface (API).  The SFL source code files are 
freely available to everyone from the Fortezza Developer's S/MIME Page
<http://www.armadillo.huntsville.al.us/software/smime>.  

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

The SFL has been successfully used to sign, verify, encrypt and decrypt
CMS/ESS 
objects using: S/MIME v3 mandatory-to-implement algorithms (DSA, E-S D-H,
3DES) 
provided by the Crypto++ 3.1 library; RSA suite of algorithms provided by
the 
RSA BSAFE v4.2 and Crypto++ 3.1 libraries; and Fortezza suite of algorithms 
provided by the Fortezza Crypto Card.  The SFL uses the VDA-enhanced SNACC
v1.3 
ASN.1 C++ Library to encode/decode objects. The v1.6 SFL release includes:
SFL
High-level library; Free (a.k.a. Crypto++) Crypto Token Interface Library
(CTIL); 
BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL (still being tested);
VDA-
enhanced GNU SNACC v1.3 rev 0.07 ASN.1 Compiler and C++ Library; test
utilities; 
test drivers and test data.  All CTILs were tested as Dynamically Linked 
Libraries (DLL) using MS Windows.  The Fortezza, BSAFE and Crypto++ CTILs
were
tested with the respective security libraries as shared objects using
Solaris 2.7.  

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

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

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

Baltimore and Entrust.  

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

1) We used the SFL to successfully process all of the SFL-supported sample
data included in the S/MIME WG "Examples of S/MIME Messages" document.  We
also used the SFL to construct sample data (such as signed receipts) to be
added to the document. We automated this SFL testing (through the use of
test drivers and configuration files) so that it can be easily repeated and
modified by us or independently by a third party.  We developed sample
objects that illustrate each feature in the Examples document that the SFL
supports.  This self-contained environment uses the specified certificates
(DSA, RSA, and DH) in the login as described in the document.  This
directory resides in "./smimeR1.6/test/specMatrix.d/CMS_Examples.d"; the
binaries are named as in the document (e.g. 5.4.bin, etc.).  The config
files used to generate these examples are in the "config.d" subdirectory.
The certificate build config files are in the "certs.d/config.d"
subdirectory.

2) We successfully completed RFC 2634 signed receipt interoperability
testing between the SFL and
Microsoft.  We added a check to the SFL to ensure that the application
always includes in the receiptRequest attribute a receiptsTo e-mail address
to which the signed receipt is to be sent.

3) We verified that the SFL can produce and process the SFL-supported
features documented in the S/MIME v3 interoperability matrices created by
Jim Schaad.  We automated this SFL testing so that it can be easily repeated
and modified by us or independently by a third party.  We have developed
sample objects that illustrate each feature in the matrix that the SFL
supports.  We updated the Interop.xls document (contained in the
"./smimeR1.6/test/specMatrix.d" subdirectories) to indicate the testing
performed using the SFL.  Within this document, each feature row contains a
reference to a binary file in the "CMS_Examples.d" directory that
demonstrates that feature if applicable.  These additional file names are
preceded by the name "ExInterop..." to distinguish them from the
"examples-03.txt" example binaries.

4) Fixed a number of bugs in the SFL and test drivers found during the
aforementioned interoperability testing.  Features improved in the SFL
include: proper SignedData and SignerInfo version numbers;
creating/processing encrypted messages without a User Key Material (UKM);
added SubjectKeyIdentifier (SKI) processing in SignedData and EnvelopedData
(Originator only, the RecipientInfos automatically use SKI for Fortezza/SPEX
CTILs); and EnvelopedData unprotectedAttrs from the test config file.  We
also corrected the following bugs in the test driver/configuration files
used to create X.509 Certificates for SFL testing: corrected inconsistent
UTC and General Time Dates; included dates past 1999; corrected object
identifiers (OID) for algorithms; and regenerated certificates to include
unsigned integers.
 
5) List template processing has been fixed to use the same "CSM_ListC"
template from the common libCert DLL.  The old convention required a new
name for this list class in each DLL; the new convention uses the same
CSM_ListC template class from libCert.  This forces the compiler to build
the logic for the actual class lists uniquely in the new DLL (see references
to CSM_ListC in the SFL for an example).  This simplifies the list logic in
support libraries and any new user libraries interested in using the list
template.

6) CertificateBuilder utility has been improved in functionality and tested
more thoroughly.  This utility can view, edit, and create certificates
(including extensions) as well as generate a variety of public/private keys
for processing by the SFL.  A new command line CertificateBuilderCL has been
created (it does not yet allow the building of keys, private or public).
The command line utility has not yet been tested on Unix.

7) Tested SFL with the C++ version of the SNACC ASN.1 library enhanced to
support PrintableString, TeletexString, NumericString, IA5String,
VisibileString, BMPString, UniversalString and UTF8String character string
types.  We added an optional function to SNACC to convert ASN.1 OCTET
STRINGs to single- or multi-byte character strings (as appropriate).  

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

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


We are still in the process of enhancing and testing the SFL.  Future
releases 
will include: completion of PKCS #11 CTIL testing; SPEX/ CTIL 
encrypt/decrypt/ESDH capabilities; finish CertificateBuilder command line 
utility; enhancing CertificateBuilder to support creation of Attribute 
Certificates; modify PKCS #12 code in test utilities to provide
interoperable key 
storage; add MIME support for test drivers; add "Certificate Management 
Messages over CMS" ASN.1 encode/decode functions; add enhanced test
routines; 
bug fixes; support for other crypto APIs (possible); and support for other
operating systems. 

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

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

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

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

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

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

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

On 14 January 2000, the U.S. Department of Commerce, Bureau of 
Export Administration published a new regulation implementing an update to
the U.S. Government's encryption export policy 
<http://www.bxa.doc.gov/Encryption/Default.htm>.  In accordance with the 
revisions to the Export Administration Regulations (EAR) of 14 Jan 2000,
the downloading of the SFL source code is not password controlled.

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

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

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

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


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA15264 for ietf-smime-bks; Wed, 12 Apr 2000 11:30:22 -0700 (PDT)
Received: from ps2.walltech.com (ps2.walltech.com [207.5.77.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15260 for <[e-mail]>; Wed, 12 Apr 2000 11:30:20 -0700 (PDT)
Received: from dtasi1 ([e-mail] [204.177.156.26]) by ps2.walltech.com (8.10.0/8.10.0/walltech-2.10) with SMTP id e3CIXgb18510; Wed, 12 Apr 2000 11:33:42 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 12 Apr 2000 11:33:39 -0700
To: Mike Just <[e-mail]>, [e-mail]
From: Bruce Greenblatt <[e-mail]>
Subject: RE: CERTDIST
Cc: "'[e-mail]'" <[e-mail]>, "'Russ Housley'" <[e-mail]>
In-Reply-To: <[e-mail] .com>
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>

As long as we're talking about where to put certificates, I thought that
I'd point out a draft that I wrote, that I received some pretty good
feedback on.  Check out the draft with the title: "LDAP Object Class for
Holding Certificate Information" at your favorite ietf drafts site, e.g.: 

http://search.ietf.org/internet-drafts/draft-greenblatt-ldap-certinfo-schema
-02.txt

It defines a "certificateType" structural object class, and "Use the
certificateType structural class to indicate that an object in the
directory is a specific type of certificate.  Each cer-
tificateType object in the directory appears directly beneath the owner of
the certificate in the directory hierarchy."

Comments are welcome... Cheers,

Bruce

At 11:47 AM 4/12/2000 -0400, Mike Just wrote:
>Two points.
>
>1) I agree with David. The document must be clear that if using LDAP, user
>certificates should be in the userCertificate attribute; user certificates
>MUST NOT be in the userSMimeCertificate attribute. (In other words,
>userSMimeCertificate is only used as a source of a user's S/MIME
>capabilities.)
>
>2) The document doesn't specify the behaviour of a client in the case that
>the userSMimeCertificate attribute is not populated (with the user's S/MIME
>capabilities).  This might only require a reference to the similar
>discussion in RFC 2633. Though there should be some indication that the
>userSMimeCertificate attribute is not required to be populated in an entry.
>
>Mike Just
>
>
>> -----Original Message-----
>> From: Russ Housley [mailto:[e-mail]]
>> Sent: Tuesday, April 11, 2000 11:11 PM
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Subject: CERTDIST
>> 
>> 
>> All:
>> 
>> It is clear to me that we have not reached consensus on 
>> CERTDIST.  I cannot 
>> recommend forwarding this document to the IESG until this 
>> certificates 
>> issue is resolved.  I hope that the  most interested parties 
>> can have an 
>> objective discussion and develop a solution that aligns with 
>> the PKIX LDAP 
>> schema.
>> 
>> Russ
>> 
>> At 09:22 AM 04/11/2000 -0400, David P. Kemp wrote:
>> >Russ,
>> >
>> >I too would like to resolve the outstanding issue of what attributes
>> >are used to hold certificates, both End Entity and CA,
>> >in the case where certificates are retrieved from an LDAP directory.
>> >
>> >As I noted after the 22 October 1999 announcement of working 
>> group last
>> >call for certdist-04, the paragraph added in response to 
>> Ella's concern
>> >is an improvement, however it does not go far enough because it does
>> >not require a single location that all applications can count on in
>> >order to ensure interoperability.   The text I proposed, 
>> quoted below,
>> >does ensure that all applications can count on finding both EE and CA
>> >certs in the PKIX-standard location, but it is not the only possible
>> >text which would ensure this result.  If Jim or anyone else has
>> >alternate proposed text for interoperability when using LDAP, please
>> >put it forward.
>> >
>> >Blake agrees that the PKIX attributes should be mandatory 
>> for LDAP in the
>> >SMIME cert-handling specification.  I am concerned that if 
>> certdist-04
>> >becomes an RFC, it will conflict with cert-handling and perpetuate
>> >confusion over which LDAP attributes should be used.  It will result
>> >in hard-to-diagnose problems when some apps look in one directory
>> >attribute and other apps look elsewhere, and it would not ensure
>> >that SMIME and non-SMIME applications can share the same directory
>> >infrastructure.
>> >
>> >Can we get a clear statement that when the smimeUserCertificate
>> >attribute is populated in an LDAP directory, it contains NO
>> >certificates?
>> >
>> >Regards,
>> >Dave
>> >
>> >
>> >
>> >
>> > > Date: Mon, 10 Apr 2000 16:34:33 -0400
>> > > To: "David P. Kemp" <[e-mail]>
>> > > From: Russ Housley <[e-mail]>
>> > > Subject: Re: which usercertificate attribute
>> > > Cc: [e-mail]
>> > >
>> > > Dave:
>> > >
>> > > Of course, Jim Schaad should be the one to answer this 
>> question.  He is 
>> > the
>> > > author of CERTDIST.  Note:  The CERTDIST document is in 
>> Working Group Last
>> > > Call, so if there are issues, they need to be resolved NOW.
>> > >
>> > > The paragraph that you are talking about was added 
>> because if comments
>> > > received from Ell Gardner at MITRE.  If memory serves, 
>> she was concerned
>> > > about two locations in the Directory for the same 
>> information.  The
>> > > paragrah that you quote is Jim Schaad's proposed 
>> solution: Get the certs
>> > > from userCertificates and the algorithm preference information
>> > > userSMimeCertificate.
>> > >
>> > > Russ
>> > >
>> > >
>> > > At 01:22 PM 04/07/2000 -0400, David P. Kemp wrote:
>> > >
>> > > >Russ,
>> > > >
>> > > >Certdist-04 section 4.5 explains:
>> > > >
>> > > >   "If the SignedData object is to be published in 
>> userSMimeCertificate,
>> > > >   the end-entity certificates MAY be omitted from the 
>> certificate bag
>> > > >   and published in the userCertificates [sic] LDAP 
>> attribute instead."
>> > > >
>> > > >How is an application developer supposed to interpret 
>> this requirement?
>> > > >I would read it to say that since the EE cert MAY be in 
>> either attribute,
>> > > >applications MUST look for it in BOTH attributes.  But 
>> Terry Hayes'
>> > > >posting indicates that (without an add-on) Communicator 
>> does not look
>> > > >in the userCertificate attribute.
>> > > >
>> > > >Section 2 justifies the inclusion of a cert path in the 
>> SignedData
>> > > >object by claiming that in non-X.500 (DAP or LDAP) 
>> directories it is
>> > > >difficult to impossible to obtain CA certificates.  But 
>> it does not
>> > > >follow through with that logic by *not* requiring a full 
>> cert path when
>> > > >the object *is* stored in an LDAP directory.
>> > > >
>> > > >Section 4.3 should be changed from:
>> > > >
>> > > >   "A chain of certificate from the 
>> end-entitycertificate(s) to the root
>> > > >   certificate(s) MUST be included in the CertificateSet."
>> > > >
>> > > >to:
>> > > >
>> > > >   "A chain of certificate from the 
>> end-entitycertificate(s) to the root
>> > > >   certificate(s) MUST be included in the CertificateSet 
>> unless the
>> > > >   SignedData object is published in 
>> userSMimeCertificate, in which case
>> > > >   the CertificateSet MUST be empty."
>> > > >
>> > > >and section 4.5 should be adjusted accordingly.
>> > > >
>> > > >This would ensure that when using LDAP, applications 
>> always use the
>> > > >PKIX-standard locations for both CA and EE certificates.
>> > > >
>> > > >Dave Kemp
>> 
>
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA10269 for ietf-smime-bks; Wed, 12 Apr 2000 08:44:19 -0700 (PDT)
Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10264 for <[e-mail]>; Wed, 12 Apr 2000 08:44:18 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <2X4T77A6>; Wed, 12 Apr 2000 11:47:27 -0400
Message-ID: <[e-mail]>
From: Mike Just <[e-mail]>
To: [e-mail]
Cc: "'[e-mail]'" <[e-mail]>, "'Russ Housley'" <[e-mail]>
Subject: RE: CERTDIST
Date: Wed, 12 Apr 2000 11:47:26 -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>

Two points.

1) I agree with David. The document must be clear that if using LDAP, user
certificates should be in the userCertificate attribute; user certificates
MUST NOT be in the userSMimeCertificate attribute. (In other words,
userSMimeCertificate is only used as a source of a user's S/MIME
capabilities.)

2) The document doesn't specify the behaviour of a client in the case that
the userSMimeCertificate attribute is not populated (with the user's S/MIME
capabilities).  This might only require a reference to the similar
discussion in RFC 2633. Though there should be some indication that the
userSMimeCertificate attribute is not required to be populated in an entry.

Mike Just


> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Tuesday, April 11, 2000 11:11 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: CERTDIST
> 
> 
> All:
> 
> It is clear to me that we have not reached consensus on 
> CERTDIST.  I cannot 
> recommend forwarding this document to the IESG until this 
> certificates 
> issue is resolved.  I hope that the  most interested parties 
> can have an 
> objective discussion and develop a solution that aligns with 
> the PKIX LDAP 
> schema.
> 
> Russ
> 
> At 09:22 AM 04/11/2000 -0400, David P. Kemp wrote:
> >Russ,
> >
> >I too would like to resolve the outstanding issue of what attributes
> >are used to hold certificates, both End Entity and CA,
> >in the case where certificates are retrieved from an LDAP directory.
> >
> >As I noted after the 22 October 1999 announcement of working 
> group last
> >call for certdist-04, the paragraph added in response to 
> Ella's concern
> >is an improvement, however it does not go far enough because it does
> >not require a single location that all applications can count on in
> >order to ensure interoperability.   The text I proposed, 
> quoted below,
> >does ensure that all applications can count on finding both EE and CA
> >certs in the PKIX-standard location, but it is not the only possible
> >text which would ensure this result.  If Jim or anyone else has
> >alternate proposed text for interoperability when using LDAP, please
> >put it forward.
> >
> >Blake agrees that the PKIX attributes should be mandatory 
> for LDAP in the
> >SMIME cert-handling specification.  I am concerned that if 
> certdist-04
> >becomes an RFC, it will conflict with cert-handling and perpetuate
> >confusion over which LDAP attributes should be used.  It will result
> >in hard-to-diagnose problems when some apps look in one directory
> >attribute and other apps look elsewhere, and it would not ensure
> >that SMIME and non-SMIME applications can share the same directory
> >infrastructure.
> >
> >Can we get a clear statement that when the smimeUserCertificate
> >attribute is populated in an LDAP directory, it contains NO
> >certificates?
> >
> >Regards,
> >Dave
> >
> >
> >
> >
> > > Date: Mon, 10 Apr 2000 16:34:33 -0400
> > > To: "David P. Kemp" <[e-mail]>
> > > From: Russ Housley <[e-mail]>
> > > Subject: Re: which usercertificate attribute
> > > Cc: [e-mail]
> > >
> > > Dave:
> > >
> > > Of course, Jim Schaad should be the one to answer this 
> question.  He is 
> > the
> > > author of CERTDIST.  Note:  The CERTDIST document is in 
> Working Group Last
> > > Call, so if there are issues, they need to be resolved NOW.
> > >
> > > The paragraph that you are talking about was added 
> because if comments
> > > received from Ell Gardner at MITRE.  If memory serves, 
> she was concerned
> > > about two locations in the Directory for the same 
> information.  The
> > > paragrah that you quote is Jim Schaad's proposed 
> solution: Get the certs
> > > from userCertificates and the algorithm preference information
> > > userSMimeCertificate.
> > >
> > > Russ
> > >
> > >
> > > At 01:22 PM 04/07/2000 -0400, David P. Kemp wrote:
> > >
> > > >Russ,
> > > >
> > > >Certdist-04 section 4.5 explains:
> > > >
> > > >   "If the SignedData object is to be published in 
> userSMimeCertificate,
> > > >   the end-entity certificates MAY be omitted from the 
> certificate bag
> > > >   and published in the userCertificates [sic] LDAP 
> attribute instead."
> > > >
> > > >How is an application developer supposed to interpret 
> this requirement?
> > > >I would read it to say that since the EE cert MAY be in 
> either attribute,
> > > >applications MUST look for it in BOTH attributes.  But 
> Terry Hayes'
> > > >posting indicates that (without an add-on) Communicator 
> does not look
> > > >in the userCertificate attribute.
> > > >
> > > >Section 2 justifies the inclusion of a cert path in the 
> SignedData
> > > >object by claiming that in non-X.500 (DAP or LDAP) 
> directories it is
> > > >difficult to impossible to obtain CA certificates.  But 
> it does not
> > > >follow through with that logic by *not* requiring a full 
> cert path when
> > > >the object *is* stored in an LDAP directory.
> > > >
> > > >Section 4.3 should be changed from:
> > > >
> > > >   "A chain of certificate from the 
> end-entitycertificate(s) to the root
> > > >   certificate(s) MUST be included in the CertificateSet."
> > > >
> > > >to:
> > > >
> > > >   "A chain of certificate from the 
> end-entitycertificate(s) to the root
> > > >   certificate(s) MUST be included in the CertificateSet 
> unless the
> > > >   SignedData object is published in 
> userSMimeCertificate, in which case
> > > >   the CertificateSet MUST be empty."
> > > >
> > > >and section 4.5 should be adjusted accordingly.
> > > >
> > > >This would ensure that when using LDAP, applications 
> always use the
> > > >PKIX-standard locations for both CA and EE certificates.
> > > >
> > > >Dave Kemp
> 


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA27196 for ietf-smime-bks; Tue, 11 Apr 2000 20:22:44 -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 UAA27188 for <[e-mail]>; Tue, 11 Apr 2000 20:22:42 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com.au (dial02.spyrus.com [207.212.34.122]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id UAA22035; Tue, 11 Apr 2000 20:26:12 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 11 Apr 2000 23:11:06 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: CERTDIST
Cc: [e-mail], [e-mail]
In-Reply-To: <[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>

All:

It is clear to me that we have not reached consensus on CERTDIST.  I cannot 
recommend forwarding this document to the IESG until this certificates 
issue is resolved.  I hope that the  most interested parties can have an 
objective discussion and develop a solution that aligns with the PKIX LDAP 
schema.

Russ

At 09:22 AM 04/11/2000 -0400, David P. Kemp wrote:
>Russ,
>
>I too would like to resolve the outstanding issue of what attributes
>are used to hold certificates, both End Entity and CA,
>in the case where certificates are retrieved from an LDAP directory.
>
>As I noted after the 22 October 1999 announcement of working group last
>call for certdist-04, the paragraph added in response to Ella's concern
>is an improvement, however it does not go far enough because it does
>not require a single location that all applications can count on in
>order to ensure interoperability.   The text I proposed, quoted below,
>does ensure that all applications can count on finding both EE and CA
>certs in the PKIX-standard location, but it is not the only possible
>text which would ensure this result.  If Jim or anyone else has
>alternate proposed text for interoperability when using LDAP, please
>put it forward.
>
>Blake agrees that the PKIX attributes should be mandatory for LDAP in the
>SMIME cert-handling specification.  I am concerned that if certdist-04
>becomes an RFC, it will conflict with cert-handling and perpetuate
>confusion over which LDAP attributes should be used.  It will result
>in hard-to-diagnose problems when some apps look in one directory
>attribute and other apps look elsewhere, and it would not ensure
>that SMIME and non-SMIME applications can share the same directory
>infrastructure.
>
>Can we get a clear statement that when the smimeUserCertificate
>attribute is populated in an LDAP directory, it contains NO
>certificates?
>
>Regards,
>Dave
>
>
>
>
> > Date: Mon, 10 Apr 2000 16:34:33 -0400
> > To: "David P. Kemp" <[e-mail]>
> > From: Russ Housley <[e-mail]>
> > Subject: Re: which usercertificate attribute
> > Cc: [e-mail]
> >
> > Dave:
> >
> > Of course, Jim Schaad should be the one to answer this question.  He is 
> the
> > author of CERTDIST.  Note:  The CERTDIST document is in Working Group Last
> > Call, so if there are issues, they need to be resolved NOW.
> >
> > The paragraph that you are talking about was added because if comments
> > received from Ell Gardner at MITRE.  If memory serves, she was concerned
> > about two locations in the Directory for the same information.  The
> > paragrah that you quote is Jim Schaad's proposed solution: Get the certs
> > from userCertificates and the algorithm preference information
> > userSMimeCertificate.
> >
> > Russ
> >
> >
> > At 01:22 PM 04/07/2000 -0400, David P. Kemp wrote:
> >
> > >Russ,
> > >
> > >Certdist-04 section 4.5 explains:
> > >
> > >   "If the SignedData object is to be published in userSMimeCertificate,
> > >   the end-entity certificates MAY be omitted from the certificate bag
> > >   and published in the userCertificates [sic] LDAP attribute instead."
> > >
> > >How is an application developer supposed to interpret this requirement?
> > >I would read it to say that since the EE cert MAY be in either attribute,
> > >applications MUST look for it in BOTH attributes.  But Terry Hayes'
> > >posting indicates that (without an add-on) Communicator does not look
> > >in the userCertificate attribute.
> > >
> > >Section 2 justifies the inclusion of a cert path in the SignedData
> > >object by claiming that in non-X.500 (DAP or LDAP) directories it is
> > >difficult to impossible to obtain CA certificates.  But it does not
> > >follow through with that logic by *not* requiring a full cert path when
> > >the object *is* stored in an LDAP directory.
> > >
> > >Section 4.3 should be changed from:
> > >
> > >   "A chain of certificate from the end-entitycertificate(s) to the root
> > >   certificate(s) MUST be included in the CertificateSet."
> > >
> > >to:
> > >
> > >   "A chain of certificate from the end-entitycertificate(s) to the root
> > >   certificate(s) MUST be included in the CertificateSet unless the
> > >   SignedData object is published in userSMimeCertificate, in which case
> > >   the CertificateSet MUST be empty."
> > >
> > >and section 4.5 should be adjusted accordingly.
> > >
> > >This would ensure that when using LDAP, applications always use the
> > >PKIX-standard locations for both CA and EE certificates.
> > >
> > >Dave Kemp



Received: by ns.secondary.com (8.9.3/8.9.3) id HAA19846 for ietf-smime-bks; Tue, 11 Apr 2000 07:09:58 -0700 (PDT)
Received: from solo.verkstad.net (solo.verkstad.net [192.71.20.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19841 for <[e-mail]>; Tue, 11 Apr 2000 07:09:56 -0700 (PDT)
Received: from verkstad.net (luke.verkstad.net [192.36.157.24]) by solo.verkstad.net (8.9.1/8.9.1) with ESMTP id QAA00123 for <[e-mail]>; Tue, 11 Apr 2000 16:13:27 +0200
Message-ID: <[e-mail]>
Date: Tue, 11 Apr 2000 16:15:48 +0200
From: Luis Barriga <[e-mail]>
Reply-To: [e-mail]
Organization: Ericsson Research
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF SMIME List <[e-mail]>
Subject: Domain-to-point security services & DOMSEC
Content-Type: text/plain; charset=iso-8859-15
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>

I have a common scenario that I believe should be addressed within this
group. I'll refer to it as domain-to-point secure messaging and it looks
as follows:

A user [e-mail] wishes to communicate *securely* with a another user
[e-mail]. The user [e-mail] doesn't have a cert (or if he does
[e-mail] doesn't know it). I see this as a common case, when companies
start migrating to PKI and:

(1) [e-mail] is actually a user [e-mail], who has temporarily left
his corporate premises and has a public email account at an POP/IMAP
service provider. A wants to exchange email securely with colleagues at
the Company, but not all of them have certs.

(2) [e-mail] is an external user with no association with
Corporate.Com, but who wants to send important secure email to
[e-mail]. [e-mail] can't access the Company's PKI. 

To solve this, the Company can deploy a domain securiy service, sort of
S/MIME proxy with public cert associated with [e-mail].
The user [e-mail] (the point) could then send S/MIME to this proxy (the
domain) with request to forward the email to the end user [e-mail].
If A also has a cert, then B can reply securely directly or via the
S/MIME proxy, provided that the proxy has access to the A's PKI
(Company.Com or ISP.com).

BTW, this scheme also allows users to store corporate email on
unstrusted public POP/IMAP services providers. It can also be used for
secure mailing lists and cert distribution.

My question to You folks is:

1. Is there enough interest out there to work towards a draft?

2. It seems that this falls within the DOMSEC draft, but the scenario
above is not explicitly addressed. Any opinion on this?

3. Anybody else done something similar?

------
Luis Barriga
Ericsson Research


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA19221 for ietf-smime-bks; Tue, 11 Apr 2000 06:19:12 -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 GAA19217 for <[e-mail]>; Tue, 11 Apr 2000 06:19:11 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA27916 for <[e-mail]>; Tue, 11 Apr 2000 09:21:31 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by roadblock.missi.ncsc.mil with ESMTP id JAA27908 for <[e-mail]>; Tue, 11 Apr 2000 09:21:31 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.57.72]) by missi.ncsc.mil (8.8.8/8.8.8) with SMTP id JAA07907 for <[e-mail]>; Tue, 11 Apr 2000 09:22:30 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 11 Apr 2000 09:22:08 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: which usercertificate attribute
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: HtSfrKcxfw7kaMm87Y9Qkg==
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>

Russ,

I too would like to resolve the outstanding issue of what attributes
are used to hold certificates, both End Entity and CA,
in the case where certificates are retrieved from an LDAP directory.

As I noted after the 22 October 1999 announcement of working group last
call for certdist-04, the paragraph added in response to Ella's concern
is an improvement, however it does not go far enough because it does
not require a single location that all applications can count on in
order to ensure interoperability.   The text I proposed, quoted below,
does ensure that all applications can count on finding both EE and CA
certs in the PKIX-standard location, but it is not the only possible
text which would ensure this result.  If Jim or anyone else has
alternate proposed text for interoperability when using LDAP, please
put it forward.

Blake agrees that the PKIX attributes should be mandatory for LDAP in the
SMIME cert-handling specification.  I am concerned that if certdist-04
becomes an RFC, it will conflict with cert-handling and perpetuate
confusion over which LDAP attributes should be used.  It will result
in hard-to-diagnose problems when some apps look in one directory
attribute and other apps look elsewhere, and it would not ensure
that SMIME and non-SMIME applications can share the same directory
infrastructure.

Can we get a clear statement that when the smimeUserCertificate
attribute is populated in an LDAP directory, it contains NO
certificates?

Regards,
Dave




> Date: Mon, 10 Apr 2000 16:34:33 -0400
> To: "David P. Kemp" <[e-mail]>
> From: Russ Housley <[e-mail]>
> Subject: Re: which usercertificate attribute
> Cc: [e-mail]
> 
> Dave:
> 
> Of course, Jim Schaad should be the one to answer this question.  He is the 
> author of CERTDIST.  Note:  The CERTDIST document is in Working Group Last 
> Call, so if there are issues, they need to be resolved NOW.
> 
> The paragraph that you are talking about was added because if comments 
> received from Ell Gardner at MITRE.  If memory serves, she was concerned 
> about two locations in the Directory for the same information.  The 
> paragrah that you quote is Jim Schaad's proposed solution: Get the certs 
> from userCertificates and the algorithm preference information 
> userSMimeCertificate.
> 
> Russ
> 
> 
> At 01:22 PM 04/07/2000 -0400, David P. Kemp wrote:
> 
> >Russ,
> >
> >Certdist-04 section 4.5 explains:
> >
> >   "If the SignedData object is to be published in userSMimeCertificate,
> >   the end-entity certificates MAY be omitted from the certificate bag
> >   and published in the userCertificates [sic] LDAP attribute instead."
> >
> >How is an application developer supposed to interpret this requirement?
> >I would read it to say that since the EE cert MAY be in either attribute,
> >applications MUST look for it in BOTH attributes.  But Terry Hayes'
> >posting indicates that (without an add-on) Communicator does not look
> >in the userCertificate attribute.
> >
> >Section 2 justifies the inclusion of a cert path in the SignedData
> >object by claiming that in non-X.500 (DAP or LDAP) directories it is
> >difficult to impossible to obtain CA certificates.  But it does not
> >follow through with that logic by *not* requiring a full cert path when
> >the object *is* stored in an LDAP directory.
> >
> >Section 4.3 should be changed from:
> >
> >   "A chain of certificate from the end-entitycertificate(s) to the root
> >   certificate(s) MUST be included in the CertificateSet."
> >
> >to:
> >
> >   "A chain of certificate from the end-entitycertificate(s) to the root
> >   certificate(s) MUST be included in the CertificateSet unless the
> >   SignedData object is published in userSMimeCertificate, in which case
> >   the CertificateSet MUST be empty."
> >
> >and section 4.5 should be adjusted accordingly.
> >
> >This would ensure that when using LDAP, applications always use the
> >PKIX-standard locations for both CA and EE certificates.
> >
> >Dave Kemp



Received: by ns.secondary.com (8.9.3/8.9.3) id DAA11642 for ietf-smime-bks; Tue, 11 Apr 2000 03:50:01 -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 DAA11638 for <[e-mail]>; Tue, 11 Apr 2000 03:50:00 -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 GAA27992; Tue, 11 Apr 2000 06:53:32 -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-cast-128-02.txt
Date: Tue, 11 Apr 2000 06:53:32 -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 CAST-128 Encryption Algorithm in CMS
	Author(s)	: C. Adams
	Filename	: draft-ietf-smime-cast-128-02.txt
	Pages		: 6
	Date		: 10-Apr-00
	
This document specifies how to incorporate CAST-128 [RFC2144] into 
the S/MIME Cryptographic Message Syntax (CMS) as an additional  
algorithm for symmetric encryption.  The relevant OIDs and processing 
steps are provided so that CAST-128 may be included in the CMS 
specification [RFC2630] for symmetric content and key encryption.

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

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

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


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

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

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

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cast-128-02.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 DAA11636 for ietf-smime-bks; Tue, 11 Apr 2000 03:49:56 -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 DAA11632 for <[e-mail]>; Tue, 11 Apr 2000 03:49:54 -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 GAA27980; Tue, 11 Apr 2000 06:53:26 -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-03.txt
Date: Tue, 11 Apr 2000 06:53:26 -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		: Incorporation of IDEA Encryption Algorithm in S/MIME
	Author(s)	: S. Teiwes, P. Hartmann, D. Kuenzi
	Filename	: draft-ietf-smime-idea-03.txt
	Pages		: 6
	Date		: 10-Apr-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-03.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-03.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-03.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-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-idea-03.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 PAA23879 for ietf-smime-bks; Mon, 10 Apr 2000 15:01:10 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA23875 for <[e-mail]>; Mon, 10 Apr 2000 15:01:09 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Mon, 10 Apr 00 15:04:09 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id <H63WR5CP>; Mon, 10 Apr 2000 15:04:09 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: CERTDIST comments
Date: Mon, 10 Apr 2000 15:04:08 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 14EC905360985-01-01
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>

Whoops.  I should pay more attention to deadlines ;).

In the example, the S/MIME capability:

SEQUENCE {
  OBJECT IDENTIFIER
  rc2CBC (1 2 840 113549 3 2)
  INTEGER 160
  }

should probably be:

SEQUENCE {
  OBJECT IDENTIFIER
  rc2CBC (1 2 840 113549 3 2)
  INTEGER 40
  }

(notice the INTEGER 40).  In the capabilities, the keylengths for RC2 are
stored unobfuscated.  Since this is an example, it may not be important that
this be correct.

Blake
--
Blake C. Ramsdell
Tumbleweed Communications (formerly Worldtalk Corp.)
For current info, check http://www.deming.com/users/blaker
Voice [phone] x103  Fax [phone]




Received: by ns.secondary.com (8.9.3/8.9.3) id NAA22710 for ietf-smime-bks; Mon, 10 Apr 2000 13:59:22 -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 NAA22706 for <[e-mail]>; Mon, 10 Apr 2000 13:59:21 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com.au ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA08082; Mon, 10 Apr 2000 14:02:16 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 10 Apr 2000 16:37:01 -0400
To: "David P. Kemp" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: which usercertificate attribute
Cc: [e-mail]
In-Reply-To: <[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>

Dave:

I am not convinced that LDAP support is a MUST requirement.  S/MIMEv2 
included a mechanism to support clients that are directory-impaired.  So 
far, this capability has remained in S/MIMEv3.

If LDAP is supported, then I agree with the things you say.

Russ


At 01:22 PM 04/07/2000 -0400, David P. Kemp wrote:
>The correct attribute in which to publish end-entity certificates is
>the one defined by RFC 2587 "LDAPv2 Schema", namely userCertificate.
>
>RFC 2632 "S/MIME Version 3 Certificate Handling", section 4, does not
>specify user agent requirements, leaving implementors on their own to
>decide how to retrieve certs.  It mentions X.500 (presumably meaning
>DAP) and DNS, but says:
>
>   "At a minimum, for initial S/MIME deployment, a user agent
>   could automatically generate a message to an intended recipient
>   requesting that recipient's certificate in a signed return
>   message."
>
>For son-of-2632, the first paragraph of section 4 needs to be rewritten
>to reflect the current directory environment.  At that time, it should
>also provide a little more guidance on interoperability.  I suggest:
>
>   "At a minimum, S/MIME user agents MUST support LDAP (RFC 2559) and
>   the LDAP v2 Schema (RFC 2587)."
>
>The new section 4 could mention certdist as an option, but standard
>LDAP should be mandatory.  Certdist could (if modified) be used to
>communicate the recipient's algorithm preferences without containing
>the recipient's certificate(s).
>
>Dave Kemp
>
>
>
>
>
> > From: [e-mail] (Terry Hayes)
> >
> > Thierry Van Doninck wrote:
> >
> > > Hi,
> > >
> > > When I use Netscape Communicator as a mail client, I can 'get' the
>certificates of my correspondents from a ldap directory.
> > > Netscape however looks for a userSMIMEcertificate instead of a
>userCertificate.
> > >
> > > Which is the correct attribute to publish Certificates in ?
> > > I would think that using 1 certificate for all applications would be 
> a lot
>more user friendly.
> > >
> >
> > The userSMIMEcertificate attribute contains additional information 
> about the
>SMIME recipient, in particular the preferred
> > encryption algorithms.  Without this information, the message sender 
> has to
>guess what algorithms would be acceptable.  This is
> > why Communicator used userSMIMEcertificate.
> >
> > More recent versions of SMIME support for Communicator (in particular 
> the PSM
>security add-on) supports retrieval of the
> > certificates from both attributes in the directory.  In addition, PSM has
>support for automatically retrieving certificates
> > from your primary directory (address book) without manual intervention.
> >
> > Terry Hayes
> > [e-mail]



Received: by ns.secondary.com (8.9.3/8.9.3) id NAA22705 for ietf-smime-bks; Mon, 10 Apr 2000 13:59:21 -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 NAA22701 for <[e-mail]>; Mon, 10 Apr 2000 13:59:20 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com.au ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA08077; Mon, 10 Apr 2000 14:02:04 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 10 Apr 2000 16:34:33 -0400
To: "David P. Kemp" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: which usercertificate attribute
Cc: [e-mail]
In-Reply-To: <[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>

Dave:

Of course, Jim Schaad should be the one to answer this question.  He is the 
author of CERTDIST.  Note:  The CERTDIST document is in Working Group Last 
Call, so if there are issues, they need to be resolved NOW.

The paragraph that you are talking about was added because if comments 
received from Ell Gardner at MITRE.  If memory serves, she was concerned 
about two locations in the Directory for the same information.  The 
paragrah that you quote is Jim Schaad's proposed solution: Get the certs 
from userCertificates and the algorithm preference information 
userSMimeCertificate.

Russ


At 01:22 PM 04/07/2000 -0400, David P. Kemp wrote:

>Russ,
>
>Certdist-04 section 4.5 explains:
>
>   "If the SignedData object is to be published in userSMimeCertificate,
>   the end-entity certificates MAY be omitted from the certificate bag
>   and published in the userCertificates [sic] LDAP attribute instead."
>
>How is an application developer supposed to interpret this requirement?
>I would read it to say that since the EE cert MAY be in either attribute,
>applications MUST look for it in BOTH attributes.  But Terry Hayes'
>posting indicates that (without an add-on) Communicator does not look
>in the userCertificate attribute.
>
>Section 2 justifies the inclusion of a cert path in the SignedData
>object by claiming that in non-X.500 (DAP or LDAP) directories it is
>difficult to impossible to obtain CA certificates.  But it does not
>follow through with that logic by *not* requiring a full cert path when
>the object *is* stored in an LDAP directory.
>
>Section 4.3 should be changed from:
>
>   "A chain of certificate from the end-entitycertificate(s) to the root
>   certificate(s) MUST be included in the CertificateSet."
>
>to:
>
>   "A chain of certificate from the end-entitycertificate(s) to the root
>   certificate(s) MUST be included in the CertificateSet unless the
>   SignedData object is published in userSMimeCertificate, in which case
>   the CertificateSet MUST be empty."
>
>and section 4.5 should be adjusted accordingly.
>
>This would ensure that when using LDAP, applications always use the
>PKIX-standard locations for both CA and EE certificates.
>
>Dave Kemp
>
>
>
>
> > From: Russ Housley <[e-mail]>
> >
> > See draft-ietf-smime-certdist-04.txt for a description of
> > userSMimeCertificate.  I think the document does a good job explaining why
> > userSMimeCertificate and userCertificate both exist.
> >
> > Russ



Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15456 for ietf-smime-bks; Mon, 10 Apr 2000 07:54:41 -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 HAA15451 for <[e-mail]>; Mon, 10 Apr 2000 07:54:39 -0700 (PDT)
Received: from wwilliams4 (wwilliams2.bbn.com [171.78.1.7]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id KAA10546; Mon, 10 Apr 2000 10:58:12 -0400 (EDT)
From: "Walter Williams" <[e-mail]>
To: "Aram Perez" <[e-mail]>, <[e-mail]>
Subject: RE: which usercertificate attribute
Date: Mon, 10 Apr 2000 10:49:49 -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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <D92EE22C97C3D311855E005004E0CBF003369C@MARS>
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>

Actually, smimeUserCertificate and userCertificate objects are both part of
the IETF standard organizationalPerson and inetOrgPerson schemas.  The first
is RFC2256 if my memory does not fail me and the second is a draft on the
standards track, and has been widely adopted in the industry.  Therefor:
There is a standard LDAP schema which you can use

Walter Williams
TSD
Senior IT Analyst
Genuity

Please note: GTE Internetworking is now Genuity

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Aram Perez
Sent: Monday, April 10, 2000 9:54 AM
To: [e-mail]
Subject: RE: which usercertificate attribute


David is right. Why have standards if you can't interoperate with other
implementations? Over a year ago I asked if there was a standard way of
getting a user's certificate from an LDAP directory. While I received a
number of replys, not one reply said: There is a standard LDAP schema which
you can use.

Regards,
Aram Perez

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Monday, April 10, 2000 8:46 AM
To: [e-mail]
Subject: Re: which usercertificate attribute


Peter,

Bob put the right words in my mouth :-).  IETF specifications use
"MUST", "SHOULD", and "MAY" in a uniform manner to enhance the
ability to interoperate.  MUST always means "must implement",
not "must use".

But I meant mandatory in an even more limited sense:  *if* applications
are going to support LDAP (i.e. X.500 directory attributes) to retrieve
certs, then they MUST be able to do it in accordance with the
standard LDAP schema.

Dave



> To: [e-mail]
> Subject: Re: which usercertificate attribute
>
> "David P. Kemp" <[e-mail]> writes:
>
> >The new section 4 could mention certdist as an option, but standard LDAP
> >should be mandatory.
>
> Why should it be mandatory?  I can see that saying that finding a cert is
> a good idea, but mandating it is not (there will always be situations
where
> it doesn't make sense), and mandating one particular way of doing it is
even
> worse - even if you are in a situation where retrieving a cert is useful,
> being forced to do it via LDAP is an unnecessary restriction.
>
> Peter.



Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15064 for ietf-smime-bks; Mon, 10 Apr 2000 07:29:43 -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 HAA15060 for <[e-mail]>; Mon, 10 Apr 2000 07:29:42 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com.au ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA03395; Mon, 10 Apr 2000 07:32:23 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
X-Priority: 2 (High)
Date: Mon, 10 Apr 2000 09:46:44 -0400
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Ready for IETF Last Call: draft-ietf-smime-cast-128-02.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>

Jeff & Marcus:

The S/MIME Working Group is finished with the CAST-128 algorithm 
specification.  It is ready for IETF Last Call and publication as a 
Proposed Standard RFC.

Russ



Received: by ns.secondary.com (8.9.3/8.9.3) id GAA14439 for ietf-smime-bks; Mon, 10 Apr 2000 06:51:17 -0700 (PDT)
Received: from mars.syndata.com ([208.195.248.153]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14435 for <[e-mail]>; Mon, 10 Apr 2000 06:51:16 -0700 (PDT)
Received: by MARS with Internet Mail Service (5.5.2650.21) id <2JTDM7AN>; Mon, 10 Apr 2000 09:54:05 -0400
Message-ID: <D92EE22C97C3D311855E005004E0CBF003369C@MARS>
From: Aram Perez <[e-mail]>
To: [e-mail]
Subject: RE: which usercertificate attribute
Date: Mon, 10 Apr 2000 09:53:59 -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>

David is right. Why have standards if you can't interoperate with other
implementations? Over a year ago I asked if there was a standard way of
getting a user's certificate from an LDAP directory. While I received a
number of replys, not one reply said: There is a standard LDAP schema which
you can use.

Regards,
Aram Perez

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Monday, April 10, 2000 8:46 AM
To: [e-mail]
Subject: Re: which usercertificate attribute


Peter,

Bob put the right words in my mouth :-).  IETF specifications use
"MUST", "SHOULD", and "MAY" in a uniform manner to enhance the
ability to interoperate.  MUST always means "must implement",
not "must use".

But I meant mandatory in an even more limited sense:  *if* applications
are going to support LDAP (i.e. X.500 directory attributes) to retrieve
certs, then they MUST be able to do it in accordance with the 
standard LDAP schema.

Dave



> To: [e-mail]
> Subject: Re: which usercertificate attribute
> 
> "David P. Kemp" <[e-mail]> writes:
> 
> >The new section 4 could mention certdist as an option, but standard LDAP 
> >should be mandatory.  
> 
> Why should it be mandatory?  I can see that saying that finding a cert is
> a good idea, but mandating it is not (there will always be situations
where
> it doesn't make sense), and mandating one particular way of doing it is
even
> worse - even if you are in a situation where retrieving a cert is useful,
> being forced to do it via LDAP is an unnecessary restriction.
> 
> Peter.


Received: by ns.secondary.com (8.9.3/8.9.3) id FAA13432 for ietf-smime-bks; Mon, 10 Apr 2000 05:43:08 -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 FAA13428 for <[e-mail]>; Mon, 10 Apr 2000 05:43:07 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id IAA17891 for <[e-mail]>; Mon, 10 Apr 2000 08:45:29 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by roadblock.missi.ncsc.mil with ESMTP id IAA17887 for <[e-mail]>; Mon, 10 Apr 2000 08:45:29 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.57.72]) by missi.ncsc.mil (8.8.8/8.8.8) with SMTP id IAA07830 for <[e-mail]>; Mon, 10 Apr 2000 08:46:21 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 10 Apr 2000 08:46:00 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: which usercertificate attribute
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: JJI8xtBbRS6Zc6mSf2Yuhg==
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>

Peter,

Bob put the right words in my mouth :-).  IETF specifications use
"MUST", "SHOULD", and "MAY" in a uniform manner to enhance the
ability to interoperate.  MUST always means "must implement",
not "must use".

But I meant mandatory in an even more limited sense:  *if* applications
are going to support LDAP (i.e. X.500 directory attributes) to retrieve
certs, then they MUST be able to do it in accordance with the 
standard LDAP schema.

Dave



> To: [e-mail]
> Subject: Re: which usercertificate attribute
> 
> "David P. Kemp" <[e-mail]> writes:
> 
> >The new section 4 could mention certdist as an option, but standard LDAP 
> >should be mandatory.  
> 
> Why should it be mandatory?  I can see that saying that finding a cert is
> a good idea, but mandating it is not (there will always be situations where
> it doesn't make sense), and mandating one particular way of doing it is even
> worse - even if you are in a situation where retrieving a cert is useful,
> being forced to do it via LDAP is an unnecessary restriction.
> 
> Peter.



Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05388 for ietf-smime-bks; Sat, 8 Apr 2000 22:03:39 -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 WAA05382 for <[e-mail]>; Sat, 8 Apr 2000 22:03:37 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Sat, 08 Apr 2000 23:06:28 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Sat, 08 Apr 2000 23:06:19 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: which usercertificate attribute
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_6B32AEC4.FC9D72C4"
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.

--=_6B32AEC4.FC9D72C4
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Peter,

At the risk of putting words in David's mouth, I think he was trying to =
define a=20
mandatory minimum environment that compliant software could be assumed=20
to support, so as to help ensure interoperability.

That certainly shouldn't preclude retrieving certificates some other way, =
of=20
course.

Bob

>>> Peter Gutmann <[e-mail]> 04/08/00 09:34AM >>>
"David P. Kemp" <[e-mail]> writes:

>The new section 4 could mention certdist as an option, but standard =
LDAP=20
>should be mandatory. =20

Why should it be mandatory?  I can see that saying that finding a cert is
a good idea, but mandating it is not (there will always be situations =
where
it doesn't make sense), and mandating one particular way of doing it is =
even
worse - even if you are in a situation where retrieving a cert is useful,
being forced to do it via LDAP is an unnecessary restriction.

Peter.

--=_6B32AEC4.FC9D72C4
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=3D1>Peter,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>At the risk of putting words in David's mouth, I think he was trying =
to=20
define a </DIV>
<DIV>mandatory minimum environment that compliant software could be =
assumed=20
</DIV>
<DIV>to support, so as to help ensure interoperability.</DIV>
<DIV>&nbsp;</DIV>
<DIV>That certainly shouldn't preclude retrieving certificates some other =
way,=20
of </DIV>
<DIV>course.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Bob<BR><BR>&gt;&gt;&gt; Peter Gutmann &lt;[e-mail]&gt=
;=20
04/08/00 09:34AM &gt;&gt;&gt;<BR>"David P. Kemp" &lt;[e-mail]&=
gt;=20
writes:<BR><BR>&gt;The new section 4 could mention certdist as an option, =
but=20
standard LDAP <BR>&gt;should be mandatory.&nbsp; <BR><BR>Why should it =
be=20
mandatory?&nbsp; I can see that saying that finding a cert is<BR>a good =
idea,=20
but mandating it is not (there will always be situations where<BR>it =
doesn't=20
make sense), and mandating one particular way of doing it is even<BR>worse =
-=20
even if you are in a situation where retrieving a cert is useful,<BR>being=
=20
forced to do it via LDAP is an unnecessary=20
restriction.<BR><BR>Peter.<BR><BR></DIV></BODY></HTML>

--=_6B32AEC4.FC9D72C4--


Received: by ns.secondary.com (8.9.3/8.9.3) id NAA05493 for ietf-smime-bks; Sat, 8 Apr 2000 13:38:21 -0700 (PDT)
Received: from relay2.sion.com ([e-mail] [200.43.36.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05479 for <[e-mail]>; Sat, 8 Apr 2000 13:38:18 -0700 (PDT)
Received: from PROXY (smtp.sion.com [200.43.36.110]) by relay2.sion.com (8.9.3/8.9.3) with ESMTP id RAA17625 for <[e-mail]>; Sat, 8 Apr 2000 17:56:43 -0300
Received: from intranet - 200.43.37.94 by sion.net with Microsoft SMTPSVC; Sat, 8 Apr 2000 17:38:27 -0300
From: "PortalProfesional.com" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Sat, 08 Apr 2000 17:40:10 -0300
Subject: LEAME, ES IMPORTANTE - www.portalprofesional.com
Reply-To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
X-Priority: 1
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>

Muchas Preguntas:
- Estas Buscando Empleo?
- Tienes empleo pero quieres uno mejor?
- No sabes donde dejar tu Curriculum?
- Eres Profesional o a punto de egresar?
- Ud es una Empresa y necesita hacer publicidad?
- Necesitas EMAIL Gratis?
- Necesitas Pagina Web Gratis?
- Ud es una Consultora o Empresa y necesita publicar sus Busquedas Laborales?
- Nunca encuentras lo que buscas en Internet?

UNA SOLA RESPUESTA: www.portalprofesional.com


VISITANOS. No te vas a arrepentir!
ICQ: 64451825
www.portalprofesional.com.ar





Received: by ns.secondary.com (8.9.3/8.9.3) id OAA13517 for ietf-smime-bks; Fri, 7 Apr 2000 14:31:14 -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 OAA13513 for <[e-mail]>; Fri, 7 Apr 2000 14:31:12 -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 JAA13063 for <[e-mail]>; Sat, 8 Apr 2000 09:34:23 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95514326315978>; Sat, 8 Apr 2000 09:34:23 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: which usercertificate attribute
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 8 Apr 2000 09:34:23 (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:

>The new section 4 could mention certdist as an option, but standard LDAP 
>should be mandatory.  

Why should it be mandatory?  I can see that saying that finding a cert is
a good idea, but mandating it is not (there will always be situations where
it doesn't make sense), and mandating one particular way of doing it is even
worse - even if you are in a situation where retrieving a cert is useful,
being forced to do it via LDAP is an unnecessary restriction.

Peter.



Received: by ns.secondary.com (8.9.3/8.9.3) id MAA11241 for ietf-smime-bks; Fri, 7 Apr 2000 12:00:40 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA11236 for <[e-mail]>; Fri, 7 Apr 2000 12:00:39 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Fri, 07 Apr 00 12:03:22 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id <H63WRZDC>; Fri, 7 Apr 2000 12:03:22 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Subject: RE: which usercertificate attribute
Date: Fri, 7 Apr 2000 12:03:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 14F0EF7049102-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>

This sounds reasonable.

I presume that there's going to be a round of edits surrounding a magic date
in September...

Blake

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Friday, April 07, 2000 10:22 AM
To: [e-mail]
Subject: Re: which usercertificate attribute


The correct attribute in which to publish end-entity certificates is
the one defined by RFC 2587 "LDAPv2 Schema", namely userCertificate.

RFC 2632 "S/MIME Version 3 Certificate Handling", section 4, does not
specify user agent requirements, leaving implementors on their own to
decide how to retrieve certs.  It mentions X.500 (presumably meaning
DAP) and DNS, but says:

  "At a minimum, for initial S/MIME deployment, a user agent
  could automatically generate a message to an intended recipient
  requesting that recipient's certificate in a signed return
  message."

For son-of-2632, the first paragraph of section 4 needs to be rewritten
to reflect the current directory environment.  At that time, it should
also provide a little more guidance on interoperability.  I suggest:

  "At a minimum, S/MIME user agents MUST support LDAP (RFC 2559) and
  the LDAP v2 Schema (RFC 2587)."

The new section 4 could mention certdist as an option, but standard
LDAP should be mandatory.  Certdist could (if modified) be used to
communicate the recipient's algorithm preferences without containing
the recipient's certificate(s).

Dave Kemp





> From: [e-mail] (Terry Hayes)
> 
> Thierry Van Doninck wrote:
> 
> > Hi,
> >
> > When I use Netscape Communicator as a mail client, I can 'get' the 
certificates of my correspondents from a ldap directory.
> > Netscape however looks for a userSMIMEcertificate instead of a 
userCertificate.
> >
> > Which is the correct attribute to publish Certificates in ?
> > I would think that using 1 certificate for all applications would be a
lot 
more user friendly.
> >
> 
> The userSMIMEcertificate attribute contains additional information about
the 
SMIME recipient, in particular the preferred
> encryption algorithms.  Without this information, the message sender has
to 
guess what algorithms would be acceptable.  This is
> why Communicator used userSMIMEcertificate.
> 
> More recent versions of SMIME support for Communicator (in particular the
PSM 
security add-on) supports retrieval of the
> certificates from both attributes in the directory.  In addition, PSM has 
support for automatically retrieving certificates
> from your primary directory (address book) without manual intervention.
> 
> Terry Hayes
> [e-mail]




Received: by ns.secondary.com (8.9.3/8.9.3) id KAA09102 for ietf-smime-bks; Fri, 7 Apr 2000 10:20:08 -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 KAA09097 for <[e-mail]>; Fri, 7 Apr 2000 10:20:07 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA08568 for <[e-mail]>; Fri, 7 Apr 2000 13:22:34 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by roadblock.missi.ncsc.mil with ESMTP id NAA08564 for <[e-mail]>; Fri, 7 Apr 2000 13:22:34 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.57.72]) by missi.ncsc.mil (8.8.8/8.8.8) with SMTP id NAA28352 for <[e-mail]>; Fri, 7 Apr 2000 13:23:06 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 7 Apr 2000 13:22:52 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: which usercertificate attribute
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: q8nMbHtQLiwjjPX0tKcHwA==
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>

Russ,

Certdist-04 section 4.5 explains:

  "If the SignedData object is to be published in userSMimeCertificate,
  the end-entity certificates MAY be omitted from the certificate bag
  and published in the userCertificates [sic] LDAP attribute instead."

How is an application developer supposed to interpret this requirement?
I would read it to say that since the EE cert MAY be in either attribute,
applications MUST look for it in BOTH attributes.  But Terry Hayes'
posting indicates that (without an add-on) Communicator does not look
in the userCertificate attribute.

Section 2 justifies the inclusion of a cert path in the SignedData
object by claiming that in non-X.500 (DAP or LDAP) directories it is
difficult to impossible to obtain CA certificates.  But it does not
follow through with that logic by *not* requiring a full cert path when
the object *is* stored in an LDAP directory.

Section 4.3 should be changed from:

  "A chain of certificate from the end-entitycertificate(s) to the root
  certificate(s) MUST be included in the CertificateSet."

to:

  "A chain of certificate from the end-entitycertificate(s) to the root
  certificate(s) MUST be included in the CertificateSet unless the
  SignedData object is published in userSMimeCertificate, in which case
  the CertificateSet MUST be empty."

and section 4.5 should be adjusted accordingly.

This would ensure that when using LDAP, applications always use the
PKIX-standard locations for both CA and EE certificates.

Dave Kemp




> From: Russ Housley <[e-mail]>
> 
> See draft-ietf-smime-certdist-04.txt for a description of 
> userSMimeCertificate.  I think the document does a good job explaining why 
> userSMimeCertificate and userCertificate both exist.
> 
> Russ



Received: by ns.secondary.com (8.9.3/8.9.3) id KAA09054 for ietf-smime-bks; Fri, 7 Apr 2000 10:19:36 -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 KAA09050 for <[e-mail]>; Fri, 7 Apr 2000 10:19:34 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA08499 for <[e-mail]>; Fri, 7 Apr 2000 13:22:02 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by roadblock.missi.ncsc.mil with ESMTP id NAA08490 for <[e-mail]>; Fri, 7 Apr 2000 13:22:02 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.57.72]) by missi.ncsc.mil (8.8.8/8.8.8) with SMTP id NAA28346 for <[e-mail]>; Fri, 7 Apr 2000 13:22:33 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 7 Apr 2000 13:22:19 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: which usercertificate attribute
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: e7FyxxG+tmYzlbvZgtpdKQ==
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>

The correct attribute in which to publish end-entity certificates is
the one defined by RFC 2587 "LDAPv2 Schema", namely userCertificate.

RFC 2632 "S/MIME Version 3 Certificate Handling", section 4, does not
specify user agent requirements, leaving implementors on their own to
decide how to retrieve certs.  It mentions X.500 (presumably meaning
DAP) and DNS, but says:

  "At a minimum, for initial S/MIME deployment, a user agent
  could automatically generate a message to an intended recipient
  requesting that recipient's certificate in a signed return
  message."

For son-of-2632, the first paragraph of section 4 needs to be rewritten
to reflect the current directory environment.  At that time, it should
also provide a little more guidance on interoperability.  I suggest:

  "At a minimum, S/MIME user agents MUST support LDAP (RFC 2559) and
  the LDAP v2 Schema (RFC 2587)."

The new section 4 could mention certdist as an option, but standard
LDAP should be mandatory.  Certdist could (if modified) be used to
communicate the recipient's algorithm preferences without containing
the recipient's certificate(s).

Dave Kemp





> From: [e-mail] (Terry Hayes)
> 
> Thierry Van Doninck wrote:
> 
> > Hi,
> >
> > When I use Netscape Communicator as a mail client, I can 'get' the 
certificates of my correspondents from a ldap directory.
> > Netscape however looks for a userSMIMEcertificate instead of a 
userCertificate.
> >
> > Which is the correct attribute to publish Certificates in ?
> > I would think that using 1 certificate for all applications would be a lot 
more user friendly.
> >
> 
> The userSMIMEcertificate attribute contains additional information about the 
SMIME recipient, in particular the preferred
> encryption algorithms.  Without this information, the message sender has to 
guess what algorithms would be acceptable.  This is
> why Communicator used userSMIMEcertificate.
> 
> More recent versions of SMIME support for Communicator (in particular the PSM 
security add-on) supports retrieval of the
> certificates from both attributes in the directory.  In addition, PSM has 
support for automatically retrieving certificates
> from your primary directory (address book) without manual intervention.
> 
> Terry Hayes
> [e-mail]



Received: by ns.secondary.com (8.9.3/8.9.3) id IAA03769 for ietf-smime-bks; Thu, 6 Apr 2000 08:40:50 -0700 (PDT)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA03765 for <[e-mail]>; Thu, 6 Apr 2000 08:40:48 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com.au (va.spyrus.com [205.177.169.194]) by thehub.knight-hub.com (8.9.3/8.9.3) with ESMTP id LAA10863; Thu, 6 Apr 2000 11:41:27 -0400
Message-Id: <4.2.0.58.20000406113958.00a4fe00@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 06 Apr 2000 11:43:21 -0400
To: Thierry Van Doninck <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: which usercertificate attribute
Cc: ietf-smime <[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>

Thierry:

 > When I use Netscape Communicator as a mail client, I can 'get' the 
certificates of my correspondents from a ldap directory.
 > Netscape however looks for a userSMIMEcertificate instead of a 
userCertificate.
 >
 > Which is the correct attribute to publish Certificates in ?
 > I would think that using 1 certificate for all applications would be a 
lot more user friendly.

See draft-ietf-smime-certdist-04.txt for a description of 
userSMimeCertificate.  I think the document does a good job explaining why 
userSMimeCertificate and userCertificate both exist.

Russ


Received: by ns.secondary.com (8.9.3/8.9.3) id HAA02959 for ietf-smime-bks; Thu, 6 Apr 2000 07:57:56 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02937 for <[e-mail]>; Thu, 6 Apr 2000 07:57:51 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id HAA01851 for <[e-mail]>; Thu, 6 Apr 2000 07:55:12 -0700 (PDT)
Received: from netscape.com ([206.222.244.213]) by dredd.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FSLOCS00.0OY; Thu, 6 Apr 2000 08:00:28 -0700 
Message-ID: <[e-mail]>
Date: Thu, 06 Apr 2000 08:00:30 -0700
From: [e-mail] (Terry Hayes)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Thierry Van Doninck <[e-mail]>
CC: ietf-smime <[e-mail]>
Subject: Re: which usercertificate attribute
References: <0551838EC845D14B*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=SY064/@MHS>
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>

Thierry Van Doninck wrote:

> Hi,
>
> When I use Netscape Communicator as a mail client, I can 'get' the certificates of my correspondents from a ldap directory.
> Netscape however looks for a userSMIMEcertificate instead of a userCertificate.
>
> Which is the correct attribute to publish Certificates in ?
> I would think that using 1 certificate for all applications would be a lot more user friendly.
>

The userSMIMEcertificate attribute contains additional information about the SMIME recipient, in particular the preferred
encryption algorithms.  Without this information, the message sender has to guess what algorithms would be acceptable.  This is
why Communicator used userSMIMEcertificate.

More recent versions of SMIME support for Communicator (in particular the PSM security add-on) supports retrieval of the
certificates from both attributes in the directory.  In addition, PSM has support for automatically retrieving certificates
from your primary directory (address book) without manual intervention.

Terry Hayes
[e-mail]



Received: by ns.secondary.com (8.9.3/8.9.3) id FAA00578 for ietf-smime-bks; Thu, 6 Apr 2000 05:33:16 -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 FAA00574 for <[e-mail]>; Thu, 6 Apr 2000 05:33:14 -0700 (PDT)
Date: 06 Apr 2000 14:34:37 +0200
From: Thierry Van Doninck <[e-mail]>
To: ietf-smime <[e-mail]>
Subject: which usercertificate attribute
Message-Id: <0551838EC845D14B*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=SY064/@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,

When I use Netscape Communicator as a mail client, I can 'get' the certificates of my correspondents from a ldap directory.
Netscape however looks for a userSMIMEcertificate instead of a userCertificate.

Which is the correct attribute to publish Certificates in ?
I would think that using 1 certificate for all applications would be a lot more user friendly.

I only have one physical passport, why would I need several digital one's ?

Thierry
eMail : [e-mail]


Received: by ns.secondary.com (8.9.3/8.9.3) id QAA07915 for ietf-smime-bks; Tue, 4 Apr 2000 16:47:14 -0700 (PDT)
Received: from poltegor.igo.wroc.pl (poltegor.igo.wroc.pl [156.17.53.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07910 for <[e-mail]>; Tue, 4 Apr 2000 16:47:12 -0700 (PDT)
Received: from kllklk (cranston-ip-2-114.dynamic.ziplink.net [209.206.5.114]) by poltegor.igo.wroc.pl (AIX4.2/UCB 8.7/8.7) with ESMTP id BAA18502; Wed, 5 Apr 2000 01:14:57 +0200 (DFT)
Message-Id: <[e-mail]>
From: "Wayne" <[e-mail]>
Subject: Top Notch
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: Tue, 04 Apr 2000 18:51:59 -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 QAA07911
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>

*Earn $2000 - $5000 weekly-starting within 1-4 weeks
*78% Profit Paid Daily
*No Selling
*No Risk Guarantee
*Work from home, No overhead, or employees.
*High Tech Training & Support
*Not MLM, 100x more profitable
*Multibillion Dollar Travel Industry
 
The most incredible part of our business
is that ALL MY CLIENTS CALL ME!
 
DO YOU QUALIFY FOR OUR MENTOR PROGRAM?
ACCEPTING ONLY 12 NEW ASSOCIATES
 
This is not a hobby!  Serious Inquires Only!!

Please reply with the following information 
NAME:
EMAIL ADDRESS:
PHONE:             (Required)
BEST TIME TO CALL:

TO:

mailto:[e-mail]?subject=more_info


FOR MORE INFORMATION

If you are an entrepreneur or have always wanted to be your own BOSS,
read on.  We supply state-of-the-art training and a support system
that allows you to work your business from your home with just a
phone-without cold calling.  DO NOT REPLY IF YOU ARE LOOKING FOR A 
"GET RICH QUICK" SCHEME or some extra cash or if you're lazy.  We are
only looking for  FOCUSED serious entrepreneurs. (Pt/FT) with the
DESIRE to  improve their lifestyle immediately. 

///////////////////////////////////////////////////////////
Please remove at mailto:[e-mail]?subject=remove
///////////////////////////////////////////////////////////





Received: by ns.secondary.com (8.9.3/8.9.3) id RAA11665 for ietf-smime-bks; Sun, 2 Apr 2000 17:52:25 -0700 (PDT)
Received: from mcaprov.mcanet.com.br (mcaprov.mcanet.com.br [200.194.224.1]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA11661 for <[e-mail]>; Sun, 2 Apr 2000 17:52:09 -0700 (PDT)
Received: from kllklk (unverified [38.26.242.199]) by mcaprov.mcanet.com.br (EMWAC SMTPRS 0.83) with SMTP id <[e-mail]>; Sun, 02 Apr 2000 20:50:32 +0000
Message-ID: <[e-mail]>
From: "Harry" <[e-mail]>
Subject: Increase Your Chances
To: win28sj
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, 02 Apr 2000 17:55:04 -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 RAA11662
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, Print this email, complete the form & fax it to 
407-359-1545

Name: ______________________________

Country: ___________________ST______

Email Address: _____________________

The above information is required to receive information via email



*****************************************************************
This message is sent in compliance of the new email bill
section 301. Per Section 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 LAA08786 for ietf-smime-bks; Sun, 2 Apr 2000 11:29:14 -0700 (PDT)
Received: from www.pressmedia.com.pl ([195.117.30.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08782 for <[e-mail]>; Sun, 2 Apr 2000 11:29:12 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from cranston-ip-1-193.dynamic.ziplink.net by www.pressmedia.com.pl with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id 2CS50T4D; Sun, 2 Apr 2000 04:37:19 +0200
From: "Greg" <[e-mail]>
Subject: Between us...
To: look90h
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Date: Sat, 01 Apr 2000 20:52:52 -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 LAA08783
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 E-COMMERCE WHEN YOU HOST WITH US!!

Tired of expensive e-commerce software, set up fees and leasing
contracts?
Here is the deal: You host your site with us and you get free E
-Commerce,
including a merchant account, real-time software and shopping cart.

NO ONE CAN BEAT OUR PRICE! IF YOU FIND A BETTER DEAL FOR OUR PACKAGE
ANYWHERE ELSE, WE WILL MATCH OUR COMPETITOR'S PRICE PLUS GIVE YOU THE
FIRST MONTH FOR FREE. 

While others charge you hundreds of dollars to get a merchant account
or
put you on a 48 months non-cancelable lease agreement we charge you
NOTHING for E-commerce when you sign up for our e-commerce hosting
plan. If you wish to stay with your current hosting company you still
can get the same deal. 
Check it out first and make an informed decision. 

You have never seen a package deal like this before:

* Your own merchant account with one of the lowest rates in the
industry
* Real-Time software to accept VISA, MASTERCARD, AMEX,
DISCOVER/NOVUS, DINERSCLUB/CARTE BLANCHE, JCB
* Direct deposit within 48 hrs into your checking account
* Shopping Cart store front software with an easy to use web based
interface
* Real-Time Credit Card Processing software
* Virtual terminal for phone/fax/mail orders
* Automated E-mail receipts to your clients
* Recurring billing feature with batch uploads
* Password generator for membership sites
* Automatic batch closing
* Address verification system (AVS)
* Back office to 24/7 access account history
* 75 MB (megabytes) of disk space
* 30 GB (gigabyte) of data transfer per month
* 25 POP3 E-mail accounts
* Unlimited alias E-mail addresses
* Live web site statistics
* Unlimited FTP uploads
* Anonymous FTP
* CGI directory for your own scripts
* Site control panel
* Installation included
* Tech support included

All this and more when you sign up for our E-Commerce Hosting plan
for ONLY $69.95 per month and a one time set up fee of $199.00.  That
's right. NO ADDITIONAL SET UP FEES or application fees for your
merchant account
real-time software or shopping cart storefront. A one-stop E-Commerce
solution. And the best is:

NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME.

THIS PRICE APPLIES TO U.S. BASED COMPANIES OR INDIVIDUALS ONLY! 
BUT WE ALSO HAVE A SOLUTION FOR INTERNATIONAL MERCHANTS! 

Please reply to:

mailto:[e-mail]?subject=INFO-PLEASE
to receive our FREE information package without obligations.



 
*********************************************************
Remove at mailto:[e-mail]?subject=remove
*********************************************************





Received: by ns.secondary.com (8.9.3/8.9.3) id UAA16156 for ietf-smime-bks; Sat, 1 Apr 2000 20:11:23 -0800 (PST)
Received: from ttic01.tatung.com.tw (IDENT:[e-mail] [139.223.65.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA16149 for <[e-mail]>; Sat, 1 Apr 2000 20:11:19 -0800 (PST)
Received: from kllklk (cranston-ip-1-50.dynamic.ziplink.net [209.206.4.50]) by ttic01.tatung.com.tw (8.9.3/8.9.3) with ESMTP id MAA03816; Sun, 2 Apr 2000 12:11:38 +0800
Message-Id: <[e-mail]>
From: "Greg" <[e-mail]>
Subject: Between us...
To: [e-mail]
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Date: Sat, 01 Apr 2000 22:29:24 -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 UAA16150
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 E-COMMERCE WHEN YOU HOST WITH US!!

Tired of expensive e-commerce software, set up fees and leasing
contracts?
Here is the deal: You host your site with us and you get free E
-Commerce,
including a merchant account, real-time software and shopping cart.

NO ONE CAN BEAT OUR PRICE! IF YOU FIND A BETTER DEAL FOR OUR PACKAGE
ANYWHERE ELSE, WE WILL MATCH OUR COMPETITOR'S PRICE PLUS GIVE YOU THE
FIRST MONTH FOR FREE. 

While others charge you hundreds of dollars to get a merchant account
or
put you on a 48 months non-cancelable lease agreement we charge you
NOTHING for E-commerce when you sign up for our e-commerce hosting
plan. If you wish to stay with your current hosting company you still
can get the same deal. 
Check it out first and make an informed decision. 

You have never seen a package deal like this before:

* Your own merchant account with one of the lowest rates in the
industry
* Real-Time software to accept VISA, MASTERCARD, AMEX,
DISCOVER/NOVUS, DINERSCLUB/CARTE BLANCHE, JCB
* Direct deposit within 48 hrs into your checking account
* Shopping Cart store front software with an easy to use web based
interface
* Real-Time Credit Card Processing software
* Virtual terminal for phone/fax/mail orders
* Automated E-mail receipts to your clients
* Recurring billing feature with batch uploads
* Password generator for membership sites
* Automatic batch closing
* Address verification system (AVS)
* Back office to 24/7 access account history
* 75 MB (megabytes) of disk space
* 30 GB (gigabyte) of data transfer per month
* 25 POP3 E-mail accounts
* Unlimited alias E-mail addresses
* Live web site statistics
* Unlimited FTP uploads
* Anonymous FTP
* CGI directory for your own scripts
* Site control panel
* Installation included
* Tech support included

All this and more when you sign up for our E-Commerce Hosting plan
for ONLY $69.95 per month and a one time set up fee of $199.00.  That
's right. NO ADDITIONAL SET UP FEES or application fees for your
merchant account
real-time software or shopping cart storefront. A one-stop E-Commerce
solution. And the best is:

NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME.

THIS PRICE APPLIES TO U.S. BASED COMPANIES OR INDIVIDUALS ONLY! 
BUT WE ALSO HAVE A SOLUTION FOR INTERNATIONAL MERCHANTS! 

Please reply to:

mailto:[e-mail]?subject=INFO-PLEASE
to receive our FREE information package without obligations.



 
*********************************************************
Remove at mailto:[e-mail]?subject=remove
*********************************************************





Received: by ns.secondary.com (8.9.3/8.9.3) id SAA04926 for ietf-smime-bks; Sat, 1 Apr 2000 18:35:45 -0800 (PST)
Received: from www.pressmedia.com.pl ([195.117.30.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA04911 for <[e-mail]>; Sat, 1 Apr 2000 18:35:41 -0800 (PST)
Message-Id: <[e-mail]>
Received: from cranston-ip-1-193.dynamic.ziplink.net by www.pressmedia.com.pl with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id 2CS50T4D; Sun, 2 Apr 2000 04:37:19 +0200
From: "Greg" <[e-mail]>
Subject: Between us...
To: look90h
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Date: Sat, 01 Apr 2000 20:52:52 -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 SAA04919
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 E-COMMERCE WHEN YOU HOST WITH US!!

Tired of expensive e-commerce software, set up fees and leasing
contracts?
Here is the deal: You host your site with us and you get free E
-Commerce,
including a merchant account, real-time software and shopping cart.

NO ONE CAN BEAT OUR PRICE! IF YOU FIND A BETTER DEAL FOR OUR PACKAGE
ANYWHERE ELSE, WE WILL MATCH OUR COMPETITOR'S PRICE PLUS GIVE YOU THE
FIRST MONTH FOR FREE. 

While others charge you hundreds of dollars to get a merchant account
or
put you on a 48 months non-cancelable lease agreement we charge you
NOTHING for E-commerce when you sign up for our e-commerce hosting
plan. If you wish to stay with your current hosting company you still
can get the same deal. 
Check it out first and make an informed decision. 

You have never seen a package deal like this before:

* Your own merchant account with one of the lowest rates in the
industry
* Real-Time software to accept VISA, MASTERCARD, AMEX,
DISCOVER/NOVUS, DINERSCLUB/CARTE BLANCHE, JCB
* Direct deposit within 48 hrs into your checking account
* Shopping Cart store front software with an easy to use web based
interface
* Real-Time Credit Card Processing software
* Virtual terminal for phone/fax/mail orders
* Automated E-mail receipts to your clients
* Recurring billing feature with batch uploads
* Password generator for membership sites
* Automatic batch closing
* Address verification system (AVS)
* Back office to 24/7 access account history
* 75 MB (megabytes) of disk space
* 30 GB (gigabyte) of data transfer per month
* 25 POP3 E-mail accounts
* Unlimited alias E-mail addresses
* Live web site statistics
* Unlimited FTP uploads
* Anonymous FTP
* CGI directory for your own scripts
* Site control panel
* Installation included
* Tech support included

All this and more when you sign up for our E-Commerce Hosting plan
for ONLY $69.95 per month and a one time set up fee of $199.00.  That
's right. NO ADDITIONAL SET UP FEES or application fees for your
merchant account
real-time software or shopping cart storefront. A one-stop E-Commerce
solution. And the best is:

NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME.

THIS PRICE APPLIES TO U.S. BASED COMPANIES OR INDIVIDUALS ONLY! 
BUT WE ALSO HAVE A SOLUTION FOR INTERNATIONAL MERCHANTS! 

Please reply to:

mailto:[e-mail]?subject=INFO-PLEASE
to receive our FREE information package without obligations.



 
*********************************************************
Remove at mailto:[e-mail]?subject=remove
*********************************************************