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

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Thu, 1 Oct 1998 16:56:35 -0700

Although it was originally planned that the signing certificate attribute
would be folded back into the CMS draft, the decision of the various authors
involved was that we would put the draft into ESS for a variaty of reasons:

1.  It was felt by all involved that keeping the description text on what
was being solved and how it was being solved was desirable.  This would be
counter to the way that attributes are currently described in the CMS draft.

2.  Since there was some discussions on the draft and changes were still
being made, it was not felt desirable that the CMS draft be put at risk by
this change occuring.

3.  There was discussion about the need to put this into CMS.  The attribute
really goes with the idea of ESS giving ENHANCED security rather than this
attribute being required for really having any security.  I do no like the
idea that you seem to be suggesting that other groups look only at the CMS
draft for their work.  They should be looking at the range of work we are
doing.  The concepts in ESS are not restricted to S/MIME by any stretch of
the imagnination.

With regards to the new attribute that you desire, I do not know of any
draft authors currently taking this under consideration.  If you want to see
this incorperated into a draft please specify what draft it should be in and
give suggested text on how the attribute should be structured and treated.
While there has been general discussion on the scope of counterSignatures I
don't think the idea of a new attribute has ever really be under
consideration.

jim schaad

-----Original Message-----
From: Francois Rousseau [mailto:[email-masked]]
Sent: Thursday, October 01, 1998 9:04 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-ess-08.txt

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]

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

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 02 Oct 1998 10:25:34 -0700

Jim,

I am supportive of the comment made by Francois about the inclusion of the new
section 5 in CMS. More explanations follow.

> counter to the way that attributes are currently described in the CMS draft.

Having a bigger "security consideration" section in CMS would solve the problem.
The current section is rather small and could certainly be enhanced. This is the
natural place for such a wording.

> being made, it was not felt desirable that the CMS draft be put at risk by

During the last meeting in Chicago I raised the issue of some changes needed
into it  I recently sent a message on this topic.

> attribute being required for really having any security.

The Attribute specification addresses two separate items:

1) the addition of a (single) user (identity) certificate,
2) the inclusion of attribute certificates.

While it is true that attribute certificates are not mandated and give enhanced
capabilities, the inclusion of the signed (single) user (identity) certificate
is there precisely to address some security issues discussed at length in the
document. The addition of a (single) user (identity)certificate is REQUIRED
security for many (but not all) contexts. The inclusion of attribute
certificates in CMS is desirable: this is a "useful attribute".

> I do no like the

The current title of ESS-08 is "Enhanced Security Services for S/MIME". It is
not "Enhanced Security Services" and I think the current title is appropriate.
So ESS *is* restricted to S/MIME. On the other hand, many people are considering
using CMS outside the context of S/MIME. They are not going to look at a
document like ESS (that is S/MIME specific). CMS is seen as a
replacement/enhancement of PKCS#7 and will be used by many applications. It is
therefore important that people looking ONLY at this specification find all the
information needed including the security consideration issues that currently
come with the section about attributes certificates.

Regards,

Denis

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 02 Oct 1998 10:02:14 -0700

>into it  I recently sent a message on this topic.

Exactly. This is a very good reason not to put these into CMS: we really,
really don't want to hold it up.

>So ESS *is* restricted to S/MIME.

I believe you are being way too literal here. "for S/MIME" does *not* mean
"only for S/MIME". The IETF has a long history of protocol X using parts
(or all) of protocol Y, even when they are in very different areas of the
Internet. Anyone is free to use any part of the ESS draft for any purpose.
That's the way we do things in the IETF.

>On the other hand, many people are 
>considering
>document like ESS (that is S/MIME specific).

Why not? If they want to only look at one document, fine, but that's their
problem, not ours. Good protocol designers will look to a variety of
sources for information.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Francois Rousseau <[email-masked]>
Date: Fri, 02 Oct 1998 16:24:50 -0400

Since I did not attend the last meeting in Chicago, I just wanted to
suggest that I though it would be more appropriate to add this new ESS
section 5 on "Signing Certificate Attribute" in CMS instead of ESS.
However, I do agree that CMS should not be held up because of this.

Instead, could a forward pointer be added in Section 11 of CMS to these
other useful attributes that are only defined in ESS?

This would result in the following changes to Section 11 of CMS:

OLD: "This section defines attributes that may used with signed-data or
authenticated-data.  Some of these attributes were originally defined in
PKCS #9 [PKCS #9], others are defined and specified here.  The attributes
are not listed in any particular order."

NEW: "This section defines attributes that may be used with signed-data or
authenticated-data.  Some of these attributes were originally defined in
PKCS #9 [PKCS #9], others are defined and specified here.  Additional
attributes are defined in the Enhanced Security Services for S/MIME [ESS],
which also include recommendations on their placement.  The following
attributes are not listed in any particular order."

[ESS] would also have to be defined in the "References" Section of CMS.

Francois Rousseau
AEPOS Technologies

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 02 Oct 1998 17:11:49 -0700

>attributes are not listed in any particular order."

I belive that this would pass muster as a "non-normative" reference,
meaning that CMS would not be held up by ESS; I like that. However, I think
we should mention the MSG spec as well, since signingTime and
smimeCapabilities are also important attributes. Thus, I would change the
sendtence added to read:

Additional attributes are defined in many places, notably the S/MIME
Version 3 Message Specification [MSG] and the Enhanced Security Services
for S/MIME [ESS], which also include recommendations on the placement of
these attributes.

--Paul Hoffman, Director

---

From: Russ Housley <[email-masked]>
Date: Tue, 06 Oct 1998 13:37:09 -0400

This paragraph was added to section 11 in CMS.

Russ