KeyInfo Extensibility poll results

I think the various sides of this issue
<http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JanMar/0039.html>
have been well argued and that it is unlikely there will be much
furhter change in opinion.  The consensus of the Working Group is for
option 2 and we will proceed on the basis of that choice.  This also
means including clearer criterion as to when elements other than those
we have defined can be included within the {X509|PGP|SPKI}Data
element.

I suggest the text in the editors draft at
<http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html#sec-KeyInfo>
be changed to be the HTML appended below.

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd                      dee3@torque.pothole.com
 155 Beaver Street                                +1 508-634-2066(h)
 Milford, MA 01757 USA                            +1 508-261-5434(w)




<h3>4.4 The <a id="sec-KeyInfo" name="sec-KeyInfo"><code>KeyInfo</code></a> Element</h3>

<p><code>KeyInfo</code> is an optional element that assists the recipient(s) in obtaining the
key needed to validate the signature. <code>KeyInfo</code> may contain keys, names,
certificates and other public key management information, such as in-band key distribution
or key agreement data. This specification defines a few types but applications may
extend those types or all-together replace them with their own key identification and
exchange semantics using the XML namespace facility. [<a href="#ref-XML-ns">XML-ns</a>]</p>

<p>If <code>KeyInfo</code> is omitted, the recipient is expected to be able to identify
the key based on application context information. Multiple declarations within <code>KeyInfo</code>
refer to the same key. While applications may define and use any mechanism they choose
through inclusion of elements from a different namespace, compliant versions MUST
implement <a href="#sec-KeyValue"><code>KeyValue</code></a> (section 4.4.2) and SHOULD
implement <code><a href="#sec-RetrievalMethod">RetrievalMethod</a></code> (section 4.4.3).</p>

<p>The following list summarizes the <code>KeyInfo</code> types defined by this
specification; these can be used within the <code>RetrievalMethod</code> <code>Type</code>
attribute to describe the remote <code>KeyInfo</code> structure as represented as an octet
stream.</p>

<ul>
  <li><a href="http://www.w3.org/2000/09/xmldsig#X509Data">http://www.w3.org/2000/09/xmldsig#X509Data</a></li>
  <li><a href="http://www.w3.org/2000/09/xmldsig#PGPData">http://www.w3.org/2000/09/xmldsig#PGPData</a></li>
  <li><a href="http://www.w3.org/2000/09/xmldsig#SPKIData">http://www.w3.org/2000/09/xmldsig#SPKIData</a></li>
  <li><a href="http://www.w3.org/2000/09/xmldsig#MgmtData">http://www.w3.org/2000/09/xmldsig#MgmtData</a></li>
</ul>

<p>The schema/DTD specifications of these types permit their children
elements to be extended/complemented with elements from another namespace.  This may be done only
if it is safe to ignore these extension elements.  If extension elements are added that must be
considered by a verifier, then a new child of <code>KeyInfo</code> should be defined.  Such a new
child may incorporate our elements, such as <code>X509Certificate</code>, and XML schema can be
used to describe the relation of such a new <code>KeyInfo</code> child to the <code>KeyInfo</code>
children we specify.</p>

<p>New <code>KeyInfo</code> children in another namespace might also be defined for entirely
new types of <code>KeyInfo</code> data or <em>alternative</em>
structures to those we define. For example, should a complete XML-PGP standard be defined, it could be used
as a new element in a different namespace that would be a child of <code>KeyInfo</code>.
Should someone define &quot;optional&quot; extensions
to the <code>ds:PGPData</code> children which can be safely ignored, they can be included as siblings.
In either case,
their element types will be in an external namespace.</p>

<p>In addition to the types above for which we define structures, we specify one
additional type to indicate a <a name="rawX509Certificate" id="rawX509Certificate">binary (ASN.1 DER)
X.509 Certificate</a>. 

<ul>
  <li><a href="http://www.w3.org/2000/09/xmldsig#rawX509Certificate">http://www.w3.org/2000/09/xmldsig#rawX509Certificate</a></li>
</ul>

<pre class="xml-dtd">
   Schema Definition:

   &lt;complexType name=&quot;KeyInfoType&quot; mixed=&quot;true&quot;&gt;
     &lt;!-- (0,unbounded) elements from (0,unbounded) namespaces --&gt;
     &lt;choice maxOccurs=&quot;unbounded&quot;&gt;     
       &lt;element name=&quot;KeyName&quot; type=&quot;string&quot;/&gt; 
       &lt;element name=&quot;KeyValue&quot; type=&quot;ds:KeyValueType&quot;/&gt; 
       &lt;element name=&quot;RetrievalMethod&quot; type=&quot;ds:RetrievalMethodType&quot;/&gt; 
       &lt;element name=&quot;X509Data&quot; type=&quot;ds:X509DataType&quot;/&gt; 
       &lt;element name=&quot;PGPData&quot; type=&quot;ds:PGPDataType&quot;/&gt; 
       &lt;element name=&quot;SPKIData&quot; type=&quot;ds:SPKIDataType&quot;/&gt;
       &lt;element name=&quot;MgmtData&quot; type=&quot;string&quot;/&gt;
       &lt;any processContents=&quot;lax&quot; namespace=&quot;##other&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;unbounded&quot;/&gt; 
     &lt;/choice&gt;
     &lt;attribute name=&quot;Id&quot; type=&quot;ID&quot; use=&quot;optional&quot;/&gt; 
   &lt;/complexType&gt;
</pre>

<pre class="xml-dtd">
   DTD:

   &lt;!ELEMENT KeyInfo (#PCDATA|KeyName|KeyValue|RetrievalMethod|
               X509Data|PGPData|SPKIData|MgmtData %KeyInfo.ANY;)* &gt;
   &lt;!ATTLIST KeyInfo  
    Id  ID   #IMPLIED &gt;
</pre>

Received on Thursday, 1 February 2001 21:59:37 UTC