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.

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 GMT

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