Re: KeyInfo Extensibility poll

From:  merlin <merlin@baltimore.ie>
To:  "Donald E. Eastlake 3rd" <lde008@dma.isg.mot.com>
Cc:  w3c-ietf-xmldsig@w3.org
In-reply-to:  <200101231954.OAA27293@noah.dma.isg.mot.com> 
Date:  Wed, 24 Jan 2001 12:13:54 +0000
Message-Id:  <20010124121354.A770944995@yog-sothoth.ie.baltimore.com>

>Hi Donald,
>
>>- Hughes wants "minimality", which might perhaps mean no extensibility,
>>but says that as long as you can do extension type 1 above, you might
>>was well be able to do something like 2 or 3.
>
>Maybe I mis-expressed myself. I want minimality but sufficiency.

Sorry, it appears I did misunderstand you.

>Option 1 fits the bill precisely: extensibility at a low-enough
>level to be useful (sufficiency) but at a high-enough level to
>be easily implemented and interoperated (minimality). Disallowing
>any extensibility fails sufficiency.
>
>By sticking with fixed SPKIData, X509Data, and PGPData we can
>guarantee baseline interop with fixed, well-defined types.
>
>By allowing these XMLDSIG defined elements to be extended, we
>are restricting interoperability: What do I do with parts of an
>X509Data that I don't understand? Ignoring them is not valid,
>because they may be critical to the use of the element. Do we
>add a criticality flag? Do we fudge the issue and say that if
>a new part is critical you must define a new KeyInfo type?

Well, my personal opinion is that allowing any extensibility allows
consenting parties to be non-interoperable with the rest of the world.
Unless we specificially define some particular circustances, such as
option 2, to be "non-critical", the only safe assumption by
implementations ignorant of the extension is that it is critical.

Donald

>Forcing modified elements to be defined under a new namespace
>solves these problems. If I don't understand the type I ignore
>it. If I do understand it, I process it. And I can, as a
>baseline, process all the basic types defined by the spec
>completely.
>
>So, I prefer 1, but if we choose 2 we may as well go with 3
>because the issues are largely the same with the two.
>
>Merlin
>
>r/lde008@dma.isg.mot.com/2001.01.23/14:54:49
>>
>>Everyone agrees that folks need to be able to add their own KeyTypes
>>as a child of KeyInfo.  The question is how we should enable them to
>>extend the structures we defined (SPKIData, X509Data, PGPData).
>>
>>Three options for extending these KeyTypes:
>>
>>1. By creating a new structure under ds:KeyInfo. One could use schema
>>to define the new structure as an extension/restriction of one of the
>>three ds:structure's.
>>
>>Exampe of a schema that says pgp:PGPData is just like the dsig one but
>>has an extra element of a given type:
>>
>><ds:KeyInfo>
>>   <pgp:PGPData xmlns:pgp="http://www.ietf.org/...">
>>     <pgp:PGPKeyID>...</pgp:PGPKeyID>
>>     <pgp:someOtherElement>...</pgp:someOtherElement>
>>   </pgp:PGPData>
>></ds:KeyInfo>
>>
>>2. By including external elements as a *complement* only to children
>>elements of a ds:structure. (Presently reflected in Editors' Draft)
>>Example:
>>
>><ds:KeyInfo>
>>   <ds:PGPData>
>>     <ds:PGPKeyID>...</ds:PGPKeyID>
>>     <pgp:someOtherElement xmlns:pgp="http://www.ietf.org/...">
>>      ...</pgp:someOtherElement>
>>   </ds:PGPData>
>></ds:KeyInfo>
>>
>>3. By placing a new structure in an existing ds:structure as a
>>*replacement*.  Example:
>>
>><ds:KeyInfo>
>>   <ds:PGPData>
>>     <pgp:PGPData xmlns:pgp="http://www.ietf.org/...">
>>       <pgp:PGPKeyID>...</pgp:PGPKeyID>
>>       <pgp:someOtherElement>...</pgp:someOtherElement>
>>     </pgp:PGPData>
>>   </ds:PGPData>
>></ds:KeyInfo>
>>
>>
>>- Reagle would like to prohibit technique 3 and encourage the use
>>of schema extension capabilities to describe the relationship between
>>ds:PGPData and pgp:PGPData.
>>
>>- LaMacchia wants to permit technique 3 as one can get an implicit
>>typing (the fact that pgp:PGPData appears within ds:PGPData can be
>>inferred to mean that pgp:PGPData is somehow related without depending
>>on schema.
>>
>>- Salz agrees with LaMacchia.
>>
>>- Hugues wants "minimality", which might perhaps mean no extensibility,
>>but says that as long as you can do extension type 1 above, you might
>>was well be able to do something like 2 or 3.
>>
>>
>>We need to resolve this reasonably quickly.  Another way of looking at
>>the three, from the limited point of view of syntactic prohibitions is
>>as follows:
>>
>>(1) Prohibit any elements, other than what we define in our namespace,
>>inside SPKIData, X509Data, and PGPData.
>>
>>(2) Prohibit elements beyond what we define unless one of our
>>subelements is also present in SPKIData, X509Data, or PGPData.
>>
>>(3) No prohibition. The entire content of SPKIData, X509Data, or
>>PGPData can be from another namespace.
>>
>>But we want to go beyond mere syntax and give some use recommendations...
>>
>>(1) In case one, there isn't much to say because any extension or
>>replacement of one of these three elements must be done, as the
>>addition of a novel type of key data element, by adding some new
>>element as a child of KeyInfo.
>>
>>(2) In this case, one would logically recommend adding subelements to
>>SPKIData, X509Data, or PGPData where you are complementing it but if
>>you are replacing it with a sufficiently new SPKI, X509, or PGP key
>>info element, then you should define a new element under KeyInfo as
>>you would if you were defining a entirely new type of child element
>>under KeyInfo.
>>
>>(3) In this case, one would logically recommend adding subelements to
>>SPKIData, X509Data, or PGPData where you are complementing it but
>>completely replacing their contents, still using the same outer
>>element, if you are defining a sufficiently new but related element.
>>It is still necessary to retain the capability of defining an
>>entirely new type of child element under KeyInfo.
>>
>>
>>People should indicate to the list and/or me in the next few days
>>which option they prefer and new points in the discussion are welcome.
>>
>>Thanks,
>>Donald
>>
>

Received on Thursday, 25 January 2001 00:26:09 UTC