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

KeyInfo Extensibility poll

From: Donald E. Eastlake 3rd <lde008@dma.isg.mot.com>
Date: Tue, 23 Jan 2001 14:54:49 -0500
Message-Id: <200101231954.OAA27293@noah.dma.isg.mot.com>
To: w3c-ietf-xmldsig@w3.org
cc: lde008@dma.isg.mot.com

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:

   <pgp:PGPData xmlns:pgp="http://www.ietf.org/...">

2. By including external elements as a *complement* only to children
elements of a ds:structure. (Presently reflected in Editors' Draft)

     <pgp:someOtherElement xmlns:pgp="http://www.ietf.org/...">

3. By placing a new structure in an existing ds:structure as a
*replacement*.  Example:

     <pgp:PGPData xmlns:pgp="http://www.ietf.org/...">

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

Received on Tuesday, 23 January 2001 14:55:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:35 UTC