To be sure that we are talking the same language, I am assuming that these
revisions would be to RFC 1422, which when coupled with 1421 seems to be
assumed to be "dead" just as it is progressing along the standards track. If
this is the general perception, and the assumption is that PEM/MIME wil
totoally overtake it, then I would lean in the direction of stripping out some
of the external syntax from 1422 and concentrate solely on the certification
mechanisms as a basline document.
This sounds fine to me. I think this is the way to go with the v3 cert work
regardless of whether MIME/PEM succeeds or fails.
On the other hand, if NED and others are saying that they would be amenable to
considering v3,
How many times do I have to say it? It is really simple: I SUPPORT UPGRADING
THE PEM CERTIFICATION INFRASTRUCTURE TO V3 CERTIFICATES. I SUPPORT REQUIRING
IMPLEMENTATION OF V3 CERTIFICATE FORMATS.
This is at least the tenth time I have said this, yet people seem to think I
have taken the opposite position. How many times does it take to make my
position on this clear?!?
perhaps as an upgrade or revison to PEM/MIME even (if and) as
it progresses, then perhaps revising the spec in two steps makes more sense.
My
feelin is that the easy stuff could be done in a month or two, and in fact the
discussion has already begun on the critical flag in CRLs. The consideration
of
the aporopriate set of extension, and which ones should b considered
mandatory,
obtional, or experimental, will take significantly longer, but is an effort
that would be of value to to entire community.
This is EXACTLY the approach I have been recommending all along.
Excellent idea! Chartering a new working group to deal ***SPECIFICALLY***
with
changes to the certificate structure and model is a wonderful idea.
I agree. I would hope, however, that this discussion could continue to take
place on pem-dev, completely exposed to everyone's critical review, even if it
does end up using significantly more bandwidth. Over and above the issue of a
sufficinet amount of review to ensure the technical quality, there is the
consideration of the education of the rest of the technical community to
consider.
I would welcome reusing the list for this purpose. Saves me having to
subscribe to another one...
It's late in the game, and I'm not trying to throw rocks at anyone, but I
think
there is a lesson to be learned from our current experience with PEM/MIME
which
would indicate that "you can pay me now, or you can pay me later." I.e., you
can educate the community and gain a concensus as you go, or you can do it
when
you get through. The total diffence in time may be small, but the increased
feeling of harmony and participation may be substantial. "This xyz spec may be
I agree completely. However, I would also say that this is exactly what we
have been trying to do with the MIME/PEM work all along.
Look at it from my perspective for a moment. These documents have been around
for a long time. During the periods when I acted as editor I responded to any
and all comments and issued updated specifications as quickly as I could. I
faithfully attended working group meeting after working group meeting. I
revised the specifications several times in accordance with the working group's
wishes, in several cases even when I VIOLENTLY disagreed with the groups
assessment of the issues involved.
And what happened? Mostly deafening silence, that's what. Several agenda were
also co-opted by other matters, and we went away from at least two meetings
I can remember with no action items to deal with.
I would therefore add to your assessment that you may or may not be able to
bring the horse to water, but it is hard as hell to force him to drink.
One final comment. I would recommend that the focus be specifically on X.509
cert, definitely in but not exclusively in the context of RFC1422. While
there
is considerable appeal to broadening the effort to look at using other
certificate systems, working on interoperability between the systems, and so
on, it seems to be that this is the sort of siren song masking very deep
matters that could easily lead to getting nothing done.
You have a point, but the tempation to embrace and co-opt PGP and PKCS may be
substantial, and with very significant and lasting benefit. We may not devise
formats that would include all of those alternative for direct compatibility,
but if we try to understnad what the motivation was behind those systems we
may
make progress. In this regard, I think that the PEM/MIME authors deserve some
credit, despite my reservations as to the overall outcome. In general, I think
that it is too early to tell yet where this may lead.
Fair enough. I would then make it a point in the charter that these issues
are to considered, but only after the primary goals have been met.
Ned