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

Re: KeyInfo: sequence or choice

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>
Message-Id: <20010313173349.8F06144397@yog-sothoth.ie.baltimore.com>

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.


>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" 
>     <!-- (0,unbounded) elements from (0,unbounded) namespaces -->
>   </sequence>
>   <attribute name="Id" type="ID" use="optional"/>
>    <!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.
Received on Tuesday, 13 March 2001 12:34:33 UTC

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