- From: merlin <merlin@baltimore.ie>
- Date: Tue, 13 Mar 2001 17:33:49 +0000
- To: "Joseph M. Reagle Jr." <reagle@w3.org>
- Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Hi Joseph, My personal preference is that we use a choice, and define as a semantic rather than syntactic error, the presence in a signature of multiple key values. The choice is a very simple structure that is flexible and easy to work with. A strict ordering would increase implementational complexity; it clearly increases schema complexity; and would seem to require a justification of the order we chose. I don't see how the lack of order impacts upon "derivations" if, by that, I am to understand derived schemata. This would also, by side effect rather than intent, satisfy the desire that other standards can reuse our key info where multiple key values make sense. Merlin r/reagle@w3.org/2001.03.07/15:18:06 >As already mentioned, the definition of ds:KeyInfo uses a (1,unbounded) >choices over mandatory elements to emulate an unordered set of optional >elements. On hindsight this appears to be a bad choice for a couple reasons. >First, it can make derivations difficult as the optionality can not be >easily constrained since it is "simulated." Second, I thought an unordered >list was preferable but now it seems preferable to know when you are going >to see these elements (e.g., what's the point of having these things in a >random order, particularly elements from an external namespace). Third, with >our present approach of using choice, I can't think of a way to constrain >KeyValue to occurring once. (See examples below of how this can be >expressed). The only down side is that this sort of structure permits and >empty KeyInfo, which Merlin just suggested a fix for given use of "choice." > >Any thoughts? > >__ > ><element name="KeyInfo" type="ds:KeyInfoType"/> ><complexType name="KeyInfoType" mixed="true"> > <sequence> > <element ref="ds:KeyName" minOccurs="0" maxOccurs="unbounded"/> > <element ref="ds:KeyValue" minOccurs="0" maxOccurs="1"/> > <element ref="ds:RetrievalMethod" minOccurs="0" maxOccurs="unbounded"/> > <element ref="ds:MgmtData" minOccurs="0" maxOccurs="unbounded"/> > <element ref="ds:PGPData" minOccurs="0" maxOccurs="unbounded"/> > <element ref="ds:SPKIData" minOccurs="0" maxOccurs="unbounded"/> > <element ref="ds:X509Data" minOccurs="0" maxOccurs="unbounded"/> > <any processContents="lax" namespace="##other" minOccurs="0" >maxOccurs="unbounded"/> > <!-- (0,unbounded) elements from (0,unbounded) namespaces --> > </sequence> > <attribute name="Id" type="ID" use="optional"/> ></complexType> > > > <!ELEMENT KeyInfo (#PCDATA|KeyName*|KeyValue?|RetrievalMethod*| > X509Data*|PGPData*|SPKIData*|MgmtData* %KeyInfo.ANY;) > > <!ATTLIST KeyInfo > Id ID #IMPLIED > > >[1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JanMar/0122.html > >__ >Joseph Reagle Jr. http://www.w3.org/People/Reagle/ >W3C Policy Analyst mailto:reagle@w3.org >IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature >W3C XML Encryption Chair http://www.w3.org/Encryption/2001/ > > ----------------------------------------------------------------------------- Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. http://www.baltimore.com
Received on Tuesday, 13 March 2001 12:34:33 UTC