[To: Michael Baum]
Richard Ankney responded to my comments re DUNS numbers as follows:
I read the NII announcement as referring only to EDI traffic, not to all NII
applications. In this case the DUNS number or equivalent is in each
interchange.
I agree.
X.435 suggests something like what Bob has proposed: alias entries with
names like C=US; O=D&B; EN=<DUNS #> for each trading partner. Other
registration agencies would have different organizational components in
the DN. These aliases would point to the normal civil naming entry.
I have a bit of a problem with this, if Rich is accurately quoting X.435. The
problem is not with the syntax, which would work, but with the semantics.
I believe in the use of strong typing, so that an attribute means one and only
one thing at all times. The X.435 usage would conflict with that principle,
because the "organization" is not the organization whose EN (enterprise
number?) is being referred to (which would be the normal implication of an
attribute associated with an organization). Instead, D&B is acting as a name
registration authority in this case, and ought to be designated as such.
In pseudoEnglish/ASN.1, the alias which points to the real organization should
be something like C=US, nameRegistrationAuthority=Dun & Bradstreet,
EN=<DUNS #>.
An even better solution, I think, would be to have TEDIS or EDIFACT or D&B or
whomever register as a name registration authority directly under the ITU root,
i.e., under the joint_ISO_CCITT (2) arc, _before_ country.
In this case, as in the case of international organizations such as the UN, no
Country would be specified. The numeric OID would make it clear who was acting
as the naming authroity.
I understand that there may be philosophical objections to creating a monoply
position for D&B (or recognizing a de facto monoply). There may be other
enterprise numbers that might be more applicable in other countries, for
example. In this case, the international EDI organization would simply register
alternate attributes, one for DUNS, perhaps one for CAGE numbers, Taxpayer ID
numbers, etc. (I'm not commenting on whether the DIUNS number is or is not the
best choice for a universal EDI enterprise number, merely iscussing technical
alternatives.)
From a technical, X.500 directory perspective, disregarding competitive issues
involving multiple directory service providers within the US and
internationally, it would seem that the best of all worlds solution would be
for this international EDI body to provide and operate (or subcontract to some
other organization) an X.500 Administrative Directory Management Domain
(ADDMD).
Efforts are underway within the NADF, the Internet, and the Paradise project in
Europe to bring all of these disjoint directory systems under the umbrella of
one common naming and knowledge tree, probably making use of knowledge and
naming link sharing tools such as the NADF's CAN tools, so that all ADDMDs and
any Private Directory Management Domains that care to can have common access to
all of the informataon in the public name space.
Such an international EDI organization could reasonably sidestep some of the
nasty antitrust problems that might otherwise exist, and substantially simpliy
the name lookup process. Without a natural monoply service provider, every
ADDMD in the world would have to know all of the DUNS numbers for every
enterprise in the world -- an untenable situation.
The alternative might be to segregate the listing of DUNS numbers to the
country in which the company or organization is located or incorporated, but
that would defeat much of the purpose of having a directory. It would be
necessary to interrogate an ADDMD in every country, from Afganistan to
Zimbabwe, in order to find a given number. (I'm assuming that there is no
internal structure to a DUNS number that might facilitate this search, but I
don't know that for a fact.)
On the other hand, if the international EDI body operated an ADDMD, then every
DSA in the world would know who it was and how to get to it, and could
interrogate it to determine the "real" (civil naming structure" name of the
organization, and which ADDMD or PRDMD contained further information about that
organization.
In other words, the international organization should maintain only a limited
pointer to the rest of the information about an organization. The information
itself could be stored at any DSA anywhere in the world. For ease of access and
replication for reliability, the international organization should probably
operate several ADDMDs, perhaps one or two in each country, that would be
synchronized, but this is a relatively small point.
However, even if this international EDI body were to operate the ADDMD, I would
not trust this alias mechanism too far. There are simply too many things that
could go wrong. Instead, the applicable Name Registration Authority (e.g., Dun
and Bradstreet) should issue a X.509 digitally signed certificate that binds
that organization name to the DUNS number.
At present, this is technically a little awkward, because X.509 does not
provide the ability to digitally sign an attribute that is not a Distinguished
Name. Including the DUNS number within an organization's Distinguished Name
could be done, especially if it is merely in the X.509 certificate, but it
would be a little tacky. Fortunately, there is considerable pressure to modify
X.509 to include such a capability, and I believe that Warwick Ford of BNR is
introducing such a position in the X.500 standards committee. Otherwise, an
approach similar to PKCS #6 could be used, where the certificate is signed, an
appendage added, and the whole thing signed again. Or an alternative to X.509
could be introduced for this purpose, perhaps along the lines of X9.30.
At the last ABA workshop, Frank Sudia and I discussed the difference between an
identity certificate and a capabilities or authorization certificate, and what
the root of either of those certificate hierarchies should be from the
standpoint of trust. Suppose the D&B were to issue a certificate binding an
organization name to a DUNS number. Should they also bind the public key for
that organization, a la X.509? This requires some more thought, but my initial
reaction would be to say that no, it probably shouldn't bind the public key,
becasue of the differences in the trust model for key authentication vs.
corporate numbering and identification.
The difference between these various trust models hasn't quite jelled yet, but
let me try to advance an argument. To my mind, the most important single
construct to come out of the PEM work was the notion of a Policy Certification
Authority. Unfortunately, we still don't have very many, if any, good examples,
but the intent would be that the PCA would operate in such a manner as to
enforce (though contracts and auditing) a certain standard of behavior with
respect to the lower-level CAs and individuals who are ultimately certified by
that PCA. The PCA should establish minimum requirements for key length and
other technical and security parameters, and should set certain standards for
the identification of individuals. Based on such a standard, users operating
within the domain of trust would know what to expect with respect to an
individual's identity bona fides.
However, it is highly unlikely that the PCA would accept any liability for the
_actions_ of such an individual or company. The PCA is almost surely not going
to establish the credit worthiness of an individual or company, nor should
they. that is more properly the function of someone issuing an authorization
certificate, e.g., MasterCard. They _do_ provide a degree of deep pockets
liaiblity for individuals, and they try hard to collect. But they also charge a
percentage of each transaction, so they can afford to take the risk and the
(hopefully modest) rate of fraud and bad debt.
It is pretty clear that D&B is _not_ in that position. They publish infomation
that is presumably relevant to someone making a decision about a firm's
financial strength, but they don't underwrite that firm's obligations or share
any liability (other than what might arise from misrepresentations or
malpractice on thier part, either deliberate or accidental, presumably.) So a
D&B certificate is neither fish nor fowl -- it isn't an identity certificate
(although it could be), because D&B presumably doesn't have a contract with the
various CAs to act as a PCA and it isn't vouching for the binding between the
organization name and the orgnization's public key. And it probaby isn't a
capability or authorization certificate either, because D&B doesn't authorize
anybody to do anything (although they could, perhaps by running some form of an
EDI clearinghouse function.)
Maybe I've gone off the deep end here, and if so I trust that someone will
throw me a rope. I've been assuming that the DUNS number was really _critical_,
and that therefore it needed to be very tightly bound to an organization. But
DUNS listings are probably widely available in other forms, and if the Name
Registration Authority were to make a mistake in the alias that points to the
real organization's entries, the mistake would be caught rather quickly. (It
would be a good idea for the organization to include the DUNS number in its own
entry, just to allow a cross check.) So although issuing a certificate t tie
the organization's Distinguished name to the DUNS number would be a nice idea,
it may not be really necessary.
If one assumes C=US, the rest of the name can be constructed can be
constructed from the interchange, i.e. Sender ID (DUNS #) and Sender ID
Qualifier (registration agency).
Regards,
Rich
I think that assuming C=US is a major problem. Even if D&B is a US corporation,
you don't want everyone in the world having to come to their DSA to dereference
this information.
On the other hand, the NADF takes the position that you list organizations
where they are most likely to be found, not necessarily where they reside. With
that interpretation, D&B could list their Name Registration Authority under
whatever countries they wish, and could provide this service if they wanted to.
Depending on the final decisions that may be made regarding Accounting and
Settlements for X.500 information flow, they could even make money from this
service as an information provider.
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
617/466-2820
Jueneman(_at_)GTE(_dot_)COM