Re: latest edits

Hi,

From:  Mark Bartel <mbartel@thistle.ca>
Resent-Date:  Fri, 8 Oct 1999 18:38:36 -0400 (EDT)
Resent-Message-Id:  <199910082238.SAA09507@www19.w3.org>
Message-ID:  <91F20911A6C0D2118DF80040056D77A20329F7@arren.cpu1634.adsl.bellglobal.co
m>
To:  "'w3c-ietf-xmldsig@w3.org'" <w3c-ietf-xmldsig@w3.org>
Date:  Fri, 8 Oct 1999 18:38:20 -0400 

>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*).

I'm not sure we need a syntax for algorithm parameters.  And if we do,
this seems awfully bulky.  I mean, if an algorithm takes one integer
parameter, I'd kind of prefer A below.  I can see B.  But C seems like
overkill to me.

A.		1
B.		<Integer>1</Integer>
C.		<Parameter type="http://dsig.reg.int/integer">1</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 think the above are all OK though I have twinges of doubt about #6.
I don't think it's the same as 5 where we control the syntax and
processing.  We don't control what signature and digest algorithms
people may come up with and there may be some case where its much
easier/more-natural to encode some other way.  This argument is a bit
weak, however, since you could always do it with base64...

>I would add the following to this list
>
>7. allow content in the transformation elements (the transformations
>will
>need parameters)

Yes.

>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

I like that.

>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

Thanks,
Donald

>-----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 Tuesday, 12 October 1999 09:24:25 UTC