RE: Revised syntax proposal

Dave,

I do not want to engage in a polemic, but I would greatly appreciate that
you make sure that I have been given a chance to review a draft before you
post it on the list with my name listed among the authors. This being said,
please find my comments below.


>  <!ELEMENT signature (signedInfo, keyInfo?, sigValue)>
>  <!ATTLIST signature
>          id     ID      #IMPLIED>
>

1.1- Adopt a naming convention.
Why signedInfo if sigValue? idem for signedAttributes and sigAlg.
So, what do you think about sigValue, sigAttributes, sigAlg, and sigInfo.
Notice, btw, that I was happy so far with Attributes and Value...


1.2- I still argue that there is no obvious benefit to keep the KeyInfo
element outside the scope of the signature. Conversely, there are known
attacks on the signature when the KeyInfo is not protected. Among others, if
a party is issued a plurality of certificates for a same key but different
attributes, you can substitute one certificate for another without impairing
signature verification. Probably some will argue that it is a flaw in X509
(actually true for a large majority of the certificate-based infrastructures
in place) and that the key alone should prevail. Unfortunately, the world is
the way it is, and for the forseeable future I feel that we should
accomodate with it and its flaws.

>  <!ELEMENT signedInfo (algorithms, (object|reference),
> signedAttributes?)>

2.1- I think that we can do without the algorithms element and expand
c14nAlg and sigAlg at this level. There is nothing wrong (from a data model
standpoint) to say that these two elements are direct properties of the
signature.

2.2- I would not distinguish between obejct and reference at this level.
From a model standpoint, the signature is applied to a resource, which one
can be given by reference or by value. The distinction should be done
further down the tree.

2.3- Considering prior comments I would propose (disregard the order):
<!ELEMENT sigInfo (c14nAlg?, sigAlg, keyInfo, resource, attributes)>

<!ELEMENT resource (reference | value)>
<!ELEMENT reference (locator, digest)>

Alternatively, we might propose (from a model standpoint I like the previous
one better)

<!ELEMENT resource ((locator, digest) | value)>

>
>  <!ELEMENT keyInfo ANY>
>  <!ATTLIST keyInfo
>          type CDATA #REQUIRED >

3.1- To follow XML common practices, might be should we turn all type
attributes into a URL (at least URI). If so, the keyInfo element (as well as
others) should be turned into simple xlinks (though never used as a link).

<!ELEMENT keyInfo ANY>
<!ATTLIST keyInfo
     xml:link   CDATA   #FIXED   'simple'
     href       CDATA   #REQUIRED
