Subject: OIDs as URIs

From: "Karl Scheibelhofer" <[email-masked]>
Date: Fri, 24 Nov 2000 10:36:31 +0100

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:[email-masked]>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540

---

From: Paul Koning <[email-masked]>
Date: Mon, 27 Nov 2000 12:56:23 -0500 (EST)

>>>>> "Karl" == Karl Scheibelhofer <[email-masked]> writes:

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

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

 Karl> · Encoding as URL: fix a base URL and append the OID in an
 Karl> appropriate format (human readable) e.g.,
 Karl> http://www.etsi.org/oid/itu-t(0)/identified-organization(4)/etsi(0)/electron
 Karl> ic-signature-standard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)

It seems to me the text part is unnecessary clutter, the numbers alone
would suffice.

Then again, perhaps it's the other way around.

What's the purpose of this?  Why would you want to map an OID to a
URI, and who/what would consume the resulting URI?  The answer would
affect the sort of encoding that makes sense, and for that matter
whether the notion itself is at all useful.

 Karl> The generated URL must be persistent! This means that the
 Karl> resulting URL must not be used to identify anything else than
 Karl> this OID. And this should be the case, at least as long as this
 Karl> URL is used to identify this OID.  

That's a problem of course.  There is no naming authority for URIs
that can enforce this, as there is for OIDs.  

 Karl>   + The owner
 Karl> of the OID can place a specification document at the place on
 Karl> his web server this URL refers to.

But then the URL refers to a document.  The document isn't the OID, so
that contradicts the requirement you stated above.

     paul

---

From: "Karl Scheibelhofer" <[email-masked]>
Date: Tue, 28 Nov 2000 09:06:05 +0100

> -----Original Message-----
> From: Paul Koning [mailto:[email-masked]]
> Sent: Monday, November 27, 2000 6:56 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: OIDs as URIs
>
>
>  Karl>

for computers to read it - yes. for human readability - no.

> whether the notion itself is at all useful.

it should be a syntactic valid URI and it should be human readable (as far
as possible and reasonable).

> that can enforce this, as there is for OIDs.

there is an naming authority for URNs (of their NID part exactly). it is
IANA. any URN is a valid URI.

there are also authorities for domain names. of course they can change their
owner. but if a company is sold, how about your OIDs? they also changed
their owner.

> that contradicts the requirement you stated above.

good comment. i agree that it is perhaps inappropriate to use the URI as an
identifier for a "thing" other that the URI points to. perhaps we should
define something additionally like: append /specification to the URI to get
a specification; and only place a document to the actual location of the
URI, if the OID identifies that document.

regards

  Karl Scheibelhofer

--