Webmaster's note: This blog post is a verbatim reprint of a post which originally appeared over 12 years ago, on November 13th, 2005. You can view the original post here.
By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation
In Part 1 of this post, I showed why “on-demand” software requires a bilateral trust model, and I reviewed current standards and practices for proving identity. I concluded:
So it seems that digital certificates and XKMS are appropriate ways to implement a bilateral trust model for ‘on-demand’ software—provided they use the right trust or ‘assurance level.’
Or are they?
(Note: what follows is of necessity pretty technical. I've tried to keep it as simple as possible.)
In his superbly-written draft PKI critique, Ian Grigg exposes an X.509 security bug:
The user of any application is not expected to enter into decisions based on who signed the cert, all are as good as each other ... This structure does not for example limit another CA [certificate authority] from issuing a certificate in this name, as neither the hapless purchaser nor the CA have any contractual obligations with any other CA. (Nor does it prevent our party going to another CA on his own behest and purchasing another certificate!). In more technical terms, this bug exposes such PKIs [public key infrastructures] to a large class of substitute certificate attacks. A cert [certificate] acquired from one CA an be used to conduct an MITM [man in the middle] attack on the victim, with neither the victim nor the copied CA being aware of the attack. In current day browsing ... there is no defence against this attack and indeed it is hidden and denied as an attack.
This means that the X.500 and X.509 standards aren’t suitable for a bilateral trust model because they do not operate across CA boundaries or namespaces. This becomes obvious as soon as you see where CAs belong in the ASN.1:2002 object identifier (OID) repository: the country-specific common area of ISO and ITU-T (International Telecommunications Union - Telecommunication standardization sector). For example, VeriSign's OID is 2.16.840.1.113733 (urn:oid:2.16.840.1.113733) which in ASN.1:2002 notation means:
{joint-iso-itu-t(2) country(16) us(840) organization(1) VeriSign(113733)}
In short, all the certificates issued by VeriSign are inextricably bound to a single organization registered in a single country (the United States, in this case).
What’s needed is a new kind of federated identity infrastructure that assures globally unique identities. One approach uses universally unique identifiers (UUID), also known as globally unique identifiers (GUID). The ASN.1:2002 OID repository has a place for those, too:
{joint-iso-itu-t(2) uuid(25)}
There is even a standard (X.667 or ISO 9834-8) for generating and registering unique of near-unique ID values, but it suffers from the same security flaw as X.509. To quote the standard itself:
The Registration Authority for UUIDs is responsible for a collision between registered UUIDs, but it is not responsible for a collision between a registered UUID and an unregistered UUID because it does not manage unregistered UUIDs.
A compatible specification, RFC4122, uses the uniform resource name (URN) namespace "urn:uuid" and an even earlier specification, RFC3043, uses the namespace “urn:pin” for “personal internet name.” Curiously, RFC3043 relies on prioritary VeriSign technology for generating and registering PINs (which overcomes the X.509 security bug exposed by Grigg), and VeriSign even has a Web page describing its PIN pilot project, but none of the links for generating or managing your own PIN work so it appears that VeriSign has abandoned this project.
But VeriSign has since gotten involved in auto-identification technology in a big way. In 2004 EPCglobal selected VeriSign to be the RA for the EPCglobal Network, a standard system for using radio frequency identification (RFID) and the electronic product code (EPC) to track articles throughout the supply network. EPCglobal, in turn, is a joint venture between GS1 (formerly EAN International) and GS1 US (formerly the Uniform Code Council)—the organizations responsible for those ubiquitous universal product barcodes found everywhere in the world. The current EPC tag data standard uses the URN namespace “urn:epc” which is further subdivided into namespaces for individual identity types. One of those, “urn:epc:id:giai”, is reserved for the global individual asset identifier (GIAI). The GIAI consists of a unique company prefix assigned by EPCglobal's RA (VeriSign), and a unique individual asset reference assigned by the company’'s RA or trusted third party (TTP). Nothing prevents a company from identifying a person as an “individual asset;” indeed, this is the only standard way I can see for putting RFID tags in employee badges.
Because it relies on a single RA, the EPCglobal Network framework overcomes the X.509 security bug exposed by Grigg. But, like X.509, it still won’t work in a bilateral trust model because it does not uniquely identify a person globally. For example, suppose you have both a day job and a night job, and each employer gives you an RFID-tagged badge. Because the employers have different company prefixes, you now have 2 different GIAIs for the same person.
I believe this demonstrates that none of the standards in use today, including X.509 (PKI) standards for digital certificates and also including UUIDs, GUIDs, PINs or the EPCglobal Network, are appropriate ways to implement a bilateral trust model for “on-demand” software.
What to do?
I'll explore some ideas in Part 3.