Subject: RE: Charter Revision

From: "Pawling, John" <[email-masked]>
Date: Tue, 22 Jun 1999 10:00:02 -0400

Russ,

Thank you for drafting the proposed charter.  I concur with the charter.  I
have a few minor comments:

1) There is significant work being done in the ISO committees (i.e. FPDAM)
that will impact the X.509 Attribute Certificate syntax.  Recommend that we
add the following text to the charter: "CMS imports the Attribute
Certificate syntax from X.509.  If the AC syntax is changed (as is
expected), then CMS will be enhanced to import the revised syntax."

2) Please list the Proposed Standards in the first paragraph so that one who
is unfamiliar with our work can distinguish the five base specs from the
list of S/MIME specs stored on the IETF web site. 

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc.
[email-masked]
============================================

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Tue, 22 Jun 1999 10:57:21 -0400

> expected), then CMS will be enhanced to import the revised syntax."

This is definitely NOT a topic for S/MIME.

In the first place CMS should be importing semantics from PKIX, not
X.509. S/MIME has not addressed PKI infrastructure issues up to this
point and I don't think it is a good time to start.

In the second place simply adding attribute certificates because they
have appeared in an ISO proposal seems a very bad plan. Lots of
ideas make it into ISO specifications that never make it into the
real world. 

The approach S/MIME should take is to look to see what _functionality_
it wants to add to S/MIME to solve _problems_. Simply adding technology
for the sake of it is a very bad move.

The proper place to address attribute certificates would be either
PKIX or more likely a new group focussed on some _use_ of attribute
certificates. I suspect however that a such a group would want to
consider other technologies as well (attributes stored in a
trusted directory, attributes embedded in an OCSP call, etc.).

		Phill