umm, not FPWD, rather updated WD ...
Also, the 2.0 requirements document is here:
http://www.w3.org/TR/2010/WD-xmlsec-reqs2-20100204/
The latest publications status of all 1.1 and 2.0 XML Security
documents is at http://www.w3.org/2008/xmlsec/wiki/PublicationStatus
regards, Frederick
Frederick Hirsch
Nokia
On Apr 7, 2010, at 9:19 AM, Hirsch Frederick (Nokia-CIC/Boston) wrote:
Thanks Andreas
Yes it seems counter-intuitive not to canonicalize XML, but it is
really only needed once the XML has been parsed, and avoiding
canonicalization saves resources.
Are you aware of the XML Security WG and the recent FPWD of Canonical
XML 2.0 [1] and XML Signature 2.0 [2]? These are intended to improve
simplicity, usability, streamability, reduced attack surface etc. Your
comments would be very welcome!
regards, Frederick
Frederick Hirsch
Nokia
[1] http://www.w3.org/TR/2010/WD-xml-c14n2-20100304/
[2] http://www.w3.org/TR/2010/WD-xmldsig-core2-20100304/
On Apr 7, 2010, at 9:00 AM, ext [email protected] wrote:
Hi Frederik, hi Thomas !
I don't want to critisize the decisions taken by your group. To keep
implementations and testing easy is a good reason !
But from my outside view it's a bit suprising : Seeing that XMLDSig
is used let's me expect a complex solution. So it would be good to
read at the introduction level that the use of XMLDSig is limited
to a small subset and doesn't necessarily implies a huge
infrastructure.
Another aspect of XMLDSig's complexity is the way people used work
with it. For example I would add a canonicalization step to each
external XML document without thinking about it ... So I would
mandate an explicit note in the spec and maybe a special error
definition in case a canonicalization is used or other widget
specific constraints are violated.
Greetings
Andreas
----- original Nachricht --------
Betreff: Re: Widget Signature modification proposal (revised)
Gesendet: Mi, 07. Apr 2010
Von: Frederick Hirsch<[email protected]>
Andreas
The intent of the proposed change is to remove ambiguity and thus
enable interop - not to make it more complicated.
I think having a clear profile with fewer choices should make it
simpler for implementation.
This may be on the agenda for the call this Thursday.
regards, Frederick
Frederick Hirsch
Nokia
On Apr 7, 2010, at 6:04 AM, ext Thomas Roessler wrote:
[email protected] wrote:
from the implementors perspective these modifications don't
introduce too much trouble. But I'm a little bit concerned about
the explicit ban of canonicalizations for 'external' documents
like
config.xml.
It is, in the first place, the default behavior of the XML
Signature
Reference Processing Model for external documents.
You're right that there's a possible design choice here to *permit*
(not
mandate) canonicalization regardless. It sounds like you suggest
that
the WG make that choice, by not prohibiting use of C14N for XML
content,
but simply leaving it open?
--- original Nachricht Ende ----
