RE: latest edits

I missed one:

9. Change the parameter structure for algorithms and transformations to be
in the form

<DigestAlgorithm name="..">
   <Parameter type="...">[parameter content]</Parameter>
</DigestAlgorithm>

AFAIK the parameter structure is not defined anywhere except by the HMAC
example.  I suggest that we define it somewhere, presumably under the
appropriate algorithm elements (change their content from ANY to
Parameter*).

-Mark Bartel
JetForm

-----Original Message-----
From: Mark Bartel
To: 'w3c-ietf-xmldsig@w3.org'
Sent: 10/8/99 5:57 PM
Subject: 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 18:38:31 UTC