Re: Question on OIDs and URIs

At 03:18 PM 2000-12-06 +0000, Juan Carlos Cruellas wrote:
>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.

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.

>
>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.

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.

>ETSI thinks that this is a very generic topic where both sides, ASN.1
>people and 
>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.

>
>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>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.

>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)
>

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?


>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.

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.  

>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...
>

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. 

>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.

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

>
>Thank you in advance for your time and interest.
>
>Best regards.
>
>Juan Carlos Cruellas
>

Received on Wednesday, 6 December 2000 13:42:27 UTC