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

Re: KeyInfo Extensibility poll

From: merlin <merlin@baltimore.ie>
Date: Wed, 24 Jan 2001 12:13:54 +0000
To: "Donald E. Eastlake 3rd" <lde008@dma.isg.mot.com>
Cc: w3c-ietf-xmldsig@w3.org
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.

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?

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 Wednesday, 24 January 2001 07:14:28 GMT

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