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.
I have no problem with the removal of any policy statements. I was unaware
there were any, and I'll have to be shown where they are before I'll believe
otherwise.
However, this sounds to me like a proposal that we do away with all forms but
those based on certs. This is not acceptable to me, as I've stated in a
previous message.
As far as key selectors go, they are not a big concern for me either way. I
think they are nice to have and the difficulty of supporting them has been
overstated, but I can live without them. What I cannot live without is some
alternative to the cert model.
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.
As I said before, the current draft does NOT reflect the current document,
which has undergone literally hundreds of editorial changes. I therefore think
this is a waste of time no matter what.
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.)
I STRONGLY OBJECT to the inclusion of v3 certs as part of this work. Doing so
guarantees a delay of at least another year, in my opinion, which is not
acceptable to me. It is also objectionable on procedural grounds -- this is
standards porkbarreling and nothing more.
If you want to prove me wrong you have only to produce a completed
specification of v3 certs that defines them adequately and deals with all the
issues they raise. This has to be done in any case -- so by all means get
started. Of course I'm unaware that anyone has volunteered to do this, let
alone begun to assess the task...
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!
As I said before, if this means what I think it means I have no interest in it
and will withdraw from the MIME/PEM effort entirely. I probably will take steps
to shut down all PEM development work at Innosoft as well, since I think that
cert-only PEM is a nonstarter now and always will be.
This is not intended to be a threat -- most of you do not and should not care
what Innosoft does or does not do with PEM. However, I feel that it is only
fair that I alert the group to my intentions in this area. I will also
recommend that other email developers do the same as Innosoft.
And let there be no doubt about my authority here -- my position at Innosoft is
Chief Development Officer so this is my call to make. As a practical matter
it has been an uphill struggle to get Innosoft to devote any resources to PEM,
so this will not be at all difficult to accomplish.
I feel compelled to say, however, that it will be a relief not to be caught
in the middle where I have to defend the actions of this group to my
peers at Innosoft and elsewhere as being in some way logical or reasonable.
Ned