W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

Re: Signature Portabilit, CanonicalizationMethod, etc.

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Wed, 13 Jun 2001 17:48:23 -0400
Message-Id: <4.3.2.7.2.20010613171050.02a18ef0@localhost>
To: "Donald E. Eastlake 3rd" <lde008@dma.isg.mot.com>
Cc: w3c-ietf-xmldsig@w3.org, lde008@dma.isg.mot.com
At 16:12 6/13/2001, Donald E. Eastlake 3rd wrote:
>My words above were not a proposal but an opinion. However, to provide
>a specific proposal, I have produced some HTML which I will post
>separately. I don't see why what could be considered just an important
>tweak to canonicalization can't just be added to the signature spec as
>a response to Last Call comments.

I'm not understanding. You can't tweak the meaning of one specification from 
another. We can't say [1] "http://www.w3.org/TR/2001/REC-xml-c14n-20010315" 
now means something different. [1] means what it means, how would people 
looking at that spec know that other specs somehow changed it's meaning?

We can create a new URI and spec such as [2] 
"http://www.w3.org/TR/2001/REC-xml-exc-c14n-20010723", but if it's a 
mandatory requirement, we'll have to let it precede xmldsig, and that'll 
hold us up.

We can create a new URI under the xmldsig namespace such as 
xmlns="http://www.w3.org/2000/09/xmldsig#excC14N" . It's kind of editorially 
awkward to profile Canonical XML in this way, but it makes sense at least. 
My original concern is that this would necessiate a new namespace. But since 
this addition doesn't break any existing instances or processes, I think we 
can deal with it just by recycling at Candidate REC, ensuring interop and 
continuing to use the same namespace.

>If you just want to trim down the verbiage, that's fine. Perhaps
>the above should have been as follows, especially with the addition
>of material in the CanonicalizationMethod section about why you
>should only use safe canonicalizations of SignedInfo:
>
>        "3. Transform operations are not provided for SignedInfo so
>         protection of it from context must be indicated by a
>         CannonicalizationMethod algorithm. ...

This still isn't an option an application has, it's saying, "If we had 
transforms over SignedInfo, then you could use Transforms. But we didn't, so 
you could use a different canonicalization." The latter statement is what is 
stated by option 2.


>Well, there may be character based canonicalizations and its
>reasonable to say that they take a UTF-8 octet string as input.

Ok, so I'll leave that bullet in. But the text has stated, "should be 
provided with the octets that represent the well-formed SignedInfo element, 
from the first character" which doesn't requries those characters to be in 
UTF-8. Are you adovcating we should move it to the octets represented by the 
UTF-8 encoding of those characters even if the XML document is encoded 
differently?

[I also continue to not like character base c14n, but we still need to be 
clear.]

>OK, sounds like a good idea.
>
> >3. (Editorial: Not sure adding "Although technically outside" to the
> >(previously) last paragraph adds anything but verbosity. We can lowercase
> >the RECOMMEND if you want.)
>
>I don't really care... I suppose it should be lower case.

Ok.


--
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
Received on Wednesday, 13 June 2001 17:48:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:05 UTC