Subject: CAs that support subjectAltName

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 30 Jun 1999 15:17:55 -0600

We're doing some experimenting with certificates that 
contain subjectAltName=RFC822=.....

Outlook98 will not allow a signed  S/MIME message to be sent if the 
e-mail address doesn't match either the "E=" or
"RFC822=" attribute in a certificate, but the RFC822 form
does seem to work, at least on outgoing messages.

Other than hand-crafting one, Petra Gloeckner's certificate,
issued by "Research" is the only example I have of such
a certificate.

Does anyone know of a public CA that can issue
such certificates, so we can do further interoperability testing?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

Date: Wed, 30 Jun 1999 15:17:55 -0600
From: "Bob Jueneman" <[email-masked]>
To: "<"<[email-masked]>
Subject: CAs that support subjectAltName
Sender: [email-masked]

We're doing some experimenting with certificates that 
contain subjectAltName=RFC822=.....

Outlook98 will not allow a signed  S/MIME message to be sent if the 
e-mail address doesn't match either the "E=" or
"RFC822=" attribute in a certificate, but the RFC822 form
does seem to work, at least on outgoing messages.

Other than hand-crafting one, Petra Gloeckner's certificate,
issued by "Research" is the only example I have of such
a certificate.

Does anyone know of a public CA that can issue
such certificates, so we can do further interoperability testing?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

Date: Wed, 30 Jun 1999 17:32:58 -0400
From: Larry Stoddard <[email-masked]>
To: Antonio =?iso-8859-1?Q?Ma=F1a?= <[email-masked]>
CC: [email-masked]
Subject: Re: Charter Revision
Sender: [email-masked]

The problem with the key/cert management approach is that it requires
many keys. This will eliminate smart card based solutions as there is
not enough space to hold multiple keys and key histories. Unless you use
multiple smart cards, which would mean playing musical smart cards to
read all your mail. Lending a token means that you are giving access to
everything protected by the token, including the ability to sign. The
problem with lending encryption keys is that some authentication schemes
use encryption keys instead of signing keys to do anonymous
authentication.

Also for those that lease PKI services there will be an additional
charge for each cert issued, so there is an incentive to minimize the
number of certificates required. The goal is to separate authorization
from identity as any change in authorization will result in revocation
of the identity certificate. Also the management of roles is something
that should be handled in as distributed a fashion as possible, ideally
the role owner should be able to delegate his role without involving the
CA. 

How do you foresee dealing with temporary delegation of signing
authority for a role? Issuing identity certs and then revoking them
would seem to be an extreme way of handling this and means more work for
LRA and CA administration, not to mention longer CRLs. An attribute
certificate with a short lifetime is more practical, especially if the
attribute cert can be issued by the local role owner.

Larry Stoddard

Antonio Maña wrote:
> 
> 
> I agree completely with David Kemp on this. It is a good idea that the
> implementation of the 'role' feature is human readable. The email
> system has been used in this way (without security) by using different
> pseudonyms (i.e. alias). Therefore Mr. Roger Smith could solve his
> problem without attribute certificates or any other change to the
> current situation simply. All he has to do is set different
> adresses for his roles. Therefore the address [email-masked]
> can be used for his personal messages using the key related to this
> account and the corresponding certificate. The address [email-masked]
> or [email-masked] can be used in the same way to identify
> his CEO role. Even if both accounts are aliases and are redirected to
> some other account, the messages sent to each account will be encrypted
> using different keys, so Roger can give the (curious) EA the key that
> decrypts messages sent to his official account without risk.
> 
> Antonio Maña.
> 
>                             \|||/
>                            ( . . )
>   +------------------o000-----U------000o------------------+
>   !           _   ,                                        !
>   ! Antonio Mana Gomez               eMail: [email-masked] !
>   !              http://www.lcc.uma.es/~amg                !
>   +--------------------------------------------------------+
>   ! Departamento de Lenguajes y Ciencias de la Computacion !
>   !      E.T.S.I.Informatica.        Desp. 1.2.B.19        !
>   !                  Campus de Teatinos.                   !
>   !                 29071 MALAGA (SPAIN)                   !
>   +--------------------------------------------------------+
>   ! Phone: (+34) 5 213 27 54        Fax: (+34) 5 213 13 97 !
>   +--------------------------------------------------------+
>   ! PGP KEY TYPE:                                          !
>   !   RSA 1024                                             !
>   ! KEY FINGERPRINT:                                       !
>   !   7900 CDBB 9766 AB87  F0CE 5B4F 3DF1 BA56             !
>   ! KEY SERVER:                                            !
>   !   Cert'eM at http://socrates.crypto.lcc.uma.es         !
>   +--------------------------------------------------------+

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-examples-01.txt
Date: Wed, 30 Jun 1999 08:53:45 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Examples of CMS Message Bodies
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-examples-01.txt
	Pages		: 8
	Date		: 29-Jun-99
	
This document gives examples of message bodies formatted using the
Cryptographic Message Syntax (CMS). It includes examples of most or all
common formats; in addition, it gives examples that show common pitfalls in implementing CMS. The purpose of this document is to help increase
interoperability for S/MIME and other protocols that rely on CMS.
 
This draft is being discussed on the 'ietf-smime' mailing list.  To join
the list, send a message to <[email-masked]> with the single
word 'subscribe' in the body of the message.  Also, there is a Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-examples-01.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 30 Jun 1999 13:40:38 +0200
From: Antonio =?iso-8859-1?Q?Ma=F1a?= <[email-masked]>
Organization: Universidad de =?iso-8859-1?Q?M=E1laga?=
To: [email-masked]
Subject: Re: Charter Revision
Sender: [email-masked]

[email-masked] escribió:
> 
> -----Original Message-----
> From: dpkemp [SMTP:[email-masked]]
> Sent: Monday, June 28, 1999 5:49 PM
> To: ietf-smime
> Cc: dpkemp
> Subject: Re:Charter Revision

SKIP

> 
> I believe that establishing a "[email-masked]" role is exclusively
> a key/cert management issue.  What changes/additions to S/MIME did you
> envision being needed?  What purpose would machine-readable message
> attributes serve in this application?
> 
> > Also suppose the CEO of a company is on vacation and he wishes his EA to
> > check his mail. But the CEO's mail is not encrypted for his EA and he
> > doesn't want the EA to have access to his personal email that is
> > encrypted for the same address.
> 
> Recipient-based access control (where the EA knows the CEO's private
> key but is on his honor not to read messages marked with a
> machine-readable "personal" attribute) is not a particularly secure
> solution. It would be possible to define a "personal/official" message
> flag that every sender would have to set appropriately, *and* rely on a
> trusted proxy to not forward personal messages to the EA.  But it seems
> much simpler to just use a role cert "Roger Smith, CEO" and a
> personal cert "Roger Smith" with different keys, and share just the
> role private key with the EA.  Human senders would select the
> appropriate certificate for personal or official messages based on the
> DN. What advantage would (machine-readable) message attributes have over
> (human-readable) DNs in this application?

I agree completely with David Kemp on this. It is a good idea that the
implementation of the 'role' feature is human readable. The email
system has been used in this way (without security) by using different
pseudonyms (i.e. alias). Therefore Mr. Roger Smith could solve his
problem without attribute certificates or any other change to the
current situation simply. All he has to do is set different
adresses for his roles. Therefore the address [email-masked]
can be used for his personal messages using the key related to this
account and the corresponding certificate. The address [email-masked]
or [email-masked] can be used in the same way to identify
his CEO role. Even if both accounts are aliases and are redirected to
some other account, the messages sent to each account will be encrypted 
using different keys, so Roger can give the (curious) EA the key that
decrypts messages sent to his official account without risk.

Antonio Maña.

                            \|||/
                           ( . . )
  +------------------o000-----U------000o------------------+
  !           _   ,                                        !
  ! Antonio Mana Gomez               eMail: [email-masked] !
  !              http://www.lcc.uma.es/~amg                !
  +--------------------------------------------------------+
  ! Departamento de Lenguajes y Ciencias de la Computacion !
  !      E.T.S.I.Informatica.        Desp. 1.2.B.19        !
  !                  Campus de Teatinos.                   !
  !                 29071 MALAGA (SPAIN)                   !
  +--------------------------------------------------------+
  ! Phone: (+34) 5 213 27 54        Fax: (+34) 5 213 13 97 !
  +--------------------------------------------------------+
  ! PGP KEY TYPE:                                          !
  !   RSA 1024                                             !
  ! KEY FINGERPRINT:                                       !
  !   7900 CDBB 9766 AB87  F0CE 5B4F 3DF1 BA56             !
  ! KEY SERVER:                                            !
  !   Cert'eM at http://socrates.crypto.lcc.uma.es         !
  +--------------------------------------------------------+

From: [email-masked]
To: [email-masked]
Subject: Re:Charter Revision "reference to RFC 2412 should be to RFC 2142"
X400-MTS-Identifier: [/PRMD=MIL/ADMD=400NET/C=SE;ISOCOR-3715e38a-fmx01]
Date: 30 Jun 1999 06:10:32 +0200
Importance: normal
Autoforwarded: false
Sender: [email-masked]

Your reference to RFC 2412 should be to RFC 2142.

/Bengt

From: [email-masked]
Date: Tue, 29 Jun 1999 11:53:28 -0400
Subject: Re:Charter Revision(take 2)
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

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

Apologies for the unclear insertions in my earlier posting.

>> Date: Fri, 25 Jun 1999 16:48:59 -0400
>> From: Larry Stoddard <[email-masked]>
>> 
>> I would like to suggest an additional item for the charter. Currently
>> there is no support for addresses that are role based (ie
>> [email-masked]). Here are some examples of problems that need to be
>> addressed.
>> 
>> Suppose there are ten people who need to read mail sent to
>> [email-masked], how would this be handled without sharing the
>> private key, which for this example is prohibited by policy. As well any
>> of the ten support people need to be able to send messages that can be
>> later
>> verified as being from the individual sender and that the sender is a
>> member of the support role.
>
>I'm not sure how any attributes or extensions could solve this
>problem.  If a message is both encrypted and sent to a role address,
>then all ten individuals need to have access to the decrypted message.
>That can be done by sharing the role's encryption private key, or by
>having a proxy which decrypts the message and forwards it to the
>"support officer on duty".  Why should sharing the role encryption key
>be prohibited by policy, assuming that it's OK for all ten people to
>have 7x24 access to all incoming messages?
>
>OTOH, policy prohibits (or should prohibit) sharing of signing keys,
>so there is always individual accountability for outgoing messages.
>A signing proxy could be used to strip off the signer's individual
>identity on outgoing messages while maintaining audit records, or you
>could use 10 different signing certs with the same role name if external
>visibility of the signing key is not an issue.
>
>I believe that establishing a "[email-masked]" role is exclusively
>a key/cert management issue.  What changes/additions to S/MIME did you
>envision being needed?  What purpose would machine-readable message
>attributes serve in this application?
>
>
>From a usability standpoint I would have thought it was 
acceptable for a member of the support team to sign a message personally 
without the need for a proxy to re-sign a message. In my experience, while I 
may send a request to [email-masked] I am normally answered by 
[email-masked] and then enter a dialog with this person. In any case it is 
probably more practical for the proxy, if used, to simply counter sign the 
message and for both signatures to go out. I would imagine that this would be 
managed via proxy configuration rather than S/MIME extensions.

