Some of this exchange confuses me. I've included the IESG in hopes of
clarification.
Lines beginning "> >" are from Peter Willilams.
Lines beginning "> " are Bob Jueneman's reply to Peter
Unmarked lines from me.
Steve
Reply-To: "Jueneman, Robert R." <Jueneman(_at_)gte(_dot_)com>
From: jueneman%wotan(_at_)gte(_dot_)com
To: Peter Williams <P(_dot_)Williams(_at_)cs(_dot_)ucl(_dot_)ac(_dot_)uk>
cc: pem-dev(_at_)tis(_dot_)com
Date: Wed, 09 Mar 94 19:21:23 EST
Subject: IETF and NADF (was Re: StrongAuthenticationUser
Peter,
I don't understand some of the points you made. Could you please
elucidate?
I don't think we are progressing the PEM RFCs on the standards path.
??
I'm not sure what Peter's comment means. The PEM RFCs (1421-1424) are
currently Proposed Standards.
1) IETF activities are being used to support "submissions" to the NADF -
private members-only commercially-driven group. This is just wrong. The IETF
should only work from NADF published documents and statements. Liason is
fine, interworking is not.
I don't understand what you are saying at all. Are you suggesting
that I am doing something "wrong" by addressing the needs of the PEM
community and/or other PKC users within the NADF, and vice versa? I
am not a member of the IETF, and don't pretend to represent them or
their position in any context. GTE has joined the NADF, and I am a
delegate, but I would not pretend to represent them in any capacity
either. but I believe that Steve Kent made the decision long ago
that this list need not be closed to IETF members, and I have been
working on that assumption ever since.
Actually, Bob, membership in the IETF is not very well defined. In
essence, participation is membership. Attendance at the thrice yearly
plenary meetings is *not* a condition of membership, and there is a
very strong rule that says decisions cannot be made solely in face to
face to meetings. The working group mailing lists, like this one, are
the key forum, and you certainly qualify as as an active member!
I don't understand the issues with respect to the NADF. Marshall
Rose, John Klensin and/or Erik Huizer might have some insight.
It may be useful to understand that the NADF is an organization of
POTENTIAL (and in some cases actual) X.500 directory service
providers, who so far are providing this service for free. At this
time, there is not yet even an agreed upon algorithm for charging
and settlements between ADDMDs, or ADDMDs and PRDMDs, so I think
that it is highly unlikely that anyone has yet made a business
decision to offer X.500 service on an on-going, for-profit basis. I
would therefore assert that the NADF's pilot project falls into the
same category as a number of other projects in the US and Europe --
feasibility studies.
Don't forget -- since the US does not have a monopoly carrier,
unlike those countries with national PTTs, a voluntary, cooperative
mechanism such as has been adopted by the NADF is a REQUIREMENT.
Because X.500 '93 doesn't yet specify how to share knowledge of
which ADDMD or PRDMD actually "contains" the entries for a
particular organization or individual, an out of band process must
be used to disseminate this information. At present this is an
awkward process that involves periodic updates via FTP of the
so-called CAN information. Without it, sharing of the national name
space would be impossible in a competitive environment.
5) Continual discussion of X.500 contradicts the instruction of the area
director to ensure PEM and X.500 services are exclusively handled within
the IETF.
To put it bluntly, who is the area director, and who made him (or her) God?
X.500 is a joint CCITT/ISO standard. Does the IETF intend to declare war
on the United Nations, under whose sponsorship these standards are
developed? I don't understand.
Perhaps one of the other area directors can speak about X.500 matters.
PEM is in the security area, and I'm the area director for security.
None of the above is familiar to me, pro or con.
I will admit to having some concerns about X.500; PEM is lagging
mightily, and I attribute some of the problem to the heavy investment
in X.500 standards which are not matched by the maturity in X.500
technology, software and products, but that's far afield from the
comments cited above.
D) Perhaps Bob will reconsider publishing his ongoing "redesign
of authentication syntax and semantics" as an I-D, rather than putting
it through the NADF?
I think you are putting me on? I have suggested revisions to the PEM
technical community regarding the content of certain X.500 attributes,
notably the structure of X.509, and more recently regarding extensions
to the X.521 definition of StrongAuthenticationUser object class. Why
do you think that deserves an Internet Draft, particularly before any
reasonable amount of concensus has been achieved?
Now, if you are suggesting that the IETF might respond to such an I-D
with a formal defect report to CCITT/ISO, I might be much more willing
to consider such an effort!
In the meantime, since I volunteered GTE Labs' resources to try to
support X.509 certificates in the X.500 environment, an effort which
I assume would be of interest to the PEM community, I am trying to
understand what attributes are required to make such a directory
really useful. IMHO, the current definitions don't cut it, and since
sooner or later we will have to make a business case for offering
such a service, utility is a primary concern.
Once GTE Labs has completed the process of registering at the
national level under ANSI and been assigned an OID, we could of
course create a gteStrongAuthenticationUser attribute and offer such
a service on a take it or leave it basis. But I don't think that
would be useful -- in particular because we don't plan to write the
DUAs that will be necessary to support such usage, and the users
would "leave it".
On the other hand, if it becomes apparent that more vendors of DUAs
and PEM UAs would implement such an enhanced object class definition
if it had an IETF OID than if it were registered under the NADF OID,
then I would be happy to have it registered as an
ietfStrongAuthenticationUser object class, and perhaps under the
OIW.
(The real issue, I think, is how we collectively are ever going to
get all of these different OIDs and attributes under control. I
suspect that it will be nearly impossible, and that it why I wrote
the message regarding self-describing objects and the need to
describe the SEMANTICS of such attributes. Now it appears that if
you hold your mouth just right, and squint a little bit when you
read Appendix C to X.501, that the AttributeTypeDescription might
just solve this problem and save the day. but I don't yet know if
anyone implements it, or whether such a reading would be a correct
interpretation. And I doubt that anyone has posted such definitions
of their attributes to any X.500 directory as yet.)
Right now I am just floating a trial balloon, and seeking feedback
and concensus as to what such an object class should look like. I
can't wait three years for CCITT/ISO to make up their collective
minds on such issues -- I want to get on with it.
Your comments, based on your obvious knowledge of the various standards
initiatives, would be most welcome.
Bob