Re: Moving a Thread to the List: KeyInfo Extensibility

I vote for minimality.

In my opinion, and it is hard for me to clarify where this
falls within the arguments of the assembled assailants, or
if it is a valid and supportable argument, or even relevant,
it is better to limit, where possible, the scope for
arbitrary extensions within _elements_ under the dsig
namespace.

Wherever there is scope for extensions, within my basic
dsig implementation I have to allow support for handler
registration and I have to add logic that allows these
extensions to be processed and I have to decide how to
proceed if I don't understand such extensions. This
makes sense in a broad scope -- SignatureMethod, KeyValue,
... - but at a certain point I become mired in the
multiplicity of options.

If we cannot define a concrete PGPData element (for example)
that I can either support completely or ignore completely,
then it seems to me that we should at the most define an
extensible (schema) type, but no corresponding element.
This allows an external entity to define a KeyInfo element
that provides a full definition of PGPData in their own
namespace, but I don't have to provide support for these
extensions within my implementation of a PGPData element
from the basic spec.

I think I'm trying to say, why define a primitive element
at all if we cannot define it sufficiently?

Based on what I think are the arguments, I disagree with
both Brian and Joseph! I don't want to be able to mess
with the content of the most primitive XMLDSIG elements at
all; doing so adds what are (in my opinion) unnecessary
option to the elements.

However, if it is mandatory that we support extension of
these primitive elements by either complement or replacement,
then I would fall on Brian's side (support replacement in
addition to complement) because the (unnecessary, to belabour
my opinion) complexity is equal for either case.

I've already written too many words, so I'll end how I begin.
I vote for minimality.

Merlin

r/reagle@w3.org/2001.01.16/18:23:25
>
>Brian and I have been working on clarifying the use of the <ANY> within the 
>KeyInfo children (PGPData, SPKIData, etc.) for extensibility purposes. At 
>first, I thought it was an editorial issue of trying to harmonize the 
>inconsistent use of ANY in the different KeyTypes. Part of these 
>inconsistencies arose from a disconnect between myself and Brian in that 
>Brian intended the ANY to be used to extend elements from our namespace. I 
>expected ANY to be only be present to permit our types to be replaced. Both 
>of these view points are reflected in different KeyTypes and I'm agreeable 
>to ANY being used in KeyInfo for replacement, and in the KeyTypes as 
>complements (but not replacements). Consequently, we've been trying to 
>identify schema/DTD constructs that prohibit empty content:
>
>   [a] <PGPData></PGPData> <!-- not a biggie, but silly -->
>
>or prohibit content that is only from an external namespace (I think it 
>should be under KeyInfo then):
>
>   [b] <PGPData><foo:MyPGPData>bar</foo:MyPGPData></PGPData>
>
>However, at this point, Brian asked with good cause why not permit [b]? We 
>don't yet agree why it should or should not, so we're bouncing it back to 
>the list for discussion. You can see the areas of the spec affected by this 
>issue in [1], underlined in red. I'll bounce our last two messages to the 
>list as well for wider comment/review.
>
>I'll ask Don to bring this issue to a close. <smile>
>
>[1] http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html#sec-KeyInfo
>
>__
>Joseph Reagle Jr.
>W3C Policy Analyst                mailto:reagle@w3.org
>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
>

Received on Wednesday, 17 January 2001 10:30:57 UTC