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

From: [email-masked]
Date: Wed, 21 Oct 1998 10:07:21 -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-09.txt
	Pages		: 35
	Date		: 20-Oct-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-09.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-ess-09.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-09.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: Wed, 21 Oct 1998 16:09:32 -0400

In a previous message I have suggested the addition of a
"counterSignatureScope" attribute in ESS to explicitly indicate whether or
not the countersigning process has validated the original content. This new
attribute could address concerns raised by various people under this
mailing list. Dr. Steve Henson has even proposed some minor
modifications/expansions to this counterSignatureScope attribute to make it
more precise.

Further to my original message and to address another non-repudiation
concern, I would also like to see if there is an interest in generalizing
such an attribute in order to also effectively define the scope of a
standard digital signature. 

It is my understanding that under the German digital signature law, before
a private key can be used to digitally sign something, every usage of the
key requires a new card holder verification. To accommodate this
requirement there is currently a plan for extending PKCS#11 with new
functions and a new attribute. The intention is that a PIN would be needed
each time the private key is being used. However, for reliable
non-repudiation, there are no means to indicate that such a verification of
the PIN was performed under the current signed data syntax of CMS. The
counterSignatureScope attribute could be generalized/expanded in a
"signatureScope" attribute to also address this scenario and possibly others.

Any thoughts?

Francois Rousseau
AEPOS Technologies

---

From: Dr Stephen Henson <[email-masked]>
Date: Sat, 24 Oct 1998 17:56:11 +0100

> "signatureScope" attribute to also address this scenario and possibly others.

I'm not sure I follow this. If the "signatureScope" is meant to be a
signed attribute and signed by the signer then it would not be
trustable: any certificate (whether the verification was performed or
not) could include any value they wanted.

There are several possible alternatives. One is an indicator in the
signer's certificate (or issuing CA): since this is signed by the CA it
would be trustable, but that makes it a PKIX issue. This might add a
complication to the S/MIME chain verification in some cases.

Alternatively a countersigner could verify that the siging certificate
was valid for this purpose and include a bit in the proposed
counterSignatureScope signed attribute. This adds the complication that
the client would need to trust the counter signing authority as a "proxy
chain verifier". 

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.

---

From: Francois Rousseau <[email-masked]>
Date: Mon, 26 Oct 1998 12:51:52 -0500

I do not think that this issue, which I raised in my previous message on a
"signatureScope" attribute, of how "private keys" are used, which I will
call a "Secure Sign" issue, can be resolved with public-key certificates.

The "Key Usage" extension from PKIX-1 may indicate the purpose of the
public key contained in the certificate. The selection of the
"digitalSignature" bit does not indicate how the private key is used in a
particular case, but only that it can be used to performed digital
signatures. Similarly the "Extended Key Usage" extension from PKIX-1 may
indicate one or more purposes for which the certified public key may be
used, in addition to or in place of the basic purposes indicated in the key
usage extension field. It still does not indicate how the private key is
used in a particular case. Similarly the "Certificate Policies" extension
from PKIX-1 may contain a sequence of one or more policy information terms,
each of which consists of an object identifier (OID) and optional
qualifiers. These policy information terms indicate the policy under which
the certificate has been issued and the purposes for which the certificate
may be used. It still does not indicate how the private key is used in a
particular case. Although the "Signing Certificate" attribute from ESS
allows to bind under the signature of the sequence of policy IDs from the
"Certificate Policies" extension from PKIX-1, it still does not address how
the private key is used in a particular case.

Indeed this is an issue with indicating HOW a "private key" is used to
digitally sign things in particular instances and not with its related
public-key certificate. This should only be reflected in each particular
digitally signed thing. However, there are currently no means under CMS
and/or ESS to indicate under what circumstances a "private key" was used to
perform a particular digital signature. Ultimately, unless the
cryptographic module performing such a "secure sign" function could append
this "signatureScope" attribute on its own, I agree with Dr. Henson that
there will always be a trust issue with the user/application including such
an attribute. 

Any more thoughts?

Francois Rousseau
AEPOS Technologies

Dr Stephen Henson wrote:
>
>I'm not sure if I follow this. If the "signatureScope" is meant to be
>a signed attribute and signed by the signer then it would not be
>Alternatively a countersigner could verify that the signing certificate

---

From: Dr Stephen Henson <[email-masked]>
Date: Mon, 26 Oct 1998 19:52:09 +0000

> the private key is used in a particular case.

I think the problem is that with current crypto hardware it is difficult
to find some reliable way to say how a private key was used in a
"particular case". 

My suggestion was meant to imply that the certificate could contain some
indication saying that the private key can *only* be used in this way.

This would mean in practice that a CA would include this flag in an end
user certificate if the certificate was part of some hardware that
always required the PIN to be entered for each signature. Either
extended key usage or policy could be used for this purpose.

Trying to handle both cases (PIN entered on each signing and PIN only
entered once initially) with the same private key and certificate
present considerable problems considering how simple most "smart card"
technology currently is. In practice it would be much more easily
handled just using separate keys and certificates.

Steve.