RE: latest edits

The number of suggested changes here is getting unwieldy, it is hard to keep
track... to summarize, may I suggest the following changes from this
discussion:

1. change SignatureAlg to SignatureAlgorithm
2. change DigestAlg to DigestAlgorithm
3. change CanonicalizationAlg to Canonicalization (but see 8. below)
4. change the Algorithm attribute in all cases to Name
5. remove the CanonicalizationAlg element for the SignedInfo, instead fixing
the canonicalization algorithm to be at least DOM canonicalization
6. fix the encoding of the SignatureValue element to be base64 (for
consistency with DigestValue)

I would add the following to this list

7. allow content in the transformation elements (the transformations will
need parameters)

I suggest that we DO NOT make the following changes:

A) combine DigestAlgorithm and DigestValue (it would be inconsistent)
B) use generic Algorithm and Value elements

Also, I seem to recall some discussion about whether to have specific or
generic transformation elements (ie. just have a Transformation element
instead of Encoding, Canonicalization, Stylesheet, etc)... we seem to be
doing both (we have Generic, Canonicalization, Stylesheet, etc).  I don't
recall the resolution to the original discussion.  I'd prefer a single
Transformation element; I don't see that having different element names adds
value.  Do we add a new element if a new type of transformation comes up?
I'm envisioning something like

<Transformations>
   <Transformation name="http://...base64-decode"/>
   <Transformation name="http://...xslt">
      <Parameter
type="http://...resource">http://some-xslt-resource</Parameter>
   </Transformation>
   <Transformation name="http://...minimal-canonicalization"/>
</Transformations>

I'll add this as

8.  change transformations to use a generic Transformation element

An added advantage of this (combined with fixing SignedInfo
canonicalization) is that we no longer have to spell Canonicalization in any
of the element names.

-Mark Bartel
JetForm

-----Original Message-----
From: Greg Whitehead
To: 'w3c-ietf-xmldsig@w3.org'
Sent: 10/8/99 4:26 PM
Subject: RE: latest edits 

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 17:57:41 UTC