>> Also suppose the CEO of a company is on vacation and he wishes his EA to
>> check his mail. But the CEO's mail is not encrypted for his EA and he
>> doesn't want the EA to have access to his personal email that is
>> encrypted for the same address.
>
>Recipient-based access control (where the EA knows the CEO's private
>key but is on his honor not to read messages marked with a
>machine-readable "personal" attribute) is not a particularly secure
>solution. It would be possible to define a "personal/official" message
>flag that every sender would have to set appropriately, *and* rely on a
>trusted proxy to not forward personal messages to the EA.  But it seems
>much simpler to just use a role cert "Roger Smith, CEO" and a
>personal cert "Roger Smith" with different keys, and share just the
>role private key with the EA.  Human senders would select the
>appropriate certificate for personal or official messages based on the
>DN. What advantage would (machine-readable) message attributes have over
>(human-readable) DNs in this application?
>
>
>> Another feature the CEO wants is the ability to have his secretary draft
>> and address messages for him that he can later sign (without cutting and
>> pasting).
>
>What involvement should the S/MIME working group have in defining
>attributes to support workflow?  Message attributes such as Draft
>markings seem to be equally applicable to unprotected and protected
>messages, so the definition of such attributes seems more suited to a
>working group in the Applications area than one in the Security area.
>Workflow applications might need to understand normal S/MIME security
>features (such as wrapped and parallel signatures), but having the
>S/MIME WG define interoperablility specifications for workflow sounds
>like the tail wagging the dog.

I feel that there is a real need for some way to 
facilitate this type of processing. Perhaps we could introduce a keyusage 
identifier which indicates that a key is to be used for "recipients eyes 
only(personal key)" or " including delegated assistant(role key)" or "company 
email(company public email key)" this would allow/require multiple encryption 
keys to be stored in a certificate. I suppose that I am actually suggesting an 
enhancement to X509.  

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

Tel +44-171-500-6473
Fax +44-171-500-8880

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

--openmail-part-086fa699-00000001--

From: [email-masked]
Date: Tue, 29 Jun 1999 09:54:39 -0400
Subject: RE: Re:Charter Revision
To: [email-masked], [email-masked]
Sender: [email-masked]

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

-----Original Message-----
From: dpkemp [SMTP:[email-masked]]
Sent: Monday, June 28, 1999 5:49 PM
To: ietf-smime
Cc: dpkemp
Subject: Re:Charter Revision

> Date: Fri, 25 Jun 1999 16:48:59 -0400
> From: Larry Stoddard <[email-masked]>
> 
> I would like to suggest an additional item for the charter. Currently
> there is no support for addresses that are role based (ie
> [email-masked]). Here are some examples of problems that need to be
> addressed.
> 
> Suppose there are ten people who need to read mail sent to
> [email-masked], how would this be handled without sharing the
> private key, which for this example is prohibited by policy. As well any
> of the ten support people need to be able to send messages that can be
> later
> verified as being from the individual sender and that the sender is a
> member of the support role.

I'm not sure how any attributes or extensions could solve this
problem.  If a message is both encrypted and sent to a role address,
then all ten individuals need to have access to the decrypted message.
That can be done by sharing the role's encryption private key, or by
having a proxy which decrypts the message and forwards it to the
"support officer on duty".  Why should sharing the role encryption key
be prohibited by policy, assuming that it's OK for all ten people to
have 7x24 access to all incoming messages?

OTOH, policy prohibits (or should prohibit) sharing of signing keys,
so there is always individual accountability for outgoing messages.
A signing proxy could be used to strip off the signer's individual
identity on outgoing messages while maintaining audit records, or you
could use 10 different signing certs with the same role name if external
visibility of the signing key is not an issue.

