Subject: RE: OIDs as URIs

From: Ambarish Malpani <[email-masked]>
Date: Mon, 27 Nov 2000 07:46:06 -0800

Hi Karl,
    Any issue with encoding oids as:

oid://0.4.0.1733.1.4.1

(Kind of like your second suggestion, without the extra text).

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Karl Scheibelhofer [mailto:[email-masked]]
> Sent: Friday, November 24, 2000 1:37 AM
> To: IETF PKIX Mailing List
> Subject: 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)/et
> si(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: "Karl Scheibelhofer" <[email-masked]>
Date: Tue, 28 Nov 2000 08:52:23 +0100

> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Monday, November 27, 2000 4:46 PM
> To: 'Karl Scheibelhofer'; IETF PKIX Mailing List
> Subject: RE: OIDs as URIs
>
>
>
> Hi Karl,

this URL is not dereferencable. it is not human readable. thus, i would say
it is not suitable for a textual encoding like e.g. XML. there is no
advantage of your suggestion over RFC 3001. if you are satisfied with
numbers only the current RFC 3001 is exactly what you mean.

regards

  Karl Scheibelhofer

--

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 28 Nov 2000 12:49:22 +0100

Karl,

> this URL is not dereferencable. 

This is not needed, as a way to express an OID.

> it is not human readable. 

This is not needed either.

> thus, i would say

RFC 3001 is quite new: A URN Namespace of Object Identifiers. M. Mealling.
November 2000. (Format: TXT=7459 bytes) (Status: INFORMATIONAL)

I went on the offical web server from the IETF
(http://www.ietf.org/rfc.html) making a query for and it is yet not there.
The official URL http://www.ietf.org/rfc/rfc3001.txt does not respond
either. Would you be able to tell us where to find that document ?

However, I observed that the status of this document is INFORMATIONAL,
instead of PROPOSED STANDARD (or STANDARD).

Regards,

Denis

---

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

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, November 28, 2000 12:49 PM
> To: Karl Scheibelhofer
> Cc: IETF PKIX Mailing List
> Subject: Re: OIDs as URIs
>
>
> Karl,
>

yes, i know that it is not absolutely required to work.

> This is not needed either.

for use in XML i would heavily recommend that it is human readable. as i
already stated in another message, this was a design goal for XML: "XML
documents should be human-legible and reasonably clear." i think this
advantage should not be underestimated.

> either. Would you be able to tell us where to find that document ?

i found it, with a link to it, via the rfc-editor page. i cannot connect to
it at the moment.

> instead of PROPOSED STANDARD (or STANDARD).

yes, i know. but it's worth to be considered, since it is very similar to
the URN approach the we discussed.

regards

  Karl Scheibelhofer

--

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 28 Nov 2000 15:30:30 +0100

> yes, i know that it is not absolutely required to work.

The URN working group is working on ways to dereference URN/URI that could be
easily applied to this.

In fact, if they get implemented, then the description in
draft-mealling-oid-urn-02.txt becomes instantly dereferencable; with only a need
for a registration of the type.

The question is to know what you will get when you dereference it.

> advantage should not be underestimated.

The problem here is that you can get the text form from the numbers, but it's
more difficult to get the number form from the text and to ensure there is only
one representation of the text form.

What must be registered is the number, not the text.

I think a BER/DER like solution, where the string _could_ be represented with
the text, at places where it's not required to have a unique representation
(ouside of signed content) can be used.

> i found it, with a link to it, via the rfc-editor page. i cannot connect to

Found a link to it as an expired draft ?!
http://www.ietf.org/internet-drafts/draft-mealling-oid-urn-02.txt

I assume this version is the same as the version submitted to the RFC editor,
and is keeped there until the RFC is available.

> the URN approach the we discussed.

Indeed, this _is_ the urn approach that was discussed :

draft-mealling-oid-urn-02.txt :
3. Examples

   The following examples are taken from the example OIDs from the
   Introduction:
      urn:oid:1.3.6.1
      urn:oid:1.3.6.1.4.1
      urn:oid:1.3.6.1.2.1.27
      URN:OID:0.9.2342.19200300.100.4