ietf-smime
[Top] [All Lists]

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

1998-10-06 12:13:54
All:

I would not like to see CMS delayed waiting for a trusted signing time.
Trusted time stamps are an activity that PKIX is considering adding to
their charter.  If this gets sorted out, then we can apply their mechanism.

Russ

At 09:47 PM 10/3/98 -0700, Jim Schaad (Exchange) wrote:
Denis,



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.

This idea almost scares me.  If we fold this type of detail into the
security considerations section of CMS, I can envision that the section is
going to end up being 20 pages long.  It would need to detail every attack
that can possibly be envisioned along with a response to the attack.  This
is the type of thing which makes for a new draft not a  modification to the
security considerations section.  Security considerations in my opinion
should give enough information to make users aware of some of the most
drastic problems that can occur, but not offering full solutions on steps
they should be taking to solve the problems.

I can support the type of change that was suggested by Francois Rousseau in
making a reference to the ESS draft (although I think that since it has a
reference name it may end up being held up in order to get the reference
correct at a later date).   I don't think that CMS should be considered the
final answer on all security problems by any group including ourselfs.


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

Yes, it is required from SOME contexts.  This is percisely what I meant when
I said it is an ENHANCED service.  It is not required by everyone, just
those that need the enhanced service.  I don't think that anybody can really
make a statement that given today's technology the same could be said about
signing time or counter signatures.  These items are included in CMS more
for the fact that they were defined by PKCS#7 than for any other reason.
These attributes could just as easily have been moved into the ESS draft
except for the fact that a primary consideration of CMS was to make sure it
could to everything that PKCS#7 did.

jim