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.
I'm not sure how this can be done given the present form of the document. In
particular, once we remove the key selector fields it will be very hard to
reinsert it later, since the entire syntax of some of the most important fields
will change. Even an addition at the end of the field will be problematic in
the future. Making it optional and presently ignored would be better, but not
by much.
I also don't see how this can be made to work in the context of certificates
either -- by removing all the identifier forms other than issuers and
distinguished names, perhaps?
If so, I'm afraid I have zero interest in implementing the resulting service,
and will withdraw from this working group effort immediately. The insistence on
the presence of certificates and distinguished names is a showstopper for me.
It is not reasonable to expect these to be used from the outset.
I also don't think the shining hope offered by v3 certs is realistic, for all
the reasons I've outlined in previous messages. Moreover, the formalism of the
process insists on this view. Had there been a complete and detailed
specification of v3 certs on the table for the past two years undergoing
comment and review I would feel differently. But there hasn't, and therefore I
don't.
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.
Well, I somewhat agree with this, at least to the extent that most if not all
of the general criticism that has been leveled at the new specifications
applies equally if not more so to RFC1421 and RFC1422. But I also think that if
we defer this to the future it will never get done, and we'll never get a
useful service out of any of this.
Put another way, it seems to me that the tactic being used here is for people
who disagree with the proposed MIME/PEM model to attempt to delay things as
much as possible. I'm opposed to the use of this tactic every bit as much as
I'm opposed to the technical changes I think this proposes making.
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.
See above. Given that the MIME/PEM document has undergone MAJOR editorial
changes in the past couple of weeks in response to feedback from various
people, I don't think a new cut at the old ones is a useful exercise.
Ned