I think the JTC1 recognition of the IETF work is a fine thing. But I do
NOT think it is something that has a fundamental effect on reality.
This is a can of worms I don't care to open just at the moment :).
yeah, I noticed that the charter wasn't strictly accurate. I'm not part of
the working group management hierarchy, so I don't know the formal answer.
Informally, I'd summarize the goal in the fashion I used in my previous
message.
Fair enough.
So, modifying my internal model a bit, I would like to make the following
observations and proposals. I realize that some of these are at odds with
some people's particular goals, but they seem to me to be the most effective
way to simultaneously make progress and avoid shooting ourselves in our
collective foot.
Old business:
Agreeing to pass the most recent edit of the MIME Security Multiparts
document along to Proposed Standard. This may actually be
accomplished (I'm still a little fuzzy on some of the document
flow procedures), but in any case we seem to all be in agreement
that the MIME security multipart representation is both useful
and sufficient to its purpose.
PROPOSAL: If this document has not already been passed along,
do so with all possible speed.
Agreeing to pass the most recent edit of the MIME/PEM document
along to Proposed Standard. The WG is divided on particular
points of this document, namely key selectors and non-certificate-
based operation.
PROPOSAL: Remove descriptions of certification policies and key
selectors from the draft, stating explicitly that policy
is defined by RFC 1422 or its successors, not the MIME/PEM
definition (In other words, reduce the scope of the
document to just representational issues, not
policy or operational issues). Unless we discover
objections at this scope (none of which I am currently
aware), pass the resulting document along with all
possible speed.
New Business:
Defining new approaches to certification and key management beyond those
discussed in RFC 1422.
PROPOSAL: Begin construction of a new document addressing policy
and key management as applied to both RFC 1421 PEM and
MIME/PEM. This removes some of the time pressure, which
will allow both more relaxed discussion and a chance to
go into more detail concerning X.509v3, the operational
implications of self-signed certificates, bare keys,
arbitrary key selectors, and so on. TIS-PEM 7.0 and
RIPEM can continue to be testbeds for the various approaches.
These proposals would, I believe, allow us to reach immediate closure on
those issues we are *not* arguing about, and open up the scope usefully on
the issues we *are* arguing about, most of which apply just as much to
RFC 1421 PEM as they do to MIME/PEM.
This would satisfy my current concerns completely. I am willing to
personally do the edits I suggest over this weekend, so that we can
all look at the concrete result on Monday.
Comments?
Amanda Walker
InterCon Systems Corporation