[O'Malley, Bartley]  From a usability standpoint I would have thought it was 
acceptable for a member of the support team to sign a message personally 
without the need for a proxy to re-sign a message. In my experience, while I 
may send a request to [email-masked] I am normally answered by 
[email-masked] and then enter a dialog with this person. In any case it is 
probably more practical for the proxy, if used, to simply counter sign the 
message and for both signatures to go out. I would imagine that this would be 
managed via proxy configuration rather than S/MIME extensions.

I believe that establishing a "[email-masked]" role is exclusively
a key/cert management issue.  What changes/additions to S/MIME did you
envision being needed?  What purpose would machine-readable message
attributes serve in this application?

> Also suppose the CEO of a company is on vacation and he wishes his EA to
> check his mail. But the CEO's mail is not encrypted for his EA and he
> doesn't want the EA to have access to his personal email that is
> encrypted for the same address.

Recipient-based access control (where the EA knows the CEO's private
key but is on his honor not to read messages marked with a
machine-readable "personal" attribute) is not a particularly secure
solution. It would be possible to define a "personal/official" message
flag that every sender would have to set appropriately, *and* rely on a
trusted proxy to not forward personal messages to the EA.  But it seems
much simpler to just use a role cert "Roger Smith, CEO" and a
personal cert "Roger Smith" with different keys, and share just the
role private key with the EA.  Human senders would select the
appropriate certificate for personal or official messages based on the
DN. What advantage would (machine-readable) message attributes have over
(human-readable) DNs in this application?
[O'Malley, Bartley]   I feel that there is a real need for some way to 
facilitate this type of processing. Perhaps we could introduce a keyusage 
identifier which indicates that a key is to be used for "recipients eyes 
only(personal key)" or " including delegated assistant(role key)" or "company 
email(company public email key)" this would allow/require multiple encryption 
keys to be stored in a certificate. I suppose that I am actually suggesting an 
enhancement to X509.  

> Another feature the CEO wants is the ability to have his secretary draft
> and address messages for him that he can later sign (without cutting and
> pasting).

What involvement should the S/MIME working group have in defining
attributes to support workflow?  Message attributes such as Draft
markings seem to be equally applicable to unprotected and protected
messages, so the definition of such attributes seems more suited to a
working group in the Applications area than one in the Security area.
Workflow applications might need to understand normal S/MIME security
features (such as wrapped and parallel signatures), but having the
S/MIME WG define interoperablility specifications for workflow sounds
like the tail wagging the dog.

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

--openmail-part-086d88de-00000001--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-small-subgroup-01.txt
Date: Tue, 29 Jun 1999 08:02:19 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Methods for Avoiding the 'Small-Subgroup' Attacks on 
                          the Diffie-Hellman Key Agreement Method for S/MIME
	Author(s)	: R. Zuccherato
	Filename	: draft-ietf-smime-small-subgroup-01.txt
	Pages		: 8
	Date		: 28-Jun-99
	
In some circumstances the use of the Diffie-Hellman key agreement scheme
in a prime order subgroup of a large prime p is vulnerable to certain
attacks known as 'small-subgroup' attacks.  Methods exist, however, to
prevent these attacks.  This document will describe the situations
relevent to the S/MIME standard in which protection is required and the
methods that can be used to to prevent these attacks.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-small-subgroup-01.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 28 Jun 1999 12:48:37 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re:Charter Revision
To: [email-masked]
Content-MD5: 742WMilzWLh8lpEHQZt4tw==
Sender: [email-masked]

> Date: Fri, 25 Jun 1999 16:48:59 -0400
> From: Larry Stoddard <[email-masked]>
> 
> I would like to suggest an additional item for the charter. Currently
> there is no support for addresses that are role based (ie
> [email-masked]). Here are some examples of problems that need to be
> addressed.
> 
> Suppose there are ten people who need to read mail sent to
> [email-masked], how would this be handled without sharing the
> private key, which for this example is prohibited by policy. As well any
> of the ten support people need to be able to send messages that can be
> later
> verified as being from the individual sender and that the sender is a
> member of the support role.

I'm not sure how any attributes or extensions could solve this
problem.  If a message is both encrypted and sent to a role address,
then all ten individuals need to have access to the decrypted message.
That can be done by sharing the role's encryption private key, or by
having a proxy which decrypts the message and forwards it to the
"support officer on duty".  Why should sharing the role encryption key
be prohibited by policy, assuming that it's OK for all ten people to
have 7x24 access to all incoming messages?

OTOH, policy prohibits (or should prohibit) sharing of signing keys,
so there is always individual accountability for outgoing messages.
A signing proxy could be used to strip off the signer's individual
identity on outgoing messages while maintaining audit records, or you
could use 10 different signing certs with the same role name if external
visibility of the signing key is not an issue.

I believe that establishing a "[email-masked]" role is exclusively
a key/cert management issue.  What changes/additions to S/MIME did you
envision being needed?  What purpose would machine-readable message
attributes serve in this application?

> Also suppose the CEO of a company is on vacation and he wishes his EA to
> check his mail. But the CEO's mail is not encrypted for his EA and he
> doesn't want the EA to have access to his personal email that is
> encrypted for the same address.

Recipient-based access control (where the EA knows the CEO's private
key but is on his honor not to read messages marked with a
machine-readable "personal" attribute) is not a particularly secure
solution. It would be possible to define a "personal/official" message
flag that every sender would have to set appropriately, *and* rely on a
trusted proxy to not forward personal messages to the EA.  But it seems
much simpler to just use a role cert "Roger Smith, CEO" and a
personal cert "Roger Smith" with different keys, and share just the
role private key with the EA.  Human senders would select the
appropriate certificate for personal or official messages based on the
DN. What advantage would (machine-readable) message attributes have over
(human-readable) DNs in this application?

> Another feature the CEO wants is the ability to have his secretary draft
> and address messages for him that he can later sign (without cutting and
> pasting).

What involvement should the S/MIME working group have in defining
attributes to support workflow?  Message attributes such as Draft
markings seem to be equally applicable to unprotected and protected
messages, so the definition of such attributes seems more suited to a
working group in the Applications area than one in the Security area.
Workflow applications might need to understand normal S/MIME security
features (such as wrapped and parallel signatures), but having the
S/MIME WG define interoperablility specifications for workflow sounds
like the tail wagging the dog.

To: Graham Klyne <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Certificate requests for encryption keys 
Date: Sat, 26 Jun 1999 23:45:18 -0400
From: Dan Geer <[email-masked]>
Sender: [email-masked]

    >[...]   and since I'm pretty picky about 
    >doing things the way PKIX requires the only way they could get
    >self-issued certs to work is to make everyone a CA.
    
    Time for a dumb question, if I may.
    
    What is the problem with this?

My colleague Don Davis & I have discussed this as early as
1996, see http://world.std.com/~dtd/scca/smartcard_ca.ps

In my view, there is nothing wrong and much right...

--dan

Date: Sat, 26 Jun 1999 09:24:31 +0100
To: Larry Stoddard <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re:Charter Revision
Cc: [email-masked]
Sender: [email-masked]

At 16:48 25/06/99 -0400, Larry Stoddard wrote:
>I would like to suggest an additional item for the charter. Currently
>there is no support for addresses that are role based (ie
>[email-masked]). Here are some examples of problems that need to be
>addressed.

I know this isn't central to the issue you raised, but in case it has any
relevence, may I draw attention to RFC 2412:

                             MAILBOX NAMES FOR
                   COMMON SERVICES, ROLES AND FUNCTIONS

#g

------------
Graham Klyne
([email-masked])

Date: Fri, 25 Jun 1999 16:48:59 -0400
From: Larry Stoddard <[email-masked]>
To: [email-masked], Russ Housley <[email-masked]>
Subject: Re:Charter Revision
Sender: [email-masked]

I would like to suggest an additional item for the charter. Currently
there is no support for addresses that are role based (ie
[email-masked]). Here are some examples of problems that need to be
addressed.

Suppose there are ten people who need to read mail sent to
[email-masked], how would this be handled without sharing the
private key, which for this example is prohibited by policy. As well any
of the ten support people need to be able to send messages that can be
later
verified as being from the individual sender and that the sender is a
member of the support role.

Also suppose the CEO of a company is on vacation and he wishes his EA to
check his mail. But the CEO's mail is not encrypted for his EA and he
doesn't want the EA to have access to his personal email that is
encrypted for the same address. As well the CEO wants to delegate his
CEO signing authority to the COO for the duration of his vacation. 

Another feature the CEO wants is the ability to have his secretary draft
and address messages for him that he can later sign (without cutting and
pasting).

The above situations are most elegantly solved by defining S/MIME
extension(s) and a standard set of role attributes that support the
concept of role based messaging. By adding extensions to S/MIME to
support "draft messages", role signing authorities, and private
role-owner only messages, email developers will be able to create more
flexible mail solutions for large corporate and government users. Work
in PKIX on attribute certificates can be used for the role attributes
and support the delegation of role authority. 

Therefore I recommend that the smime WG charter include the
investigation of S/MIME extensions to support role based messaging and
standardization of role based messaging attributes and certificates that
are compliant with the attribute certificate work being done in PKIX.

Larry Stoddard
CFIOG IPC

[email-masked]

Date: Thu, 24 Jun 1999 13:12:14 -0600
From: "Tolga Acar" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Large attachment in S/MIME
Sender: [email-masked]

If I understand correctly, DER encoding should not be the problem, since DER/BER allows encoding of arbitrarily sized contents. There isn't a limit on length - well, there is, the content must be shorter than 2^(8*126)  - 1, i.e., 2^1008 - 1 bytes, inclusive. 
I believe "excessively large" does not imply such messages/attachments.

- Tolga

>Another problem we are trying to solve concerns very large file (or attachment
>when it is a message) in S/MIME. As the ContentInfo need to be DER encoded, it
>is not possible to process a buffer excessively large. What should be done in
>this case?

Date: Thu, 24 Jun 1999 14:44:34 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Large attachment in S/MIME
Cc: [email-masked]
Sender: [email-masked]

I assume that you want to use CMS, nor all of S/MIME.  I do not understand
what value the MIME encoding would provide in your application.

the contents of the encapsulatedContentInfo field do not need to be DER
encoded. Section 5.2 states this clearly.

Russ

At 05:11 PM 6/24/99 +0200, [email-masked] wrote:
>
>
>We are actually looking at using S/MIME in a file manager (Windows Explorer,
>...) but we are not aware of any RFC or drafts describing this process.
>Has anybody seen anything about this?
>
>Another problem we are trying to solve concerns very large file (or attachment
>when it is a message) in S/MIME. As the ContentInfo need to be DER encoded, it
>is not possible to process a buffer excessively large. What should be done in
>this case?
>
>Thanks for your help.
>

From: [email-masked]
To: [email-masked]
Date: Thu, 24 Jun 1999 17:11:19 +0200
Subject: Large attachment in S/MIME
Sender: [email-masked]

We are actually looking at using S/MIME in a file manager (Windows Explorer,
...) but we are not aware of any RFC or drafts describing this process.
Has anybody seen anything about this?

Another problem we are trying to solve concerns very large file (or attachment
when it is a message) in S/MIME. As the ContentInfo need to be DER encoded, it
is not possible to process a buffer excessively large. What should be done in
this case?

Thanks for your help.

From: Carlisle Adams <[email-masked]>
To: "Pawling, John" <[email-masked]>, "'Phillip M Hallam-Baker'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Charter Revision
Date: Tue, 22 Jun 1999 13:25:45 -0400
Sender: [email-masked]

Hi Phill,

> ----------
> From: 	Phillip M Hallam-Baker[SMTP:[email-masked]]
> Sent: 	Tuesday, June 22, 1999 10:57 AM
> To: 	Pawling, John; [email-masked]
> Subject: 	RE: Charter Revision
> 
> > 1) There is significant work being done in the ISO committees (i.e.
> FPDAM)
> > that will impact the X.509 Attribute Certificate syntax.  
> > Recommend that we
> > add the following text to the charter: "CMS imports the Attribute
> > Certificate syntax from X.509.  If the AC syntax is changed (as is
> > expected), then CMS will be enhanced to import the revised syntax."
> 
> This is definitely NOT a topic for S/MIME.
> 
> In the first place CMS should be importing semantics from PKIX, not
> X.509. 
 
Fair enough.  Note, however, that John did not suggest importing semantics
from X.509; he suggested importing syntax from X.509, which is the correct
thing to do.  This should lead to no conflict with what PKIX is doing
(recall what the "X" in PKIX stands for...).

> The approach S/MIME should take is to look to see what _functionality_
> it wants to add to S/MIME to solve _problems_. Simply adding technology
> for the sake of it is a very bad move.
> 
> The proper place to address attribute certificates would be either
> PKIX or more likely a new group focussed on some _use_ of attribute
> certificates. 
 
As John has pointed out, it has been envisioned from the start of the S/MIME
Working Group that Attribute Certificates might be the technology that makes
labeling of e-mail messages useful.  So what you're asking for above may be
precisely the reason that it is valuable to include the text that John
suggested...

Carlisle.

From: "Pawling, John" <[email-masked]>
To: [email-masked]
Subject: RE: Charter Revision
Date: Tue, 22 Jun 1999 11:12:45 -0400
Sender: [email-masked]

Phill,

I agree that the S/MIME WG should not duplicate the work of the PKIX WG.
The PKIX WG is the place to debate the use of ACs, not the S/MIME WG.
However, the existing CMS-13 I-D (soon to be an RFC) already imports the
1997 X.509 AC syntax (because it is anticipated that the originator's AC(s)
may need to be carried in the CMS security heading).  My point is that any
change away from the 1997 AC syntax is a change to CMS.

I believe that the PKIX WG's goal is to devise an AC strategy that is
consistent with X.509.  If the PKIX WG achieves that goal then it is
appropriate for CMS to import the AC syntax from X.509.  I believe that it
is premature to argue about "PKIX vs. X.509" because they should specify
identical syntaxes.

In summary, I still believe that my proposed text should be added to the
charter because there will be changes to CMS related to the AC syntax.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc.
[email-masked]
============================================

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Pawling, John" <[email-masked]>, <[email-masked]>
Subject: RE: Charter Revision
Date: Tue, 22 Jun 1999 10:57:21 -0400
Importance: Normal
Sender: [email-masked]

> 1) There is significant work being done in the ISO committees (i.e. FPDAM)
> that will impact the X.509 Attribute Certificate syntax.  
> Recommend that we
> add the following text to the charter: "CMS imports the Attribute
> Certificate syntax from X.509.  If the AC syntax is changed (as is
> expected), then CMS will be enhanced to import the revised syntax."

This is definitely NOT a topic for S/MIME.

In the first place CMS should be importing semantics from PKIX, not
X.509. S/MIME has not addressed PKI infrastructure issues up to this
point and I don't think it is a good time to start.

In the second place simply adding attribute certificates because they
have appeared in an ISO proposal seems a very bad plan. Lots of
ideas make it into ISO specifications that never make it into the
real world. 

The approach S/MIME should take is to look to see what _functionality_
it wants to add to S/MIME to solve _problems_. Simply adding technology
for the sake of it is a very bad move.

The proper place to address attribute certificates would be either
PKIX or more likely a new group focussed on some _use_ of attribute
certificates. I suspect however that a such a group would want to
consider other technologies as well (attributes stored in a
trusted directory, attributes embedded in an OCSP call, etc.).

		Phill

From: "Pawling, John" <[email-masked]>
To: [email-masked]
Subject: RE: Charter Revision
Date: Tue, 22 Jun 1999 10:00:02 -0400
Sender: [email-masked]

Russ,

Thank you for drafting the proposed charter.  I concur with the charter.  I
have a few minor comments:

1) There is significant work being done in the ISO committees (i.e. FPDAM)
that will impact the X.509 Attribute Certificate syntax.  Recommend that we
add the following text to the charter: "CMS imports the Attribute
Certificate syntax from X.509.  If the AC syntax is changed (as is
expected), then CMS will be enhanced to import the revised syntax."

2) Please list the Proposed Standards in the first paragraph so that one who
is unfamiliar with our work can distinguish the five base specs from the
list of S/MIME specs stored on the IETF web site. 

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc.
[email-masked]
============================================

Date: Mon, 21 Jun 1999 16:17:29 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Charter Revision
Sender: [email-masked]

I have finally taken all of the inputs that I received and combined them
with stuff that I made up out of thin air.  I had to do this because not
everyone sent in information about their plans.

Anyway, here is my proposed revised charter.  Please comment.

Russ

= = = = = = = = = = 

S/MIME Mail Security (smime)

Chair:
     Russ Housley <[email-masked]>

