But my sense is that it is time for some more extensive revisions, including
updating the certificate chain to stop at one or more trusted root keys,
instead of the PCA or IPRA necessarily, the PCA-CA-user hierarchy, and
probably
a number of other extensions.
Hmm. Well, while I think such changes would be good, in the abstract at least,
I also think that this could easily add lots of delay. The question becomes
one
of which is more important, a timely specification or a complete revisiting
of all the issues.
I would tend towards the latter, but that's just a personal preference which I
cannot back up with any compelling technical argument.
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.
On the other hand, if NED and others are saying that they would be amenable to
considering v3, 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.
I would actively support such an revision effort, and suggest that we do
whatever is necessary to charter a work group to address this issue.
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.
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
a sonofabitch, but at least it's our sonofabitch."
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.
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820