W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999

RE: latest edits

From: Greg Whitehead <gwhitehead@signio.com>
Date: Fri, 8 Oct 1999 13:26:57 -0700
Message-ID: <6B962A1EE646D31193270008C7A4BAB509338B@mail.paymentnet.com>
To: "'w3c-ietf-xmldsig@w3.org'" <w3c-ietf-xmldsig@w3.org>
Sigh... parameters.  Looking at core-991008, we have the following
productions:

4.2 Signature Algorithm

  <!ELEMENT SignatureAlg ANY>
  <!ATTLIST SignatureAlg
          Algorithm    CDATA    #REQUIRED >
     <!-- Where CDATA conforms to the 
          productions specified by [URI] --> 

3.0 Signature Value

  <!ELEMENT SignatureValue CDATA)>
  <!-- base64 encoded signature value -->
  <!ATTLIST SignatureValue
          encoding    CDATA     "urn:dsig:base64"> 

Signature Algorithm and Value are split by necessity, since the Algorithm
needs to be signed.  I like the proposal to expand the Alg suffix and
replace the "Algorithm" attribute with a "name" attribute.


4.1 Canonicalization Algorithm

  <!ELEMENT CanonicalizationAlg ANY>
  <!ATTLIST CanonicalizationAlg
          Algorithm    CDATA    "null">
     <!-- Where CDATA conforms to the 
          productions specified by [URI] --> 

There is a proposal, which I favor, to fix the canonicalization algorithm in
SignedInfo and remove this element.


4.3.3 Transformation Algorithms

  <!ELEMENT Generic EMPTY >
  <!ATTLIST Generic
          Algorithm    CDATA    #REQUIRED >

  <!ELEMENT Encoding EMPTY >
  <!ATTLIST Encoding
          Algorithm    CDATA    #REQUIRED >

  <!ELEMENT CanonicalizationAlg EMPTY >
  <!ATTLIST CanonicalizationAlg
          Algorithm    CDATA    #REQUIRED >

  ...

Note that none of these algorithms have parameters.  This definition of
CanonicalizationAlg is inconsistent with 4.1, which is fine if 4.1 goes
away.

Given that none of the other transformation algorithms have the Alg suffix
in their names, I'm happy to remove it from CanonicalizationAlg (especially
if 4.1 goes away).  In any case, the proposal to replace the "Algorithm"
attribute with a "name" attribute applies.


4.3.4 Digest Algorithm

  <!ELEMENT DigestAlg ANY>
  <!ATTLIST DigestAlg
           Algorithm     CDATA   #REQUIRED >
     <!-- Where CDATA conforms to the 
          productions specified by [URI] --> 

4.3.5 Digest Value

  <!ELEMENT DigestValue CDATA>
  <!-- base64 encoded digest value -->

Note that encoding is fixed here, as base64, which is inconsistent with
SignatureValue above.

There is no technical reason to keep the digest algorithm separate from the
value, but we might choose to do so for consistency with Signature and the
handling of paramters.  Again, the proposal to expand Alg and replace the
"Algorithm" attribute with a "name" attribute applies.

If we really want consistency, we might consider the use of generic
Algorithm, Parameter, and Value elements that are interpreted in context:

<Signature>
  <SignedInfo>
    <Algorithm name="..."/>		<-- signature algorithm
    <Digest>
      <Algorithm name="..."/>		<-- digest algorithm
      <Value>xxx</Value>		<-- digest value
    </Digest>
  </SignedInfo>
  <Value>xxx</Value>			<-- signature value
</Signature>

But I'm not sure this is really a step forward.

-Greg
Received on Friday, 8 October 1999 16:27:26 GMT

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