Security Area Director:
     Jeffrey Schiller <[email-masked]>
     Marcus Leech <[email-masked]>

Mailing Lists:
     General Discussion: [email-masked]
     To Subscribe:       [email-masked]
     Archive:            http://www.imc.org/ietf-smime/

Description of Working Group:

The S/MIME Working Group has completed five Proposed Standards that
comprise the S/MIME version 3 specification.  Current efforts build
on these base specifications.

The use of Diffie-Hellman Key Agreement as the mandatory to implement
key establishment mechanism may expose some implementations to 
vulnerabilities based on "small subgroup" attacks.  An informational 
document will be prepared describing techniques that can be used to 
avoid these attacks.

The Cryptographic Message Syntax (CMS) is cryptographic algorithm 
independent, yet there is always more than one way to use any algorithm.
To ensure interoperability, each algorithm should have a specification 
that decribes its use with CMS.  Specifications for the use of optional
cryptographic algorithms will be developed.

To aid implementers, documents containing example output for CMS will
be collected and published.  Some of the examples will include structures 
and signed attributed defined in the Extended Security Services (ESS) 
document.

Current methods of publishing certificates in the Directory do not 
allow the inclusion of secondary support information such as the 
SMimeCapabilities attribute.  A method of publishing certificates 
along with authenticated secondary support information will be 
defined. 

In some situations it would be advantageous for the CMS RecipiontInfo
structure to support additional key management techniques, including
cryptographic keys derived from passwords.  A mechanism to facilitate 
the definition of additional key management techniques will be defined.

S/MIME version 3 supports encrypted mail lists.  Specifications for the 
distribution of symmetric mail list keys to mail list agents (MLAs) and
message recipients will be developed.  The specification will be 
cryptographic algorithm independent.

S/MIME version 3 supports security labels.  Specifications that show 
how this feature can be used to implement an organizational security 
policy will be developed.  Security policies from large corporations will
be used as examples.

S/MIME version 3 can be used to protect electronic mail to and from a
domain.  In such an environment, S/MIME v3 processing is performed by 
message transfer agents, guards, and gateways in order to provide 
"Domain Security Services."  Mechanisms are needed to solve a number of 
interoperability problems and technical limitations that arise when  
domains supporting different security policies wish to interoperate.

The S/MIME Working Group will attempt to coordinate its efforts with the
OpenPGP Working Group in areas where the work of the two groups overlap.

Goals and Milestones:

History:
     First draft of small subgroup attack avoidance.
     First draft of certificate distribution specification.
     First draft of domain security services document.
     First draft of CMS and ESS examples document.
     First draft of KEA and SKIPJACK algorithm specification.
     First draft of IDEA algorithm specification.

July 1999:
     First draft of security label usage specification.

August 1999:
     Last call on small subgroup attack avoidance.
     Last call on KEA and SKIPJACK algorithm specification.

September 1999:
     First draft of CMS RecipiontInfo extension.
     First draft of mail list key distribution.
     Last call on certificate distribution specification.

November 1999:
     Updated draft of domain security services document.
     Last call on security label usage specification.
     Submit small subgroup attack avoidance as Informational RFC.
     Submit KEA and SKIPJACK algorithm specification as Informational RFC.

December 1999:
     Last call on CMS and ESS examples document.
     Last call on IDEA algorithm specification.
     Last call on CMS RecipiontInfo extension.

January 2000:
     Last call on mail list key distribution.
     Submit certificate distribution specification as a Proposed Standard.

February 2000:
     Submit security label usage specification as Informational RFC.

March 2000:
     Submit CMS and ESS examples document as Informational RFC.
     Submit IDEA algorithm specification as Informational RFC.
     Submit CMS RecipiontInfo extension as a Proposed Standard.
     Submit mail list key distribution as a Proposed Standard.

July 2000:
     Last call on domain security services document.

September 2000:
     Submit domain security services as Experimental RFC.

From: "Pawling, John" <[email-masked]>
To: "'SMIME WG'" <[email-masked]>
Subject: ESS Examples Document
Date: Mon, 21 Jun 1999 10:59:34 -0400
Sender: [email-masked]

All,

Recommend that the S/MIME WG should consider adding an "ESS Examples"
document to supplement the "Examples of CMS Message Bodies" document.
Propose that the "ESS Examples" document will include example hex encodings
of ESS attributes and signed receipt messages as well as to provide examples
of the MIME headings for triple-wrapped messages.  I believe that this
document would add significant value to ESS interoperability testing.  Paul
Hoffman, Director, Internet Mail Consortium, has graciously volunteered to
be the editor of the "ESS Examples" document.  If nobody objects to this
proposal, then I believe that the S/MIME WG charter should be expanded to
include the "ESS Examples" document.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc.
[email-masked]
============================================

Date: Mon, 21 Jun 1999 09:12:27 +0200
From: Michael Probst <[email-masked]>
To: Ivan Perez-Armendariz <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: email software that supports S/MIME security
Sender: [email-masked]

For general security development in Java and SSL (TLS soon) and S/MIME in
particular
also have a look at:

http://jcewww.iaik.tu-graz.ac.at/

(it's in/from Austria, Europe though, if that matters, but there should not be
any problems with
_im_porting strong cryptography, I suppose :-)

Ivan Perez-Armendariz wrote:

> Is there a list somewhere of email software that supports S/MIME security?
> So far, I've gathered that Microsoft Outlook and Netscape Communicator have
> support.  In addition, Worldtalk provides a S/MIME plug-in for Eudora.  Any
> information would be great.
>
> Thanks,
>
> Ivan Perez-Armendariz

--
Michael Probst        mailto:[email-masked]

PIRONET INTRANET AG        http://www.piro.net
Intranet-Division
Im Mediapark 5
50670 Koeln

Tel.:  +49 (0)221 454 3771
Fax:  +49 (0)221 454 3710

From: "Teiwes, Stephan (Ascom Systec AG)" <[email-masked]>
To: Ivan Perez-Armendariz <[email-masked]>, [email-masked]
Subject: AW: email software that supports S/MIME security
Date: Sun, 20 Jun 1999 13:38:27 +0200
Sender: [email-masked]

Hi there,

please, also consider Ascom iT_Sec's E-mail client product "IDEA@outlook"
which supports both S/MIME and PGP.
You will find more information on our web page http://www.ascom.com/infosec.
If you have any further question, don't hesitate and contact us.

Best wishes,

*Stephan Teiwes

----------------------------------------------------------------------------
|  Dr. Stephan Teiwes
|  IT Security Consultant
|  iT_Security AG, Ascom Systec AG 
|  Gewerbepark, CH-5506 Maegenwil
|  Phone: +41 (0)62 / 889 59 36 
|  Fax:      +41 (0)62 / 889 59 99
|  EMail: [email-masked] 
|
|  Information Security with IDEA@corporate products
|  http://www.ascom.com/infosec
----------------------------------------------------------------------------

From: [email-masked]
Date: Fri, 18 Jun 1999 19:19:41 -0400
To: <[email-masked]>, <[email-masked]>
Subject: Privacy
Content-Description: "cc:Mail Note Part"
Sender: [email-masked]

     Look at Lotus also, NotesMail supports S/MIME and has embedded, 
     user-friendly rsa-based encryption services for confidentiality and 
     authentication .

______________________________ Reply Separator _________________________________
Subject: email software that supports S/MIME security 
Author:  Ivan Perez-Armendariz <[email-masked]> at smtplink 
Date:    6/18/99 6:11 AM

Is there a list somewhere of email software that supports S/MIME security? 
So far, I've gathered that Microsoft Outlook and Netscape Communicator have 
support.  In addition, Worldtalk provides a S/MIME plug-in for Eudora.  Any 
information would be great.
     
Thanks,
     
Ivan Perez-Armendariz

Date: Fri, 18 Jun 1999 10:51:32 -0700
From: Jonathan Hawkins <[email-masked]>
Subject: Re: email software that supports S/MIME security
To: [email-masked]
Cc: Ivan Perez-Armendariz <[email-masked]>, [email-masked]
Reply-to: [email-masked]
Organization: Sun Microsystems - Network Solutions Group
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------F494CCFC7D458CF6C2D970B0
Content-Type: multipart/alternative;
 boundary="------------67E768111DE1A173B8087D0B"

--------------67E768111DE1A173B8087D0B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

RSA maintains a list of S/MIME enabled products on their
"S/MIME Central" webpage.  They have their own S/MIME Toolkit as well.

http://www.rsa.com/smime/

Jonathan

[email-masked] wrote:

> Lotus Notes R5 also supports S/MIME.
>
> David K. Hemsath, Team Lead (Security)
> SecureWay SysMgmt/Architecture/Standards
> IBM Corporation; 11400 Burnet Road; Austin, TX 78758 USA
> Tel.: +1(512)838-3618 T/L 678; Fax: 0156
> Pager: 800-946-4646/PIN=1400035/www.mobilecomm.com
> [email-masked]
>
> Ivan Perez-Armendariz <[email-masked]> on 06/18/99 08:11:53 AM
>
> To:   "[email-masked]'" <[email-masked]>
> cc:    (bcc: David Hemsath/Austin/IBM)
> Subject:  email software that supports S/MIME security
>
> Is there a list somewhere of email software that supports S/MIME security?
> So far, I've gathered that Microsoft Outlook and Netscape Communicator have
> support.  In addition, Worldtalk provides a S/MIME plug-in for Eudora.  Any
> information would be great.
>
> Thanks,
>
> Ivan Perez-Armendariz

--
-----------------------------------------------------------------
Jonathan T. Hawkins             Phone:  650-786-8889 (Sun x88889)
Network Solutions Group         Fax  :  650-786-9564
Sun-Netscape Alliance           Pager:  [email-masked]
=================================================================

--------------67E768111DE1A173B8087D0B
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>RSA maintains a list of S/MIME&nbsp;enabled products on their "S/MIME&nbsp;Central"&nbsp;webpage.&nbsp;
They have their own S/MIME&nbsp;Toolkit as well.
<p><A HREF="http://www.rsa.com/smime/">http://www.rsa.com/smime/</A>
<p>Jonathan
<br>&nbsp;
<p>[email-masked] wrote:
<blockquote TYPE=CITE>Lotus Notes R5 also supports S/MIME.
<p>David K. Hemsath, Team Lead (Security)
<br>SecureWay SysMgmt/Architecture/Standards
<br>IBM Corporation; 11400 Burnet Road; Austin, TX 78758 USA
<br>Tel.: +1(512)838-3618 T/L 678; Fax: 0156
<br>Pager: 800-946-4646/PIN=1400035/www.mobilecomm.com
<br>[email-masked]
<p>Ivan Perez-Armendariz &lt;[email-masked]> on 06/18/99 08:11:53 AM
<p>To:&nbsp;&nbsp; "[email-masked]'" &lt;[email-masked]>
<br>cc:&nbsp;&nbsp;&nbsp; (bcc: David Hemsath/Austin/IBM)
<br>Subject:&nbsp; email software that supports S/MIME security
<p>Is there a list somewhere of email software that supports S/MIME security?
<br>So far, I've gathered that Microsoft Outlook and Netscape Communicator
have
<br>support.&nbsp; In addition, Worldtalk provides a S/MIME plug-in for
Eudora.&nbsp; Any
<br>information would be great.
<p>Thanks,
<p>Ivan Perez-Armendariz</blockquote>

