W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2001

RE: KeyInfo Extensibility poll

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Mon, 29 Jan 2001 16:26:38 -0500
Message-Id: <4.3.2.7.2.20010129160221.02a7a8d0@rpcp.mit.edu>
To: Brian LaMacchia <bal@microsoft.com>
Cc: "'merlin'" <merlin@baltimore.ie>, "'Donald E. Eastlake 3rd'" <lde008@dma.isg.mot.com>, "'w3c-ietf-xmldsig@w3.org'" <w3c-ietf-xmldsig@w3.org>
At 10:55 1/25/2001 -0800, Brian LaMacchia wrote:
>Since all of KeyInfo is optional, by definition if you don't understand a
>clause you come across you drop it on the floor.

Agreed, and the bit we're trying to understand is if some folks want to be 
able to say:

1. "I understand "http://www.w3.org/2000/09/xmldsig#PGPData" and its 
children element types and only those element types; I might understand 
other namespaces under KeyInfo"

2. "I understand "http://www.w3.org/2000/09/xmldsig#PGPData" and its 
children element types from the dsig namespace and maybe some other children 
of a similar sort of meaning from other namespaces"

There's a tradeoff between the clarity of the namespace in option 1, and the 
small bit of metadata "typing" implied in option 2. When it comes to 
parsing, these lead to the following models:

1. I find foo:bar under KeyInfo, I don't even have a clue if I care about 
it, but I can dereference the namespace, grab the schema, and understand its 
type from that.

2. I find foo:bar under PGPData, I can infer whether I care or not 
immediately because I know if I care about PGPData.

So you're approach does give a hint as to whether one should even bother to 
dereference and chase down a schema, but it also encourages folks to extend 
our elements (in a potentially confusing way) where I'd like to encourage 
them to make a clean replacement and use schema typing to explicitly define 
the relationship.

>One of my main objections with option 1, which I raised previously during
>the flap over the exact structure of X509Data, is that the XMLDSIG WG should
>not be in the position of specifying a fixed, non-extensible Scheme for data
>types that are "owned" by another WG.

We own our namespace; they own there's.

>If this WG is not willing to support extensibility within the "best-guess"
>structures we have created to foster use of the output of the other WGs, I
>humbly suggest that our best, safest course of action would be to remove the
>X509Data, SPKIData and PGPData sections in their entirety from the draft and
>let each of the other WGs issue RFCs that specify sub-elements of KeyInfo
>that best represent their own work product.

The nice thing is that they can do exactly this without dropping out 
"best-guess" approximations because other WGs will do their work in their 
own namespace. Actually, my interest in not having extensibility at the type 
level (PGP, X509, SPKI) is to encourage other WGs to do a better job at the 
schema class level, instead of hacking on extensions to ours at the instance 
level.

__
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
Received on Monday, 29 January 2001 16:26:56 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:12 GMT