Re: Moving a Thread to the List: KeyInfo Extensibility

Hi,

From:  merlin <merlin@baltimore.ie>
To:  "Joseph M. Reagle Jr." <reagle@w3.org>
Cc:  "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>, muraw3c@attglobal.net,
            Brian LaMacchia <bal@microsoft.com>,
            "Donald Eastlake" <dee3@torque.pothole.com>, lde008@dma.isg.mot.com
In-reply-to:  <4.3.2.7.2.20010116180220.02b74408@rpcp.mit.edu> 
Date:  Wed, 17 Jan 2001 15:30:15 +0000
Sender:  merlin@baltimore.ie
Message-Id:  <20010117153015.B60FD43C69@yog-sothoth.ie.baltimore.com>
>
>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.

Aren't all extensions under some ancestor element under the dsig
namespace (except, in some sense, attribute extensions...)?

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

Well, if an implementation had only the mandatory KeyValue and
provided for registration of other KeyInfo child types, it would
hardly matter how many other KeyInfo child types there were or whether
or not they allowed extensions within them.  The only type of
registration you would need to worry about was KeyInfo children.
((Well, you could have a common facility in your core XMLDSIG
implemention to register KeyInfo grandchildren by call a registration
entry in previously registered KeyInfo child code but such a
facility's complexity is invarient with the number of KeyInfo children
whether or not defined in the dsig namepace.))

If some particular KeyInfo child type, say PGP, is included in an
XMLDSIG implementation, then I guess it might need to provide for
registration of new PGP children, but that seems to make sense to me.

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

It looks to me like we can sufficinetly define the KeyInfo types
provided in the dsig namesapce.

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

The requirement from the requirements document that arbitrary key
agreement methods be supported by the specifciation seems to imply at
least extension of KeyInfo.  Of course, this does not mean that any
particular implementation need support such extensions.

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

Further comments, including comments on my comments, welcome.

Thanks,
Donald

>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 Thursday, 18 January 2001 16:27:19 UTC