Subject: Question on OIDs and URIs

From: Juan Carlos Cruellas <[email-masked]>
Date: Wed, 6 Dec 2000 15:18:31 +0000

Dear all,

My name is Juan Carlos Cruellas and I am involved in a work dealing with
electronic signature formats. ETSI has issued its standard
TS 101 733 "Electronic Signature Format" which defines a format for electronic
signatures valid in the long term (by usage of timestamping techniques).
The core format is based on the CMS  structure defined in the RFC 2630,
with the adition of a number of  what in CMS document are known as signed
and unsigned attributes (additional  information qualifying the digital
signature
for people familiar with XML terminology).
At the same time, ETSI, being aware of the growing importance of XML syntax
and of the
works dealing with digital signature in XML, expressed its interest in
having something
similar to its electronic signature but in XML syntax.
ETSI launched a work whose final objective is to define new XML types able
to contain
identical information (semantically speaking)  to the information
contained in the new ASN.1 structures defined in the ETSI document.
The results of this work will be then, new XML types whose data can be
incorporated to the
XML digital signature structure defined by the W3c/IETF digital signature
group.

We, at the UPC, are in charge of the editorial work of this specification,
and there have been produced
a number of drafts.

The reason for send you this e-mail is related with the following problem:

In ASN.1 the usual way for identifying, let's say a Policy for signature,
is an OID.
In XML, identification and reference of objects is made using URIs.
So the problem appears when one treats of incorporating information of an
OID in an XML document by converting it in a special form of an URI.

ETSI thinks that this is a very generic topic where both sides, ASN.1
people and
XML people will likely have something to say.

The alternatives raised up to now are:

1. The draft being produced by Michael Melling (draft-mealling-oid-urn-...)
where the proposal is made of representing OIDs as URNs, leading to something
like:
        urn:oid:1.3.6.1

2. A URL with a fixed a base and appended the OID in an human readable format:
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)

3. As an URN but with the human readable text included:

urn:oid:itu-t(0)/identified-organization(4)/etsi(0)/electronic-signature-sta
ndard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)

These three proposals have been discussed among several people
in the XML digital signature group, ETSI group, and the group that
works in the production of the RFC draft and different views have
been expressed.

Concerns on possible mismatching between numbers and text in the
representation
with text, have been raised. In the same direction, it has
been said that automatic processing is facilitated if only numbers
appear....
But human readibility have been argued as a critery supporting
the incorporation of the text.

Besides the former, the issue raised by approaches 2 and 3 is
the identification of the organization "in charge" of the OID,
which is repeated. Arguments against these repetitions have
also been raised...

It is our intention, by sending this e-mail to ask your opinion on this
issue, in order to get a major number of views and take, in the
end, a better decision.

Thank you in advance for your time and interest.

Best regards.

Juan Carlos Cruellas

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 6 Dec 2000 10:32:28 -0500

Howdy,

This is perhaps a good time to point out that there is a maximum
length of URIs.  Whether it's de jure (can't find the reference just
this minute) or de facto, URIs of longer than 255 characters will cause
problems.  Which sort of argues for the URN:OID proposal from Michael
Mealling, of the 3 you have outlined, since (apart from anything else)
the ones with "human readable" components seem capable of being quite
expansive.

Leslie.

--

-------------------------------------------------------------------
"Days used to be longer."
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Al Gilman <[email-masked]>
Date: Wed, 6 Dec 2000 14:18:31 -0500

>XML digital signature structure defined by the W3c/IETF digital signature

It is desirable to avoid new XML types unless the type is really different.
The criteria for when you have a novel type vs. just appearing in a new
location are different.  This is a domain analysis issue which affects your
total XML usage profile.  This can be separated, a bit, from the smaller
question of how to identify a resource (the signature-related policy) in
URI-conformant form within this XML application profile.

You may view the task before you as a special case of schema mapping as used
for data mediation.  An example approach supported by running code is
discussed
in

<http://www-diglib.stanford.edu/cgi-bin/get/SIDL-WP-1999-0126>http://www-di
glib.stanford.edu/cgi-bin/get/SIDL-WP-1999-0126

It sounds as though one approach here could be to start with one mapping at
the
level of CMS to XML Schema.  Then use XML Schema to derive the ETSI
signature-in-XML practice (presuming it is actually more restrictive than the
general XML signature practice) as a mutual specialization of the
ETSI-signature specialization of CMS and the XML-Signature target environment
types.

>OID in an XML document by converting it in a special form of an URI.

You have both problems.

Yes, in XML all you are basically required to do is to represent the policy
identity in some scheme conforming to the general requirements for URIs.  That
is all that XML per se requires of you.  On the other hand, you do need to
survey your user community for what operations on "policy on which signature
depends" need to be supported consistently and interoperably.

