Representation of OIDs as URIs

in the last ETSI ESI meeting we discussed how we could represent OID (ASN.1)
as URIs. i proposed two schemes that seem reasonable. we would also like to
hear other opinions.
these two approaches are as follows:

One encodes the OID as an URL and the other encodes it as an URN:

·	Encoding as URL:
fix a base URL and append the OID in an appropriate format (human readable)
e.g.,
http://www.etsi.org/oid/itu-t(0)/identified-organization(4)/etsi(0)/electron
ic-signature-standard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)
The generated URL must be persistent! This means that the resulting URL must
not be used to identify anything else than this OID. And this should be the
case, at least as long as this URL is used to identify this OID.
Advantages and disadvantages of this approach that we are aware of by now,
are as follows.
Advantages:
+	Uses the widely know schema of URLs.
+	The owner of the OID can place a specification document at the place on
his web server this URL refers to.
+	If there is no resource (e.g. a specification) at the given URL, then it
is just a unique name like an OID is.
+	Every company can use its own base URL. Some people also mentioned the
idea to use one base URL for all OIDs (e.g. http://www.w3.org/oid/,
http://www.oid.int or http://www.iso.org/oid). This would have the advantage
to have always the same base URL. The disadvantages would be: If the owners
want to place a specification on the web server, the owning company would
have to maintain web space for all OID owners (perhaps a redirection
mechanism would solve this?). Additionally, if a company wants to use this
base URL for internal (or even secret) purposes, it might not want to use
the fixed base URL (perhaps, it could just use anyone, if it is just for
internal use?)
Disadvantages:
-	The company owning the domain name of the base URL must ensure that the
base URL is persistent. It needs to be persistent as long as there is one or
more URLs in use for identifying an OID using this base URL. Remind that the
base URL includes the domain name and any additional directories.
-	If the URL is used just as a unique name without referring to any
resource, it might confuse people.

·	Encoding as URN:
register a NID (see RFC 2141 and RFC 2611) through IANA
(http://www.iana.org)
e.g., register “oid” as an NID, define NSS to identify an ASN.1 OID. This
could look like
urn:oid:itu-t(0)/identified-organization(4)/etsi(0)/electronic-signature-sta
ndard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)
for instance.
Advantages and disadvantages of this approach are:
Advantages:
+	There is a central registration authority for NID.
+	This approach could serve for all OIDs automatically (e.g. if the
registered NID would be “oid”).
+	IANA guarantees that NID are registered only once.
Disadvantages:
-	This mechanism of URNs with registered NIDs seems to be rarely used. Some
people might reject it just because they are not familiar with that kind of
URI.
-	There is no widely used and globally available mechanism to dereference an
URN. Thus, it might not be possible to retrieve a specification with the
given URN as seen with the approach using URLs.
At first glance, the approach using a URN seems to have the advantage to
guarantee uniqueness. But there is never a hundred percent guarantee for
uniqueness of any data. It is simply impossible. No one can securely prevent
me using any identifier the I want. In both approaches, the owner of the
base URL or of the registered NID has to ensure some properties.
Just consider the case in which a company is sold. If the succeeding owner
decides to change the rules and reassign all previously used identifiers,
the system does not work, no matter what scheme you use: URNs, URLs, or even
OIDs. Any of these systems only works, if everyone stick to the rules.


what do you think is the preferable approach?


  Karl Scheibelhofer

--

Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540

Received on Friday, 24 November 2000 04:31:35 UTC