>
>  <!ELEMENT sigValue (#PCDATA)>
>  <!-- base64 encoded signature value -->
>
>  <!ELEMENT algorithms (c14nAlg, sigAlg)>
>

4.1- see comment 2.1 above.

>  <!ELEMENT c14nAlg ANY>
>  <!ATTLIST c14nAlg
>          type CDATA #REQUIRED >

5.1- see comment 3.1 above.

>
>  <!ELEMENT sigAlg ANY>
>  <!ATTLIST sigAlg
>          type CDATA #REQUIRED >
>

6.1- see comment 3.1 above.

>  <!ELEMENT digestAlg ANY>
>  <!ATTLIST digestAlg
>          type CDATA #REQUIRED >
>
7.1- see comment 3.1 above.

>  <!ELEMENT signedAttributes (attributeData+)>
>  <!-- must be at least one attributeData or omit the element-->
>
>  <!ELEMENT attributeData ANY>
>  <!ATTLIST attributeData
>          type CDATA #REQUIRED >

8.1- I propose that you adopt a single model for algorithm parameters and
attribute values. Either you allow ANY at the top level or you add an
intermediary element for type identification.

Option A: ANY top level

<dsig:c14nAlg type='http://xfdl.org/algorithms/c14n'>
  <xfdl:exclude>
    <xfdl:field href='comment'\>
    ...
  </xfdl:exclude>
</dsig:c14nAlg>
<dsig:attributes>
  <dsig:SigningTime>1998-10-29T13:26-0500</dsig:SigningTime>
</dsig:attributes>

Option B: With type element

<dsig:c14nAlg type='http://xfdl.org/types/alg/c14n'>
  <dsig:parameter type='http://xfdl.org/types/prm/c14n'>
    <xfdl:exclude>
      <xfdl:field href='comment'\>
      ...
    </xfdl:exclude>
  </dsig:parameter>
</dsig:c14nAlg>
<dsig:attributes>
  <dsig:attribute type='http://w3.org/xmldsig/types/attr/sigtime'>
    <dsig:date>1998-10-29T13:26-0500</dsig:date>
  </dsig:attribute>
</dsig:attributes>

To some extents, I like the first approach better for its compactness.
BTW, notice that I prefer to encapsulate the datetime in a specific element.
This provides for a stronger prototyping when use in parallel with an xml
schema. This will also help canonicalization of basic data types.

>
>  <!ELEMENT reference (resource)>
>
>  <!ELEMENT object (c14nAlg, content)>
>

9.1- Why should we specify a c14n algorithm? The content being encapsulated
into the sigInfo element, it is implicitly processed during canonicalization
of the sigInfo element.

I understand that an embedded content may have particular c14n requirements.
But, allowing a different c14n algorithm within the sigInfo means that you
have to define how you transition from one canonicalizer to the other or the
way you expect to pipe the result of one into the other (without breaking
the first one).

>  <!ELEMENT content ANY>
>  <!ATTLIST content
> 	 type CDATA #IMPLIED>
>

10.1- I suggest that you provide an encoding attribute. Also, we could have
share the same definition between content, sigValue, digestValue...

>  <!ELEMENT resource (location, c14nAlg, digestAlg, digest)>
>  <!ATTLIST resource
> 	 type CDATA #IMPLIED>
>

11.1- This description does not make any sense from a data model. c14nAlg
and digestAlg are not direct properties of a resource. A resource element
should be limited to a locator and a digest (though we could have add
attributes). c14nAlg, digestAlg are properties of the digest element:

<!ELEMENT resource (location, digest)>
<!ELEMENT digest (c14nAlg, digestAlg, value)>

>  <!ELEMENT location (#PCDATA)>

12.1- Location should rather be an xlink.

<!ELEMENT location EMPTY>
<!ATTLIST location
     xml:link CDATA  #FIXED 'simple'
     href     CDATA  #REQUIRED
>

>
>  <!ELEMENT digest (#PCDATA)>
>  <!-- base64 encoded digest value -->
>

13.1- see comment 11.1 above

>  <!ELEMENT manifest (resource+)>
>  <!-- the manifest may be used as an object, or referred to by a
>       reference; but is not part of the core signature syntax -->
>   <!ATTLIST manifest
>          id     ID      #IMPLIED>
>

14.1- May not have to be defined by this specification. Whoever needs
something like that could reuse the resource element definition.

> 4. Example
>
> <signature id="foo">
>    <signedInfo>
>       <algorithms>
>          <c14nAlg type="identity"/>
>          <sigAlg type="rsaWithSHA-1"/>
>       </algorithms>
>       <object>
>          <c14nAlg type="identity"/>
>          <content type="manifest">
>             <manifest id="bar">
>                <resource>
>                   <location> syntax.txt </location>
>                   <c14nAlg type="identity"/>
>                   <digestAlg type="sha-1"/>
>                   <digest> a23bcd43 </digest>
>                </resource>
>             </manifest>
>          </content>
>       </object>
>       <signedAttributes>
>          <attributeData type="signingTime">Its midnight
> here</attributeData>
>       </signedAttributes>
>    </signedInfo>
>    <keyInfo type="keyName"> 3 </keyInfo>
>    <sigValue> dd2323dd </sigValue>
> </signature>
>
> 5) Processing:
> Validation of an XML signature consists of the following steps

> a) canonicalization of the signed object based on c14n algorithm ID in
> the object element.
> b) c14n of the signedInfo element based on the c14n algorithm ID in
> the algorithms element.

15.1- the second canonicalization might actually break restrictions imposed
by the first one unless you encode the embedded object. Consider the
following:

   xml-canon( ... | identity(xml-object) | ... )

> c) obtain the validation keying info from keyInfo or externally.
> d) validate the sigValue based on the sigAlg ID in the algorithms
> element and the key obtained in step c.
>   - Digest calculation is performed over the canonicalized signedInfo
>     element including start and end tags.
>   - All signedAttributes are treated as opaque with respect to
>     processing.

16.1- If an xml schema is available, it might be interesting to canonicalize
the attribute values... But this is a canonicalization problem and should
not be addressed here.