<pre>--&nbsp;
-----------------------------------------------------------------
Jonathan T. Hawkins&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp; 650-786-8889 (Sun x88889)
Network Solutions Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax&nbsp; :&nbsp; 650-786-9564
Sun-Netscape Alliance&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pager:&nbsp; [email-masked]
=================================================================</pre>
&nbsp;</html>

--------------67E768111DE1A173B8087D0B--

--------------F494CCFC7D458CF6C2D970B0
Content-Type: text/x-vcard; charset=us-ascii;
 name="Jonathan.Hawkins.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jonathan Hawkins
Content-Disposition: attachment;
 filename="Jonathan.Hawkins.vcf"

begin:vcard 
n:Hawkins;Jonathan
tel;work:650-786-8889
x-mozilla-html:FALSE
url:ironic.eng
org:<A HREF="http://www.sun.com">Sun Microsystems, Inc</A>;NSG <A HREF="http://www.sun.com/sims">Sun Internet Mail Server</A><IMG SRC="http://www.sun.com/sims/images/SUN_sims99-3.2-32.gif">
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;901 San Antonio Rd	=0D=0AMPK16-102			;Palo Alto;CA;95051;USA
x-mozilla-cpt:thestork.eng.sun.com;30376
fn:Jonathan Hawkins
end:vcard

--------------F494CCFC7D458CF6C2D970B0--

From: [email-masked]
To: Ivan Perez-Armendariz <[email-masked]>, [email-masked]
Date: Fri, 18 Jun 1999 11:50:45 -0500
Subject: Re: email software that supports S/MIME security
Sender: [email-masked]

Lotus Notes R5 also supports S/MIME.

David K. Hemsath, Team Lead (Security)
SecureWay SysMgmt/Architecture/Standards
IBM Corporation; 11400 Burnet Road; Austin, TX 78758 USA
Tel.: +1(512)838-3618 T/L 678; Fax: 0156
Pager: 800-946-4646/PIN=1400035/www.mobilecomm.com
[email-masked]

Ivan Perez-Armendariz <[email-masked]> on 06/18/99 08:11:53 AM

To:   "[email-masked]'" <[email-masked]>
cc:    (bcc: David Hemsath/Austin/IBM)
Subject:  email software that supports S/MIME security

Is there a list somewhere of email software that supports S/MIME security?
So far, I've gathered that Microsoft Outlook and Netscape Communicator have
support.  In addition, Worldtalk provides a S/MIME plug-in for Eudora.  Any
information would be great.

Thanks,

Ivan Perez-Armendariz

From: Ivan Perez-Armendariz <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: email software that supports S/MIME security
Date: Fri, 18 Jun 1999 06:11:53 -0700
Sender: [email-masked]

Is there a list somewhere of email software that supports S/MIME security?
So far, I've gathered that Microsoft Outlook and Netscape Communicator have
support.  In addition, Worldtalk provides a S/MIME plug-in for Eudora.  Any
information would be great.

Thanks,

Ivan Perez-Armendariz

Date: Mon, 14 Jun 1999 17:38:37 -0700
Subject: Back To Basics (Was "Re: Certificate requests for encryption keys")
From: "Aram Perez" <[email-masked]>
To: [email-masked], [email-masked]
Sender: [email-masked]

I've been away for a couple of weeks so I've read with great interest all 
the discussion on this subject. I'd like to add my comments, starting with
what Bob Jueneman wrote:

>This thread has engendered several interesting subthreads, but let's dispatch
>the first one, first.

I did not understand Bob's answer to what he called "the first one". I
thought what started this thread was that Ilan Shacham wrote:

>There has been much talk lately of using dual key pairs - one key pair
>for encryption, and one for signing.
>The following question arises - how does one create a certificate request
>for an encryption key pair? after all, the certificate request is signed by
>the key inside it, but the key is an encryption key, so this is illegal.

I'm assuming Ilan is talking about about the "Simple Enrollment Request"
from <draft-ietf-pkix-cmc-xx.txt> which based on a PKCS#10 message. PKCS#10
requires that "the certificate request is signed by the key inside it" and
thus his question. The "Full PKI Request" allows the request to "be signed
either by the private key material of the signature certification request,
or by a pre-existing signature key and certificate." I believe this
corresponds to Ilan's second solution. Ilan stated that this solution
provides "no Proof Of Posession of the encryption key". If I cannot attest
that a certificate request has my encryption public key with my signature,
of what use are digital signatures?

Also, I'm assuming that Ilan is talking about encryption keys used for key
management (key exchange, key wrapping, etc.) and not for encrypting data.
Hence Anne Anderson's comments about end-entities needing "to change
encryption keys frequently" does not make sense. The reason S/MIME uses
EnvelopedData is that is allows for a new *data encryption key* for every
message with a longer term *key management key*.

I agree with Bob Jueneman's position of having POP for the private key, but
I also agree with Terry Hayes' statement that even though Bob's suggestion
"is rather awkward", we should "Fix the operational level protocols
instead".

With respect to self-signed certificates, no matter what format (X.509, PGP,
SDSI, etc), whether it's from an end-entity or a CA, you have to verify it
out-of-band.

Regards,
Aram Perez

Date: Mon, 14 Jun 1999 17:48:26 -0400 (EDT)
From: "David M. Balenson" <[email-masked]>
To: [email-masked]
Subject: NDSS 2000 SUBMISSION DEADLINE EXTENDED TO JUNE 23RD
Sender: [email-masked]

The Internet Society's Year 2000 Network and Distributed System
Security Symposium (NDSS 2000) deadline for submissions of technical
paper and panel proposals has been EXTENDED TO JUNE 23RD due to
the large number of requests for an extension and the desire to
accomodate people.

The complete Call for Papers (CFP) is available at
http://www.isoc.org/ndss2000/.

Submissions are being accepted electronically at http://www.isi.edu/~ndss00.

-David Balenson, NDSS 2000 Publicity Chair

Date: Mon, 14 Jun 1999 09:37:31 -0400
To: Andrew Farrell <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Issues with S/MIME Message Specification 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>>Thanks for your comments.  I hadn't considered the possible difference 
>>in scope between the S/MIME Message Specification and the CMS, but I can 
>>see that CMS might have broader applicability, and hence, differing 
>>requirements.
>
>This is also the reason why there are, on close examination, no MUSTs
>or SHOULDs in CMS. 

Yes. CMS has many application beyond S/MIME.  We have already started to
see many other applications, including the PKIX CMC.

However, this is not the reason that I did not follow the MUST and SHOULD
conventions.  I tried to keep the document structure similar to PKCS#7
v1.5.  This way, someone who has a RKCS#7 v1.5 implementation might have an
easier time figuring out what changes were needed to implement CMS.

Russ

Date: Mon, 14 Jun 1999 11:35:17 +0100
To: [email-masked]
From: Graham Klyne <[email-masked]>
Subject: Re: Certificate requests for encryption keys
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 05:57 12/06/99, Peter Gutmann wrote:

>Since the distribution now includes new people (ietf-smime) I'll give the 
>Readers Digest version of what I said in an earlier message:

Thanks for that.

>[...]   and since I'm pretty picky about 
>doing things the way PKIX requires the only way they could get self-issued 
>certs to work is to make everyone a CA.

Time for a dumb question, if I may.

What is the problem with this?  Unless I'm missing something (likely :-),
being a CA is no big deal security-wise.  I don't see any special trust
conferred on that basis alone.

#g

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Certificate requests for encryption keys
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Date: Sat, 12 Jun 1999 05:57:32 (NZST)
Sender: [email-masked]

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

>>From: Paul Hoffman / IMC <[email-masked]>
>>
>>Exactly right. And, as Peter has pointed out yet again, there is a business
>>desire for "trust me after some out-of-band validation" certs that is so
>>strong, there are many examples IN USE TODAY of them. I'll trust him when
>>he says they are not interoperable; that certainly sounds likely to me.
>>
>>Telling these people "don't use PKIX" is silly. We want as many people
>>using PKIX as possible so that application vendors don't have to support
>>two different cert formats to hold keys that are being used in the same way.

>I'm confused about exactly what the "strong business desire" is for, and how 
>it relates to the proposed solutions.

Since the distribution now includes new people (ietf-smime) I'll give the 
Readers Digest version of what I said in an earlier message:

1. Free or low-cost certificate tools are becoming more and more widespread.
2. Businesses are using these more and more: "The software's free, we have
   the expertise to do it in-house, why do we need to pay a CA for it?"
   (Classical manglement thinking at work).

The problem with this approach is that X.509 doesn't define a format for:

1. A standalone end-entity certificate verified using out-of-band means.
2. An encryption-only cert signed with an end-entity signature-only cert
   verified via the usual CA mechanism.

Both of these results are what businesses are trying to do based on the
manglement thinking presented above, with the result that you end up with
whatever cert kludges are required by the toolkit they're using to make this
possible (eg everyone is a CA and signs their own certs, a single certificate
vending machine-type app is used to sign everyone's certs just to get the 
public key into X.509 format, someone is appointed to generate everyone's keys
for them so they can sign the public portion with a fixed CA cert before they 
send them out to the users(!!!), etc etc etc).

The result was a thread containing various ways to achieves this, with no
clear consensus being reached (several people had done it, but their ways
of doing it were all different).

>Here's a simple proposal, involving the addition of one signed attribute to 
>CMS section 11:

