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

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Sat, 3 Oct 1998 21:47:19 -0700

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 06 Oct 1998 11:49:57 -0400

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