By God, I think we are really about to make some progress! Amanda's proposal is
exacly in line with what I have been saying, Jeff seems to feel that
convergence with RIPEM is not out of the question, and Derek indicates that
maybe even PGP and PEM could possibly converge. The millenium may be here
before the year 2000, at this rate!
Amanda>
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.
Absolutely.
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.
According to Jim, this may need some more work. I certainly agree that to
whatever extent the certification policies are described, it would make sense
to remove them and refer to a single common document.
With respect to the issue of key selectors, I'll be happy to work with Amanda
to review and edit this portion. Perhaps I've misstated something, or called
something by the wrong name, as I haven't reread the spec in a couple of weeks.
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.
I agree in general. Ned had some points along this line, and I agree with some
but disagree with others. I'd like to see the bare-bones v3 certificate and v2
CRLs included, and agree with Jeff that not highlighting the requirement to
implement the CRITICAL function correctly would be irresponsible. Precisely how
to reference the ASN.1, etc., I think is still an open issue, but one that is
primarily a technical/drafting issue rather than a real procedural show-stopper
(I hope.)
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.
Bravo, bravo, bravissimo!
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820