>   - If a reference element is present, recalculate digest on item

17.1- In contradiction with what we have agreed upon in Boston...

17.2- Verification may happen in an environment that does have network
connectivity...

>     referenced and compare to digest value in resource element.
>

18.1- To summarize all my comments, here is an alternative DTD:

<!ELEMENT dsig:signature (dsig:sigInfo,dsig:value)>
<!ATTLIST dsig:signature
    xmlns:dsig  CDATA #FIXED %xmldsig.dtd
    id          ID    #IMPLIED
>

<!ELEMENT dsig:sigInfo (dsig:resource,dsig:attributes?,
          dsig:keyInfo,dsig:c14nAlg?,dsig:sigAlg)>
<!ATTLIST dsig:sigInfo
    xmlns:dsig  CDATA #FIXED %xmldsig.dtd
>

<!ELEMENT dsig:resource (dsig:attributes?,(dsig:reference|dsig:value))>
<!ATTLIST dsig:resource
    xmlns:dsig  CDATA #FIXED %xmldsig.dtd
>

<!ELEMENT dsig:reference (dsig:locator,dsig:digest)>
<!ATTLIST dsig:reference
    xmlns:dsig  CDATA #FIXED %xmldsig.dtd
>

<!ELEMENT dsig:locator EMPTY>
<!ATTLIST dsig:locator
    xmlns:dsig  CDATA #FIXED %xmldsig.dtd
    xml:link    CDATA #FIXED 'simple'
    href        CDATA #REQUIRED
>

<!ELEMENT dsig:digest (c14nAlg?, digestAlg, value)>
<!ATTLIST dsig:digest
    xmlns:dsig  CDATA #FIXED %xmldsig.dtd
>

<!ELEMENT dsig:c14nAlg ANY>
<!ATTLIST dsig:c14nAlg
    xmlns:dsig  CDATA #FIXED %xmldsig.dtd
    xml:link    CDATA #FIXED 'simple'
    href        CDATA #REQUIRED
>

<!ELEMENT dsig:digestAlg ANY>
<!ATTLIST dsig:digestAlg
    xmlns:dsig  CDATA #FIXED %xmldsig.dtd
    xml:link    CDATA #FIXED 'simple'
    href        CDATA #REQUIRED
>

<!ELEMENT dsig:sigAlg ANY>
<!ATTLIST dsig:sigAlg
    xmlns:dsig  CDATA #FIXED %xmldsig.dtd
    xml:link    CDATA #FIXED 'simple'
    href        CDATA #REQUIRED
>

<!ELEMENT dsig:value ANY>
<!ATTLIST dsig:value
    xmlns:dsig  CDATA      #FIXED   %xmldsig.dtd
    encoding (none|base64) #IMPLIED 'base64'
>

<!ELEMENT dsig:keyInfo ANY>
<!ATTLIST dsig:keyInfo
    xmlns:dsig  CDATA      #FIXED   %xmldsig.dtd
>

<!ELEMENT dsig:attributes ANY>
<!ATTLIST dsig:attributes
    xmlns:dsig  CDATA      #FIXED   %xmldsig.dtd
>

Later on, we could propose a series of keyInfo types as well as signature
attributes and resource attributes (if we keep this last one).

Example (inspired from previous one):
-------------------------------------

<dsig:signature>
  <dsig:sigInfo>
    <dsig:resource>
      <dsig:value>
        <myelement>
          <mysubelement/>
        </myelement>
      </dsig:value>
    </dsig:resource>
    <dsig:attributes>
      <dsig:sigTime>1998-10-29T13:26-0500</dsig:sigTime>
    </dsig:attributes>
    <dsig:keyInfo>
      <dsig:keyID>3</dsig:keyID>
    </dsig:keyInfo>
    <dsig:c14nAlg href='http://w3.org/xmldsig/xc14n'/>
    <dsig:sigAlg href="http://w3.org/xmldsig/rsaWithSHA-1"/>
  </dsig:sigInfo>
  <dsig:value encoding='base64'>ekgrtdd2323dd</dsig:sigValue>
</dsig:signature>


Sincerely,

Richard D. Brown
Chief Software Architect - R&D
Globeset, Inc. Austin, TX - U.S.

Received on Wednesday, 11 August 1999 14:24:25 UTC