I am supportive of the comment made by Francois about the inclusion of the new
section 5 in CMS. More explanations follow.
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.
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.
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.
During the last meeting in Chicago I raised the issue of some changes needed
into it I recently sent a message on this topic.
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.
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
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 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.
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
From: Francois Rousseau [mailto:f(_dot_)rousseau(_at_)adga(_dot_)ca]
Sent: Thursday, October 01, 1998 9:04 AM
Subject: Re: I-D ACTION:draft-ietf-smime-ess-08.txt
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)?
Tel: (819) 772-8522 Ext 314
Fax: (819) 772-0449
A New Internet-Draft is available from the on-line Internet-Drafts
This draft is a work item of the S/MIME Mail Security Working Group of the
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.