Subject: I-D ACTION:draft-ietf-smime-ess-08.txt

From: [email-masked]
Date: Thu, 01 Oct 1998 10:22:43 -0400

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		: Enhanced Security Services for S/MIME
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-ess-08.txt
	Pages		: 31
	Date		: 30-Sep-98
	
This document describes three optional security service extensions for
S/MIME. These services provide functionality that is similar to the Message
Security Protocol [MSP4], but are useful in many other environments,
particularly business and finance. The services are:
 - signed receipts
 - security labels
 - secure mailing lists
 
The services described here are extensions to S/MIME version 3 [SMIME3],
and some of them can also be added to S/MIME version 2 [SMIME2]. The
extensions described here will not cause an S/MIME version 3 recipient to
be unable to read messages from an S/MIME version 2 sender. However, some
of the extensions will cause messages created by an S/MIME version 3 sender
to be unreadable by an S/MIME version 2 recipient.
 
The format of the messages are described in ASN.1:1988 [ASN1-1988].
 
This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to:
     [email-masked]
with the single word
     subscribe
in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>.

Internet-Drafts are 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-ess-08.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-ess-08.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-ess-08.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.

---

From: Francois Rousseau <[email-masked]>
Date: Thu, 01 Oct 1998 12:03:45 -0400

Paul,

In this updated version 8 of ESS, I have noticed that the previous work of
Jim Schaad on the "Signing Certificate Attribute Specification" has been
integrated as part of a new Section 5 on the "Signing Certificate
Attribute". The signingCertificate attribute is also listed as one of the
permitted attribute in a counterSignature attribute in Section 1.3.4 of ESS.

However, since countersignatures will be used more widely than just within
S/MIME and the signingCertificate attribute could also be used with normal
signatures, should not this new Section 5 of ESS have been integrated
within CMS instead?

In addition, is there anything done to create a new attribute that would
also be allowed in a counterSignature attribute in order to effectively
define its scope (e.g. content was or was not verified against the message
digest before generating the countersignature)?

Francois Rousseau
AEPOS Technologies
Tel: (819) 772-8522 Ext 314
Fax: (819) 772-0449
[email-masked]

---

From: Dr Stephen Henson <[email-masked]>
Date: Fri, 02 Oct 1998 02:08:45 +0100

> digest before generating the countersignature)?

I recall mentioning this as a possible way to make it easier for a
client to know if a countersigner has verified the original content.

There are various other ways of dealing with this which don't need an
additional attribute. One is to treat it in an analagous manner to other
signatures and judge the validity of the certificate based on the
signing authority: or more specifically its policy.

In the case of some timestamping servers the certificates have specific
V3 extensions: extendedKeyUsage. I can't comment on how universal this
is.

In a human readable environment the actual name of the countersigning
authority could help avoid confusion: for example a message saying
"countersigned by 'foobar timestamping authority' on HH:MM".

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.