- From: Donald E. Eastlake 3rd <lde008@dma.isg.mot.com>
- Date: Tue, 23 Jan 2001 14:54:49 -0500
- 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: <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 Tuesday, 23 January 2001 14:55:00 UTC