>From: jueneman <jueneman%wotan(_at_)com(_dot_)gte>
>Subject: Re: identifying attribute types
>Date: Fri, 19 Nov 93 12:31:28 EST
Im glad this got a reply. It became necessary to force the issue,
by being provocative.
>>Summarising the system implementation requirements outlined by
>>Steve Kent:
Does anyone deny that my precis reflected the thrust of Steve Kent's
position expressed over months and months, in response to
your many mails? (the provocative statementing is mine, not
Steve's; my personal view has not been expressed)
>If I understand the thrust of these remarks correctly, I VERY STRONGLY
>DISAGREE.
>
>I don't think that we know well enough at this time to say exactly what
>attributes will be required for the various purposes for which PEM may
>ultimately be used.
the function of PEM is well-defined: the exchange of
secure internet mail. It has no other purpose. Any purposes
for which secure Internet mail is used should build upon
PEM, not change PEM. PEM includes a trusted key distribution
protocol. It is mandatory. It states requirements
for naming.
Other X.509 pilots, which Im involved in, do not
necessairly make such requirements. However they
are not "PEM".
The function of naming in PEM is to satisfy assurance evaluation criteria
for ensuring individual accountability. it has no other
security function. Descriptive identification is thus required. Addresses
are not suitable. No form of addresing is needed by the PEM protocol.
I would therefore insist that the IANA specify a
>MINIMUM required set of attributes necessary to support a reasonable
>amount of interoperability, but that no constraints be placed on an
>implementation that chooses to support additional attributes.
The IETF promotes universal protocols, to the Internet community. there
can be no notion of "resaonable interoperability". Any protocol
failing this criteria must be rejected. If a proposed protocol
is _so_ ambiguous that this situation is likely, it must
be refined. PEM is not ambiguous.
>the RFCs say currently, a compliant PEM UA should be required to display
>any attribute type that it does not understand as best it can, whether as
>a printable string or in hex.
PEM protocol is not concerned with displaying.PEM UAs are. The RFCs make
recommendations for UA facilities, they are but helpful recommendations. It
is implicit that the identity protocol understand all
data types used in a security protocol. otherwise the protocol
exchange and the associated elements of procedures
cannot be considered assured. PEM does understand all
the types of the information transfer, by having adopted
the syntax and semantics of DN types, and the transfer rules of B/DER.
However the legitimacy of the DN is a "conforamance to schema" question,
which require the protocol engine to check whether the DN satisfies
the schema rules. to be interoperable, the protocol engine musthave
the means to know all the schemas for all naming contexts. in the
absence of a universal, theoretical directory, this is difficult. that
a nominated set is supported by all, is most likely the realistic
options. PEM currently nominates one schema.
In particular, PEM should not be limited to the
>set of attributes specified in X.521, but should be guided more by the
>NIST stable implementors agreements (at least for US use).
You have stated that a given set of attributes must be agreed. You have
chosen NIST OIW regional workshop, rather than the international IANA body.
OIW would be more suitable to profiling and protocol standardisation performed
by ANSI. This is the IETF.
>
>Point 2) is so judgemental in its nature that it conveys little useful
>information. "Effective organization of a Directory Information Tree" --
>effective using whose particular implementation? "as represented by a
>nominated set of competent schema specifications" -- nominated by whom?
>Competent in whose judgement? CCITT's? One or more PTTs? NIST?
>Individual Private Directory Service Providers providing service to
multiple
>users, e.g., AT&T or GE Information Services, or perhaps GTE? Truely
>Private Directory Servers Providers, such as IBM or the University of
>Michigan?
effective means that there exists a naming architecture, and Directory schema
for each jurisdiction of naming, accessed by one or more service
providers. There are multiple naming jurisdictions in the IETF. PEM
identity protocol must be able to enforce schema constraints on
any name. the only exception is where the CA acts as a
trusted third party, and may be assumed to have assured the
form of the name.
See above for the understandin of nomination, and who nominates for
the PEM world. (PEM!)
>
>Point 3) requires an "algorithmic relationship" between the DN contained
>in the X.509 certificate and the DN of the X.500 entry. Does this include
>subsets or supersets? In other words, can I include multiple X.509
>certificates in the entry for a given "individual," perhaps to support
multiple
>algorithms, different uses, etc? Or must a lower level DN be created in the
>directory that is equivalent to the DN of the certificate? Likewise, can I
>create multiple entries under multiple directory DNs, each of which would
>contain identical certificates? I should think so, in both cases.
This is not relevant to the current deployment of PEM, in which
detailed disucssion of Directory Services is not helpful. We can discuss
this offline, for the case of MSP. To be helpful to PEM deployment,
implementations might simply store one certificate in one entry,
where the certificate subject and the entry distinguished name
are identical.
>
>Example:
>
>Suppose that the DN that is used to search the directory is
>C=US,O=GTE,OU=GTE Labs,CN=Robert Jueneman. Can I create multiple
>X.509 certificates and file them under that directory DN, including one
with
>C=US,O=GTE,OU=GTE Labs,CN=Robert Jueneman,Description="For
>Personal and Confidential Mail Only"?
>
>Likewise, suppose that I have a certificate containing a DN of
>C=US,O=GTE,OU=GTE Labs,CN=Robert Jueneman. Is there any reason
>that I cannot file that certificate under several directory DNs, including
>C=US,O=GTE,OU=GTE Labs,CN=Robert R. Jueneman,Title=Mgr., Secure Systems,
>C=US,O=GTE,OU=GTE Labs,CN=Bob Jueneman, and
>C=US,S=Massachusetts,L=Acton,Address=10 Stoneymeade Way,
>CN=Robert Jueneman? (Note that these may or may not be aliases
>of each other, for I may wish to associate different mailboxes, telephone
>numbers, etc. with each one.)
>
>Many of these issues are presently being explored by the NADF and
>individual service providers, and presumably by other such organizations
>in other countries. I therefore think it would be highly presumptious of
the
>IETF to try to prejudge or foreclose potentially useful attribute options
>and/or directory structure conventions at this time.
The IETF and the NADF and PARADISE liase closely. The same people are
involved. PEM protocols have devolved schema management to the NADF
for US/CA identities. An algorithm exists to determine a NADF
legitimate DN based upon the US civil naming infrastructure. there
are many legal advantages to this, as already explained by Marhsall
and Stef. US identities used in the PEM protocol are rquired
to adopt the NADF schema. You may not deviate (in PEM), except where
provided for by the NADF. The rules are independent of
Directory service provision, or implementations.
>
>Instead, we should allow a relatively rich set of attributes, taking into
>account the fact that many, perhaps most, PEM users may not have access
>to a commercial-quality X.500 directory server for some number of years.
>That should not hinder the deployment of PEM or its use outside of an X.500
>environment.
>As users make up certificates which contain information which they think
>is necessary or at least useful, they will find out from their
correspondents
>and/or their directory service provider whether those attributes are
>understood or useful.
This assumes that users are naming authorities. This is not the case in PEM
in the US domain. Other domains have yet to formalize their requirements. The
NADF specificially uses the civil naming infrastructure. US PEM users do not
choose their DN.
The users will then be free to negotiate with
>their directory service provider and/or PEM UA provider for the support
they
>.feel they need, and that is how it should be.
>
I sympathathise with much of your position. It contains analysis
and beliefs which I held only a few years ago. It is the OSI
hypothesis. In such a free form, it has been shown not to produce
results except in small internets. The more focussed approach of the
OSI-related NADF and PEM is intended to work for all the Internet, without
ceding
rights over naming and security to sovereign jurisdictions.
>Bob