That's a nice way to do it using existing mechanisms, but it's almost but not 
quite completely unlike the required solution :-).  What people are trying to 
do is create certs managed through means other than the full CA 
infrastructure, and use the resulting certs (full certs, not just raw public 
keys) with web servers, in custom signing applications, in EDI software, and 
God knows what else (for example I know of one company who do a web-browser
plugin which signs data sent from the user back to a central server where 
noone's going to pay a CA for a cert when the entire app with an infinite-user
license sells for a few hundred dollars.  In this case they're going to set up
every user as a CA with their own self-signed CA cert, and the software is 
coded to treat them as EE certs.  The reason I know about this particular case
is that they're using my software to do it, and since I'm pretty picky about 
doing things the way PKIX requires the only way they could get self-issued 
certs to work is to make everyone a CA.  I don't know whether they've released 
this yet, but from talking to them in the past they're going to end up with a 
fair number of users, and there are many other companies doing things this way
as well).

As I see it, there are three options:

1. Define a format for the two cases described above and try and get 
   developers of toolkits and whatnot to stick with it, so that when people
   do employ these certs you can identify them and work with them as required
   (which could include just refusing to handle them if you feel so inclined).
2. Educate every IT person on the planet about the wonders of X.509 and
   convince them all to do it the way they're supposed to do it rather than in
   a way where they can ship a product as quickly and cheaply as possible.
3. Continue to ignore the issue and end up with an ever-increasing number of 
   homegrown kludges which at best won't interoperate with anything else and
   at worst will severely screw up any other software which tries to use it.

Peter.

Date: Fri, 11 Jun 1999 11:01:09 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Certificate requests for encryption keys
To: [email-masked]@ara.missi.ncsc.mil
Cc: [email-masked]@ara.missi.ncsc.mil
Content-MD5: w5LphXXmPJtyWof6sPduDw==
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
> 
> Exactly right. And, as Peter has pointed out yet again, there is a business 
> desire for "trust me after some out-of-band validation" certs that is so 
> strong, there are many examples IN USE TODAY of them. I'll trust him when 
> he says they are not interoperable; that certainly sounds likely to me.
> 
> Telling these people "don't use PKIX" is silly. We want as many people 
> using PKIX as possible so that application vendors don't have to support 
> two different cert formats to hold keys that are being used in the same way.

Paul,
  I think you're a nice guy too :-), but I'm confused about exactly what
the "strong business desire" is for, and how it relates to the proposed
solutions.

I believe this thread began with a desire to *NOT* do out-of-band
validation, but instead to leverage the assurance provided by X.509
identity certificates (and the Internet X.509 PKI or a closed/local
X.509 PKI) to validate encryption keys.  I'm certain that that is the
need expressed by Bill Burr.

I also believe that the need for encryption keys can be grouped into
two categories: protecting data at rest, and protecting data in
transit.  IPSEC/IKE is one mechanism for protecting data in transit,
which uses identity certificates and uncertified key establishment
keys.

This message addresses protecting data at rest, similarly using
an encryption key with assurance inherited from a certified identity
(an X.509 signature certificate). It does not require any out-of-band
operations on the encryption key. It assumes that the out-of-band
operations related to establishing trust in the signature key are
already in place.  Given that environment, it seems to me that it is
more appropriate to standardize a single mechanism and promote
interoperability in the data protection protocol - CMS - than in
the key certification infrastructure protocol - X.509.

Here's a simple proposal, involving the addition of one signed attribute
to CMS section 11:

----------------------------------------------------------------------

11  Useful Attributes
   ...

11.6  Public Key

  The PublicKey attribute type specifies a public key which can be
  referenced in lieu of X.509 certificates in the EnvelopedData content
  type.  This attribute is used to allow the message signer to specify
  a public encryption key to be used in enveloped messages sent
  to the signer.
  
  The following object identifier identifies the PublicKey attribute:
  
    id-publicKey OBJECT IDENTIFIER ::= { ... }
  
  PublicKey attribute values have ASN.1 type PublicKey:
    
    PublicKey ::= SEQUENCE {
      kid           SubjectKeyIdentifier,
      keyInfo       SubjectPublicKeyInfo  }

    SubjectPublicKeyInfo ::= SEQUENCE {    -- Copied or Imported from X.509
      algorithm     AlgorithmIdentifier,
      publicKey     BIT STRING  }

----------------------------------------------------------------------

Note that almost no other changes should be required to the CMS specification
to enable the use of keys instead of certificates:

Section 6.1: "originatorInfo optionally provides information about the
  originator.  It is present only if required by the key management
  algorithm."      (OriginatorInfo contains certs and CRLs.)
  
Section 6.2.1: 

    rid  EntityIdentifier,
   
  EntityIdentifier ::= CHOICE {
    issuerAndSerialNumber  IssuerAndSerialNumber,
    subjectKeyIdentifier   [0] SubjectKeyIdentifier  }

  "rid specifies the recipient's certificate or key that
   was used by the sender to protect the content-encryption key."

Change:
  "The EntityIdentifier is a CHOICE with two alternatives specifying the
  recipient's certificate, and thereby the recipient's public key."
  
to:
  "The EntityIdentifier is a CHOICE with two alternatives specifying the
  recipient's certificate or the recipient's public key."

Add a line to the table in ESS Section 1.3.4 specifying that the
PublicKey attribute MUST be signed, and may be either Inner or Outer
in a triple-wrapped message.

Date: Tue, 01 Jun 1999 20:11:05 -0400
To: "Bob Jueneman" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Issues with S/MIME Message Specification
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Bob:

I would like to see the specifications published as RFCs, then get some
implementation experience.  I believe that the most valuable spec changes
will result from implementaion experiences.  So, I would expec to wait a
few months before we query the working group for issues and proposed solutions.

Russ

At 04:05 PM 6/1/99 -0600, Bob Jueneman wrote:
>Russ, and others,
>
>I regret the timing of my remarks, which was unfortunate.  Although
>I had been following along the S/MIME discussions, it was not
>an area I was responsible for until very recently. I hope to be able to
>
>make more of a contribution in the future. Unfortunately, the fact that
>
>my comments came just after, rather than before the Last Call, was 
>viewed with distaste  by some, and perhaps understandably so.
>
>My concern for the apparently duplication of algorithm specifications
>was to prevent exactly the kind of unfortunate disagreement in
>specifications as occurred with the may/should for RSA signature,
>but I overlooked the fact that CMS is intended to have a broader scope
>than just the S/MIME specification, and that the S/MIME spec was
>picking and choosing a profile of algorithms from a larger set.
>
>Although I feel as strongly as most of the members of the IETF 
>regarding the need for strong cryptography, I do disagree with 
>the policy of mandating strong algorithms as a MUST, as I would 
>prefer to deal with such issues on the political, rather than as
>an issue for the standards community to deal with. I will address that
>
>issue with the IESG, as you requested, rather than burden the list.
>
>However, since S/MIME provides a way for one user to inform
>other correspondents of their preferred algorithms, the only practical
>implication (other than the not so trivial issue of specsmanship and 
>conformance) is the question of what is to be done as a default, 
>in the absence of prior knowledge.  But according to 2.7.1.3 (Rule 3,
>Unknown Capabilities, Unknown Version of S/MIME), the rule is
>that the sending agent SHOULD use triple-DES -- not MUST.
>I can live with that -- that gives the implementor leeway to
>have the user specify a default option, request notification, etc.
>
>On a different subject, can I ask you what the plan is for 
>entertaining further comments and/or proposed revisions to 
>either the S/MIME or CMS specification, prior to their 
>consideration as Draft Standard?  Will suggestion for revisions 
>be in order at some point in time, or is that decision expected 
>to be a straight up/down vote?
>
>Regards,
>
>Bob
>
>
>
>Robert R. Jueneman
>Security Architect
>Network Security Development
>Novell, Inc.
>122 East 1700 South
>Provo, UT 84606
>[email-masked]
>1-801-861-7387
>
>>>> Russ Housley <[email-masked]> 05/24/99 08:45AM >>>
>Bob:
>
>In CMS Section 12.3.2, RSA Key Management is a "should" implement
>algorithm.  As a result of an editorial error, in CMS Section 12.2,
>RSA
>Signature is a "may" implement algorithm.  I thought that they had the
>same
>"should" status.  This would be consistent with the MSG document.
>
>We went through great pains to include support many, many algorithms
>in
>CMS.  The  "must" implement algorithms to provide a set of
>interoperable
>strong algorithms.  The "should" implement algorithms provide backward
>compatibility with S/MIMEv2.  Any other algorithm is considered a
>"may"
>implement algorithm. RSA with OAEP falls into this "may" implement
>category.
>
>The IETF consistently includes strong algorithms in standards.  If you
>wish
>to discuss this policy, please discuss it in a broader context (not
>just
>S/MIME) with the IETF Security Area Directors (Jeff Schiller and
>Marcus
>Leech).  I have CCed them on this e-mail message, so you have their
>addresses.  I do not consider this an approprate topic for the S/MIME
>mail
>list.
>
>I wish you had raised this inconsistency during CMS and MSG Last Call. 
>The
>IESG has approved these documents.  I hope you will raise this topic
>again
>when the documents are considered for Draft Standard status.
>
>Russ
>  S/MIME WG Chair  &
>  CMS Document Editor
>

Date: Tue, 01 Jun 1999 10:44:37 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: CERTDIST Comments
Cc: [email-masked]
Sender: [email-masked]

--=====================_346546==_
Content-Type: text/plain; charset="us-ascii"

Jim:

I have embedded comments in the attached copy of CERTDIST.

After reading and commenting, I wonder if a general signed directory
attribute mechanism would be preferable.  Such a mechanis would allow any
attribute to be signed by the user for posting in his directory entry.  I
am not sure how searches would work in the directory with such an attribute.

The directory entry could contain many attributes:
	sMIMEcapabilities
	emailAddress
	userCertificate
	whateverElse
	signedAttributes
		SIGNED ( sMIMEcapabilities )
		SIGNED ( whateverElse )

Does this generalization make sence?

Russ
--=====================_346546==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="certdist-cmts.txt"

Internet Draft                                                Jim Schaad 
draft-ietf-smime-certdist-03.txt                               Microsoft 
February 25, 1999 
Expires in six months 

                 Certificate Distribution Specification 

Status of this memo 
      
  This document is an Internet-Draft and is in full conformance with all 
  provisions of Section 10 of RFC2026. Internet-Drafts are working 
  documents of the Internet Engineering Task Force (IETF), its areas, 
  and its working groups. Note that other groups may also distribute 
  working documents as Internet-Drafts. 
      
  Internet-Drafts are draft documents valid for a maximum of six months 
  and may be updated, replaced, or obsoleted by other documents at any 
  time. It is inappropriate to use Internet-Drafts as reference material 
  or to cite them other than as "work in progress." 
      
  To learn the current status of any Internet-Draft, please check the 
  "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 
  Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 
  munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 
  ftp.isi.edu (US West Coast). 
      
