The charter proposal looks pretty good. However, I think a more easy to
follow list of the provisions might be:
The resulting work will specify:
1. certificate and message formats that have limited backwards
compatibility with the existing PGP message format described in RFC 1991
2. a public key infrastructure and trust model
3. basic time stamping capabilities
4. mandatory minimum specifications for encryption and key exchange that
are chosen without concern for any government policies and that are
consider strong, open, and unencumbered by intellectual property rights
5. a MIME structure similar (if not identical) to RFC 2015
Chairpersons:
John W. Noerenberg, II <jwn2(_at_)eudora(_dot_)com>
Charles J. Breed <cbreed(_at_)pgp(_dot_)com> co-chair
My experience has been that two chairpeople don't do a better job than one.
In this case, since Charles currently works for the company whose employees
have written the drafts we'll probably consider, I think that a single
chairman, John Noerenberg, would be better than two. (Disclaimer: both
people work for members of IMC, and John's on our board of directors.)
At 9:07 AM -0700 8/25/97, David Gaon wrote:
I disagree - There MUST NOT be any mandatory requirements for
algorithms, keys, ...
If two correspondents need to correspond securely, they must first
establish their respective mail security capabilities (ie find out
what they can receive) through the use of other relevant mail
capabilities such as Directories.
If they h ave compoatible capabilities, they will correspond, if they
do not, tough luck. This is no problem for e-commerce because I
expect commercial enterprises will implement a multitude of security
capabilities to satisfy their cusdtomers.
The IESG rejected the TLS (SSL) Working Group's efforts because they didn't
include a mandatory minimum. Although they haven't said that they would do
that for all security protocols, it seems likely they will. Thus, I think
this group needs to have mandatory minimums if we want to have our work be
on standards track.
>>Charter - 5. certificate and message format
Could we work towards unifying the different secure mail messsage
formats floating around and making this the unified format
Well, given that the other popular format (S/MIME) uses a very different
underlying format (PKCS #7), "unifying" can't happen at the same time as
any backwards compatibility with earlier PGP (or, conversely, with earlier
S/MIME). I think it is better to stay focused on the work described above.
--Paul E. Hoffman, Director
--Internet Mail Consortium