>I agree with Bob on all of this. I also think that the only way to deal
>with these matters is to review the v3 cert work carefully, develop a
>list of potential issues, and then try to write a document that deals
>with them. Informed decisions on what to push for can be made once this is
>done.
>
>I also think this should be a topic for a new group. (The mailing list
>used doesn't matter to me.)
I do not agree with Bob on this.
Justification: v3 means no change to older (conformant) PEM system, and
interworking
at the v1 service is assured between systems. v1 (or default to
be precise)
PEM procedures may continue to be used with v3 certificates.
If all that we were proposing was to change the version number and reject any
critical extensions, it would be a relatively easy upgrade to existing systems,
both classic PEM and PEM/MIME, I think. That doesn't, however, guarantee that
anyone would be willing to invest the time to do upgarde their software, go
through the test and release process, revise the documentation, and handle any
of the incompatibility questions that arise. I would think that if I were an
implementor I would be highly reluctant to do so. As a result, you would be
left with a number of non-conformant implementations. I fail to see that that
would accomplish much, unless someone just wants to score points. Or are you
aware of some urgent requirement for v3 compatability that requires us to mount
a full-court press on this issue? I may have argued with Ned and Jim in the
past as to the degree of difficulty that is involved in getting classic PEM up
and running with a certificate infrastructure, but I would hesitiate to claim
that there is a vast population of users who are already up and running.
At this time, we are PERHAPS 90 days or so away from the v3 format even being
formally adopted, and the group has not yet seen the text of the proposed
extensions. Not having had time to even begin considering these issues, I don't
think that there is anything approximating a consensus as to how long this
process might take, or what the optimum approach might be. I think that it is
reasonably clear that if we see a lot of work ahead to really take profitable
advantage of v3, then it might be appropriate to make the quick fix and just
accept a bare-bones implementation of v3, with the "real" standard cum
extensions coming perhaps six months months to a year later, and another six
month to a year to get new implementations out.
In addition to the impact on PEM and PEM/MIME, we have to consider the impact
on certificate generation systems as well as on Directory implementations, both
X.500 and local client/server systems such as DEC's InfoBroker. The change in
the semantics of the DN is going to require careful consideration and planning.
As I said before, it isn't at all clear that with a substantial change in the
DN semantics, that an implementation can easily include code to handle both
formats, or that this would even be desirable.
I do not thing this should be a topic for a new group: the topic is
(a) as v3 relates to PEM, already fully covered in the proposed std
(b) fully within the PEM WG charter.
From the standpoint of the formal PEM WG charter, I guess I would agree. I was
merely thinking of a potentially different set of active players. In
particular, I think it will be necessary to develop a small working group,
either self-selected or assigned by the chair, to focus on this issue. In
particular one or more primary authors have to be assigned, and a tentative
schedule worked out.
If there are new work items, to address non-v1 uses of v3, or to upgrade
PEM procedures to use the std extensions, he can petition the chair,
as I did.
If and when I decided to volunteer to spearhead that function, I might be
willing to do so, and so might someone else. I think it is a little premature
to start getting all constipated about formality and Robert's Rules of Order
when we are still trying to form an opinion about what is going to need to be
done.
We have received appeals and comment to be a more disciplined and
productive WG. lets start with the basic model of respecting the
chair's role when it comes to the agenda and procedure.
If and when someone starts paying me for this work (preferably by the byte :-),
I'll start worrying more about discipline and meeting schedules. In the
meantime, I would be _delighted_ to have the chair outline his thoughts on this
particular issue, set an agenda, and inform us all of proper procedures.
If the chairman calls, would someone get his name? (I'm assuming that it is
still Steve Kent, but I don't know for sure.)
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820