Abstract 
      
  Current methods of publishing certificates in directory services are 
  restricted to just certificates.  This document provides a method of 
  publishing certificates with secondary support information such as the 
  SMimeCapabilities attribute (containing bulk algorithm support) in a 
  way that is both authenticated and bound to a given certificate. 

RH> I think that we can make this a bit stronger.  How about:
When certificates are published in a Directory, the issuer signature
provides integrity and authentication of the certificate content.
However, other Directory attributes do not enjoy this same protection.
This document specifies a method of publishing certificates as well
as secondary attributes, such as SMimeCapabilities, with integrity
and authentication.

  This draft is being discussed on the "ietf-smime" mailing list.  To 
  join the list, send a message to <[email-masked]> with the 
  single word "subscribe" in the body of the message.  Also, there is a 
  Web site for the mailing list at <http://www.imc.org/ietf-smime>. 
 
1.   Introduction 
      
  This document discusses a new method of publishing certificates in a 
  directory to provide authenticated attributes as part of the 
  certificate publishing process.  This allows for the addition of 
  information such as the SMimeCapabilities attribute from [SMIME] which 
  contains information about the bulk encryption algorithms supported by 
  the End-Entity's cryptography module. 

RH> I suggest that we change the first sentence in the above paragraph
from "This document discusses a new method ..." to "This document 
specifies a method ..."

RH> I suggest that we change the last sentece in the above paragraph
from "... bulk encryption algorithms supported by the End-Entity's 
cryptography module." to "... cryptographic algorithms supported by 
the End-Entity."
     
  Section 2 discusses the current set of publishing methods available 
  for use, along with the benefits and restrictions of each method. 
  Section 3 covers the definition and properties of a 
  SMimeCertificatePublish object. 

RH> Please add a sentence about section 4.

  Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD 
  NOT are used in capital letters. This conforms to the definitions in 
  [MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help 
  make the intent of standards track documents as clear as possible. The 
  same key words are used in this document to help implementers achieve 
  interoperability. 

2.   Current Publishing Methods 
      
  There are several different ways to publish certificate information. 
  These methods include the userCertificate property in LDAP 
  directories, sending signed objects between users, and transport of 
  certificate files (either bare or as CMS degenerate signed objects). 
  Each of these methods has benefits and drawbacks.  Each of these 
  methods will now be briefly discussed. 

RH> Please change "property" to "attribute."  This change is needed in
the above paragraph and many of the following paragraphs too.

RH> Does "degenerate" help user understanding in this intro paragraph?
     
  A public directory may be used to distribute certificates.  LDAP 
  currently has the userCertificate property defined just for that 
  purpose.  The benefits of using a public directory are that a sender 
  may create an encrypted object for a recipient without first receiving 
  information (such as a signed message) from the recipient. Most public 
  directories currently only contain leaf certificates for individuals 
  in the directory entry for the individual.

RH> Can we delete " entry for the individual" ?

                                              While some directories, 
  such as X.500 directories, provide for a directory entry to contain 
  the CA certificate, this is not the case for all directories.  Outside 
  of the structure of an X.500 directory the problems associated with 
  chaining from the individual's certificate to the CA's directory entry 
  in order to obtain it's certificate is difficult to impossible.  This 
  leads to two drawbacks: First, the set of bulk algorithms supported by 
  the recipient is unknown.  

RH> Please change "bulk" to "cryptographic."  The SMimeCapabilities 
attribute also contains preferences regarding key management.  This
change is needed here ans several places later in the document.

                             Second, no additional certificates may be 
  carried which would help in validating the recipient's certificates. 

RH> Please change "carried" to "included."
     
  Using certificate files for certificate distribution has the benefit 
  of already being in wide spread use. (They are commonly used for 
  certificate distribution from Certificate Authorities either as part 
  of the enrollment protocol or from web based repositories.) 

RH> Please remove parens from previous sentnece.

                                                                  The 
  degenerate CMS signed object form, certificate files may carry a set 
  of certificates to allow a sender to validate the recipients 
  certificates.  However, they suffer from two drawbacks.  First, as 
  with the public directory, the additional information is not available 
  as part of the certificate file.  Second, the certificate is obtained 
  from either the recipient one is encrypting for or a third party (not 
  a directory). 

RH> I am not sure what you mean in the second drawback above.
     
  Using signed objects for certificate distribution has the benefit of 
  allowing additional information such as the SMimeCapabilities 
  attribute to be carried as part of the package.  It also allows for 
  the inclusion of additional certificates to be used in verifying the 
  encryption certificate used to build an encrypted object. However, it 
  has the drawback that the initialization process is done via a one-on-
  one process. 

3.   SMimeEncryptCerts 
 
  When publishing one's own encryption certificates, it is often 

RH> Can we say "key management" instead of "encryption" ?  If you agree,
this change is needed several other places too.

  advisable to publish a wide selection of certificates to insure 

RH> Please change "insure" to "ensure".

  maximum interoperability.  This section describes an attribute that 
  may be used to both identify the set of encryption certificates and 
  establish the set of bulk encryption algorithms supported by each of 
  the certificates. 
     
  The SMimeEncryptCerts attribute is used to identify one's own 
  encryption certificates to the other party.  This attribute is a 
  sequence so that more than one encryption certificate can be 
  identified in a single SignerInfo object.  Each certificate is then 
  given a set of capabilities so senders can identify the correct 
  certificate to use for specific capabilities. 
      
  The structure and OID for the SMimeEncryptCerts attribute are: 
     
    id-aa-smimeEncryptCerts OBJECT IDENTIFIER ::= { iso(1)  
         member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)  
         smime(16) id-aa(2) 13 } 
     
     SMimeEncryptCert ::= SEQUENCE { 
          hash           Hash, 
          capabilities   SMIMECapabilities 
     } 
     
     SMimeEncryptCerts ::= SEQUENCE OF SmimeEncryptCert 
     
     Hash ::= OCTET STRING - SHA1 hash of the certificate 

RH> I would like to see Hash be defined as a SEQUENCE of a hash algorithm
identifier (AlgorithmIdentifier) followed by the hash value (OCTET STRING).
     
  When a certificate appears in an SMimeEncryptCerts attribute, the 
  certificate MUST be included SignedData object.  The order of 
  certificates in the SMimeEncryptCerts attribute is the preferred order 
  of use by the sender.  It is expected that the preferred certificate 
  in the SMIMEEncrpytionKeyPreference would be the first certificate in 
  the SMimeEncryptCerts attribute. 
   
  If present, the SMimeEncryptCerts attribute MUST be an authenticated 
  attribute; it MUST NOT be an unauthenticated attribute. CMS defines 
  authenticatedAttributes as a SET OF AuthAttribute.  A SignerInfo MUST 
  NOT include multiple instances of the SMimeEncryptCerts attribute. CMS 
  defines the ASN.1 syntax for the authenticated attributes to include 
  attrValues SET OF AttributeValue. A SMimeEncryptCerts attribute MUST 
  only include a single instance of AttributeValue. There MUST NOT be 
  zero or multiple instances of AttributeValue present in the attrValues 
  SET OF AttributeValue. 

4.   SMimeCertificatePublish Object 
      
  The structure of the SMimeCertificatePublish object is defined in this 
  section.  This object has the benefit that it is published into a 
  directory service (and thus is available to all parties) and it
  contains a signed object that allows it to carry the additional 
  information desired to increase interoperability. 
     
  This section describes the LDAP directory schema, the body content and 
  additional restrictions on the attribute and signers of the SignedData 
  object used in publishing the user's certificate. 
     
  The ASN definition of a SMimeCertificatePublish object is the same a 
  CMS signed object. 
     
    SMimeCertificatePublish ::= ContentInfo 
     
  Where the contentType is id-signed-data and the content is a 
  SignedData content. 
     
  A SMimeCertificatePublish object MAY contain multiple SignerInfo 
  objects.  Each SignerInfo object is independent.  This document 
  imposes no restrictions on attributes that appear in more that one 
  SignerInfo object. 
 
4.1  Signed Content 
 
  The SMimeCertificatePublish object is explicitly designed to carry no 
  body content.  All information is carried in the signed attribute 
  section of the SignerInfo. 
     
  The following object identifier is used to distinguish the content of 
  a SMimeCertificatePublish: 
     
    id-ct-publishCert OBJECT IDENTIFIER ::=  { iso(1) member-body(2) 
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-ct(1) 
       3) 
     
  When creating a SMimeCertificatePublish object, the eContent of the 
  Signed-Data object is omitted and the eContentType OID is set to id-
  ct- publishCert.  

RH> Please spell out "OID."

RH> Please remove the spaces after the dashes.

                    Note this is different from an empty content, which 
  would be represented as an octet string containing zero bytes.  The 
  hash of the body (used in the id-message-digest attribute) is set to 
  the initialization value of the hash function.  (This is expected to 
  provide the same result as if you had hashed a body containing exactly 
  0 bytes.) 

RH> Please change "0 bytes" to "zero bits".
 
4.2  Signed Attributes 
 
  The signed attributes section MUST be present in the SignerInfo 
  object, and the following signed attributes MUST be present: The 
  signing-time attribute (from [CMS]), the SMimeCapabilities and 
  SMIMEEncryptionKeyPreference (from [SMIME]). 
 
4.3  CertificateSet 
 
  This draft imposes additional restrictions on the set of certificates 

RH> Please change "draft" to "specification."

  to be included in the SignedData object beyond those specified in 
  [CMS] and [SMIMECERT].  A chain of certificate from the end-entity
  certificate(s) to the root certificate(s) MUST be included in the 
  CertificateSet. Unlike in S/MIME messages the root certificate MUST be 
  included in the CertificateSet. The root certificate is included so 
  that end-entities have a better chance of finding and independently 
  verifying the trustworthiness of the root certificate based on its 
  content. 
     
  User agents MUST NOT automatically trust any root certificate found in 
  a SMimeCertificatePublish object. 

4.4 Signing Certificate 
 
  The SMimeCertificatePublish object MUST be signed by a signing 
  certificate associated with the end-entity, or a signing certificate 
  of a CA in the validation path of the encryption certificate. 
     
  Part of the process of extracting certificates involves comparing the 
  certificate found to the address matching the directory look-up.  The 
  validation SHOULD match the address used to look up the certificate 
  with one of the names found in the certificate.  Thus if an RFC822 
  name was used to do the directory look-up, the RFC822 name would be in 
  the SubjectAltName extension on the certificate. 

