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.
??
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.
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.
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