- From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
- Date: Tue, 12 Oct 1999 09:24:21 -0400
- To: "'w3c-ietf-xmldsig@w3.org'" <w3c-ietf-xmldsig@w3.org>
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