RH> Please add:  "Similarly, if an X.500 Distinguished Name was used to
do the directory look-up, the X.500 Distinguished Name would be in the
Subject field of the certificate."
     
  The steps for extracting the encryption certificate from a 
  SMimeCertificatePublish object are as follows: 
     
  1. Verify that the SMimeCertificatePublish object contains a valid 
    signature and the certificate used to sign the message can be 
    validated. 
   
  2. Does the certificate used to sign the SMimeCertificatePublish 
    object "match" the intended recipient of the encryption object?  If 
    so, proceed to step 6 else step 3. 
   
  3. Does the certificate referenced in the SMIMEEncryptionKeyPreference 
    attribute "match" the intended recipient of the encryption object?  
    If so, proceed to step 4, else stop with failure. 
 
  4. Validate the referenced encryption certificate. 
 
  5. Compare the signing certificate to the set of certificates used to 
    verify the encryption certificate.  Is the signing certificate in 
    the set of verification certificates?  If yes then the encryption 
    certificate has been located.  If no, no encryption certificate was 
    found. 
 
  6. Locate the encryption certificate using the 
    SMIMEEncryptionKeyPreference attribute in the signed attributes of 
    the SMimeCertificatePublish object. 
   
  In all cases, once an encryption certificate has been obtained, the 
  standard methods of validating signatures on the certificate and 
  checking for revocation MUST be followed.
 
4.5 LDAP Schema 
 
  After a SignedData object has been produced, it needs to be published 
  into one or more directories. This section describes the LDAP schema 
  used to support this. 
     
  A new LDAP attribute userSMimeCertificate is defined by this document. 
  The attribute is defined according to the syntax provided in [LDAPV3]. 
  The definition of this attribute is: 
     
    ( 1 2 840 113549 1 9 16 <TBD> 
      NAME    `userSMimeCertificate' 
      SYNTAX  `binary' 
      MULTI-VALUE 
      USAGE userApplications 
    ) 
     
  If the CA is the only entity that can write to the directory, it may 
  wish to provide some mechanism for updating the attributes such as the 
  smimeUserCapabilities in the published object. 
 
4.6 MIME Encoding 
 
  The application/pkcs7-mime-publish type is used to carry 
  SMimeCertificatePublish objects as mime objects.  The optional "name" 
  parameter SHOULD be emitted as part of the Content-Type field.  The 
  file extension for the file name SHOULD be ". p7p". 
 
A.  ASN Module 
 
  SMimeCertDistributionSyntax 
     { iso(1) member-body(2) us(840) rsadsi(113549) 
         pkcs(1) pkcs-9(9) smime(16) modules(0) <TBD> } 
   
    DEFINITIONS IMPLICIT TAGS ::= 
    BEGIN 
   
    -- EXPORTS All 
    -- The types and values defined in this module are exported for use 
    -- in the other ASN.1 modules.  Other applications may use them for 
    -- their own purposes. 
   
    IMPORTS 
    -- SMime Cryptographic Message Format 
       ContentInfo 
          FROM CryptographicMessageSyntax { iso(1) member-body(2)  
                  us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
                  modules(0) cms(1) } 
   
    -- SecureMimeMessageV3 
       SMIMECapabilities 
          FROM SecureMimeMessageV3 { iso(1) member-body(2) us(840)  
                  rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
                  smime(4)}; 
   
    -- S/MIME Object Identifier Registry 
    id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)  
              rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) } 
   
    -- Authenticated Attribute identifing Encryption Certificates 
    --   Value is a single SMimeEncryptCerts 
   
    id-aa-smimeEncryptCerts OBJECT IDENTIFIER ::= { id-smime id-aa(2) 13 
  } 
     
    SMimeEncryptCerts ::= SEQUENCE OF SMimeEncryptCert 
   
    SMimeEncryptCert ::= SEQUENCE { 
        hash           Hash, 
        capabilities   SMIMECapabilities 
    } 
     
    Hash ::= OCTET STRING -- SHA1 hash of the certificate 
   
    -- Content Type of Certificate publish message. 
    --   Signed content is detatched and empty 
    id-ct-publishCert OBJECT IDENTIFIER ::=  { id-smime id-ct(1) 3 } 
     
    SMimeCertificatePublish ::= ContentInfo 
   
  END -- of SMimeCertDistributionSyntax 
      
B.  Backwards Compatibility 
      
  The SMimeCertificatePublish object is based on work previously done at 
  both Microsoft and Netscape. 
     
  Both of these companies have implemented a version of 
  userSMimeCertificate in their mail LDAP directory structures. 
  Microsoft has also put the property into its MAPI based directory 
  schema. 
     
  Both companies use a ContentInfo object containing a SignedData object 
  with one SignerInfo object.  In both cases however the eContent is 
  tagged with id-data not id-ct-publishCert.  The actual content is 
  omitted from the SMimeCertificatePublish object. 
     
  In the case of both companies, clients who implement this feature 
  require that the end-entity is the signer of the object; the CA is not 
  permitted to sign and publish the object. 
   
  Microsoft has also produced an early version of the SMimeEncryptCerts 
  attribute. The syntax for this structure is 
   
   id-Microsoft-SMimeEncryptCert OBJECT IDENTIFIER ::= {1 3 6 1 4 1 311 
  16 4}

   Microsoft-SMimeEncryptionert ::= IssuerAndSerialNumber 
   
  A description of IssuerAndSerialNumber can be find in [CMS]. 
   
C.   Registration of MIME 
 
  To: [email-masked] 
  Subject: Registration of MIME media type application/pkcs7-mime-
  publish 
     
  MIME media type name: application 
     
  MIME subtype name: pkcs7-mime-publish 
     
  Required parameters: none 
  Optional parameters: name, filename 
     
  Encoding considerations: Will be binary data, therefore should use 
  base-64 encoding 
     
  Security considerations: There is no requirement for additional 
  security mechanisms to be applied at this level. The required 
  mechanisms are designed into the SMimeCertificatePublish content. 
     
  Interoperability considerations: - 
     
  Published specification: this document 
     
  Applications that use this media type: Secure Internet mail and other 
  secure data transports. 
     
  Additional information: 
    File extension (s): p7p 
    Macintosh File Type Code (s): - 
     
  Person and email address to contact for further information: Jim 
  Schaad, [email-masked] 
     
  Intended usage: COMMON 
      
D.   Open Issues 
   
  - Need Example Message 
      
References 
  CMS     "Cryptographic Message Syntax", Internet Draft ietf-draft-
  smime-cms 
   
  MUSTSHOULD "Key words for use in RFCs to Indicate Requirement Levels", 
          RFC 2119 

  LDAPV3  "Lightweight Directory Access Protocol (v3): Attribute Syntax 
          Definitions", RFC 2252 
   
  SMIME   "S/MIME Version 3 Message Specification", Internet Draft ietf-
  draft-smime-msg 
   
  SMIMECERT "S/MIME Version 3 Certificate Handling", Internet Draft 
            ietf-draft-smime-cert 
      
Security Considerations 
 
  Something goes here about making sure that you have the correct 
  certificate and that no substitutions are done when getting 
  certificates and information from the directory service. 
      
Author Address 
 
  Jim Schaad 
  Microsoft 
  One Microsoft Way 
  Redmond, WA 98052-6399 
  [email-masked] 

--=====================_346546==_--

Date: Tue, 01 Jun 1999 10:53:44 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: S/MIME WG meeting slots in Oslo
Sender: [email-masked]

S/MIME is tentatively scheduled as follows:

	Thursday, July 15 at 1530-1730
		other groups scheduled at that time: ipngwg

Please submit agenda requests for this meeting to me as soon as possible.

Thanks,
   Russ
   S/MIME WG Chair

Date: Tue, 01 Jun 1999 16:05:13 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Issues with S/MIME Message Specification
Sender: [email-masked]

Russ, and others,

I regret the timing of my remarks, which was unfortunate.  Although
I had been following along the S/MIME discussions, it was not
an area I was responsible for until very recently. I hope to be able to 
make more of a contribution in the future. Unfortunately, the fact that 
my comments came just after, rather than before the Last Call, was 
viewed with distaste  by some, and perhaps understandably so.

My concern for the apparently duplication of algorithm specifications
was to prevent exactly the kind of unfortunate disagreement in
specifications as occurred with the may/should for RSA signature,
but I overlooked the fact that CMS is intended to have a broader scope
than just the S/MIME specification, and that the S/MIME spec was
picking and choosing a profile of algorithms from a larger set.

Although I feel as strongly as most of the members of the IETF 
regarding the need for strong cryptography, I do disagree with 
the policy of mandating strong algorithms as a MUST, as I would 
prefer to deal with such issues on the political, rather than as
an issue for the standards community to deal with. I will address that 
issue with the IESG, as you requested, rather than burden the list.

However, since S/MIME provides a way for one user to inform
other correspondents of their preferred algorithms, the only practical
implication (other than the not so trivial issue of specsmanship and 
conformance) is the question of what is to be done as a default, 
in the absence of prior knowledge.  But according to 2.7.1.3 (Rule 3,
Unknown Capabilities, Unknown Version of S/MIME), the rule is
that the sending agent SHOULD use triple-DES -- not MUST.
I can live with that -- that gives the implementor leeway to
have the user specify a default option, request notification, etc.

On a different subject, can I ask you what the plan is for 
entertaining further comments and/or proposed revisions to 
either the S/MIME or CMS specification, prior to their 
consideration as Draft Standard?  Will suggestion for revisions 
be in order at some point in time, or is that decision expected 
to be a straight up/down vote?

Regards,

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> Russ Housley <[email-masked]> 05/24/99 08:45AM >>>
Bob:

In CMS Section 12.3.2, RSA Key Management is a "should" implement
algorithm.  As a result of an editorial error, in CMS Section 12.2, RSA
Signature is a "may" implement algorithm.  I thought that they had the same
"should" status.  This would be consistent with the MSG document.

We went through great pains to include support many, many algorithms in
CMS.  The  "must" implement algorithms to provide a set of interoperable
strong algorithms.  The "should" implement algorithms provide backward
compatibility with S/MIMEv2.  Any other algorithm is considered a "may"
implement algorithm. RSA with OAEP falls into this "may" implement category.

The IETF consistently includes strong algorithms in standards.  If you wish
to discuss this policy, please discuss it in a broader context (not just
S/MIME) with the IETF Security Area Directors (Jeff Schiller and Marcus
Leech).  I have CCed them on this e-mail message, so you have their
addresses.  I do not consider this an approprate topic for the S/MIME mail
list.

I wish you had raised this inconsistency during CMS and MSG Last Call.  The
IESG has approved these documents.  I hope you will raise this topic again
when the documents are considered for Draft Standard status.

Russ
  S/MIME WG Chair  &
  CMS Document Editor