The OID-using community needs to form their own consensus a) that they want a
URI-conforming transliteration or representation for OIDs and b) how much they
wish to standardize this and how (numbers vs. expanded form, etc.).

However, you also have the problem in the ASN.1-based usage pattern of how to
deal with policies identified by any URI, and not just the OID-identified
policies.

>XML people will likely have something to say.

You need to expand this to ASN.1 people, XML people, and URI people.

It is important to distinguish what aspects of this design problem are
properly
in the purview of which group to hold the ultimate decision power on.

><http://www.etsi.org/oid/itu-t>http://www.etsi.org/oid/itu-t(0)/identified
-organization(4)/etsi(0)/electron
>ic-signature-standard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)

This is IMHO significantly less than the highest and best use of the URI
space.

The OID using community has the option of pursuing recognition (using the
standard IETF scheme recognition processes) for either a sub-scheme of urn: as
proposed by Mealling or a top-level scheme parallel to URN.  But using the
http: scheme, unless what follows is going to get you some useful stuff when
one does an HTTP GET on it, is going to generate more heat than light and
should be avoided.

>ndard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)

The point is that the information model for OIDs defines the number form and
the text form as synonyms.  So it is not a question of picking which one you
use in a URI scheme.  The service that you offer to the "policy publisher" is
broken if someone wishing to follow the policy cannot easily move back and
forth between the two synonymous forms of identification defined in the OID
pattern of practice.

The reference model for your security architecture should include a model (a
schema of [possibly virtual] data) which defines this synonym relationship and
the rules for each variant form.  This synonym relationship between variant
data forms must also be covered by conversion services in order for the
alternative pattern not to break the application of policies in the signature
practice.

The pattern of practice that you have to standardize among those using OIDs to
identify policy descriptions that signatures will depend on has to be broader
than just one data representation.  The appropriate bundle to standardize
is an
"application profile," a bundle of representations and services which
assures a
healthy life-cycle for the identification of the policy document and its
reference and recovery as appropriate.

What is the existing best current practice for moving back and forth between
numeric and textual forms of OIDs?  Is this service part of the standards
profile of what to implement with regard to the proposed ASN.1-based security
services?  Is it [like LDAP] already covered with URI-conformant service
identification forms of reference?

>the incorporation of the text.

If humans don't have access to the human information of "whose policy are you
following" then the system is broken.

Human interpretation of the context of policy on which the signature
depends is
a valid requirement, and the ASN.1-based signature application profile should
support it well.

This does not [by virtue of logic] have to be satisfied by putting the
human-comprehensible information in the data of the XML signature block.  On
the other hand, if current OID use policies allow for the use of the text form
with the numeric form as an ad_lib alternative, this (signature practice) may
not be the place to standardize on numbers.  If OID doctrine says that numbers
are the standard and text synonyms are a permitted alternative, then you have
to think twice before breaking this OID tradition.

You may well have internationalization or canonicalization problems with
respect to the longer forms of the OIDs, but this is a small matter of
programming, and there are resources in the canonicalization methods
associated
with XML signature and the work on internationalization of URIs that may be of
assistance.

This is a decision to be worked out by the OID using community.  One option is
to decide, in signature practice, to standardize on the numeric form of OIDs.
In this case, it is important that there be services which are highly
available
that allow one to trace back from numeric OIDs to text OIDs and human readable
representations of the policies.

>which is repeated. Arguments against these repetitions have

This is a problem wired into the logical definition of the OIDs.  There are
logically two questions, and they need to be separated.  1) If the
publisher of
the policy wishes to identify their policy by an OID, how to provide for
URI-conformant expression of this identification suitable for use in XML
and 2)
Given all URI-conformant forms of identification, which will be equally
acceptable to XML, do policy publishers really wish to always identify their
policies via the OID route?

[major IMHO disclaimer]  I would be thinking of setting up the model of what
the information is you actually capture in the OID dictionary, and be
preparing
to deal with any form of identification which succeeds in reproducing this
information.  The binding from information fields to OID path order may in
fact
be introducing constraints that you would like to get out from under
eventually.

You will probably be under pressure, if you decide to remove the redundant
reference to the congnizant organization, to demonstrate a reference
implementation of all relevant transforms.  This doesn't seem like a serious
technical risk if you develop the binding in a schema-based environment.

>issue, in order to get a major number of views and take, in the

An excellent move.

I would also encourage you or someone on your team to monitor what is going on
in the security and information services working groups in the Global Grid
Forum <http://<http://www.gridforum.org/>www.gridforum.org/>.
They have the same general problem and may have valuable ideas to
contribute to
a solution or may be good customers for what you work out.

Al