IRC log of xmlsec on 2008-10-21

Timestamps are in UTC.

06:36:37 [RRSAgent]
RRSAgent has joined #xmlsec
06:36:37 [RRSAgent]
logging to http://www.w3.org/2008/10/21-xmlsec-irc
06:36:39 [trackbot]
RRSAgent, make logs member
06:36:39 [Zakim]
Zakim has joined #xmlsec
06:36:41 [trackbot]
Zakim, this will be XMLSEC
06:36:41 [Zakim]
ok, trackbot; I see T&S_XMLSEC()2:30AM scheduled to start 6 minutes ago
06:36:42 [trackbot]
Meeting: XML Security Working Group Teleconference
06:36:42 [trackbot]
Date: 21 October 2008
06:37:03 [fhirsch3]
Chair: Frederick Hirsch
06:37:20 [fhirsch3]
Regrets: John Wray, Juan Carlos Cruellas
06:37:43 [pdatta]
pdatta has joined #xmlsec
06:37:55 [fhirsch3]
Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0039.html
06:38:08 [fhirsch3]
zakim, call executive_6
06:38:08 [Zakim]
ok, fhirsch3; the call is being made
06:38:09 [Zakim]
T&S_XMLSEC()2:30AM has now started
06:38:11 [Zakim]
+Executive_6
06:38:11 [csolc]
csolc has joined #xmlsec
06:38:21 [fhirsch3]
zakim, who is here?
06:38:21 [Zakim]
On the phone I see Executive_6
06:38:23 [Zakim]
On IRC I see csolc, pdatta, Zakim, RRSAgent, fhirsch3, klanz2, trackbot
06:38:31 [pdatta]
pdatta has joined #xmlsec
06:38:44 [brich]
brich has joined #xmlsec
06:39:25 [brich]
ScribeNick: brich
06:44:24 [pdatta]
pdatta has joined #xmlsec
06:45:09 [Zakim]
+??P1
06:45:11 [klanz2]
zakim, ? is klanz2
06:45:11 [Zakim]
+klanz2; got it
06:50:00 [youenn]
youenn has joined #xmlsec
06:50:07 [youenn]
youenn has left #xmlsec
06:51:56 [brich]
TOPIC: Agenda discussion
06:52:39 [brich]
Possibly go through Pratik's proposal for XPath subsetting
06:53:36 [bal]
bal has joined #xmlsec
06:55:16 [brich]
Proposal was from Sept 1
06:56:43 [fhirsch3]
http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0000.html
06:57:16 [fhirsch3]
exi - serialize documents or fragments, multiroot docs
07:01:08 [pdatta]
pdatta has joined #xmlsec
07:03:53 [klanz2]
q+
07:08:07 [brich]
Schema validation, namespace undeclaration, etc
07:09:18 [rdmiller]
rdmiller has joined #xmlsec
07:10:51 [brich]
Also need to discuss c14n...whitespace handling, intermediate indention, b64-encoded certs, detection and removal of "insignificant information"
07:16:03 [brich]
Might help to consolidate what we consider to be insignificant information, those things that applications should NOT depend on being retained
07:20:43 [brich]
c14n being a terminal transform, rather than having to go back and forth between nodesets and octet streams, seems like a crucial simplification
07:22:23 [brich]
konrad...is there a heuristic for determining qnames in context vs other uses?
07:23:12 [klanz2]
can we ask users that what looks like a QName, but isn't one it will ahev to be escaped
07:23:26 [klanz2]
s/ahev/have/
07:24:10 [klanz2]
q+
07:30:59 [tlr]
tlr has joined #xmlsec
07:32:50 [brich]
Discussion around c14n output being able to be used as a standard form to be passed around...eliminating this allows more things to be considered "insignificant information" and can be left out
07:33:13 [klanz2]
What is the complement of the InfoSet, what can be thrown away ...
07:34:11 [brich]
TOPIC: XProc and XML discussion with Norm Walsh
07:36:42 [brich]
Subtopic: C14N requirements
07:37:48 [brich]
What pieces are not to be considered significant, that applications cannot depend on being retained?
07:38:23 [brich]
Norm...what's significant is what in its infoset
07:38:46 [brich]
Norm...element content whitespace is insignificant
07:39:22 [brich]
Norm...almost everything else is significant
07:40:24 [brich]
Norm...schema does not really address this well, only in DTD
07:41:05 [brich]
Norm...w/o schema or DTD, all whitespace should be assumed to be significant
07:41:08 [klanz2]
q+
07:42:40 [rigo]
rigo has joined #xmlsec
07:43:18 [pdatta]
pdatta has joined #xmlsec
07:43:28 [brich]
norm...cdata sections do not turn up in the infoset
07:44:01 [fhirsch]
fhirsch has joined #xmlsec
07:44:52 [klanz2]
That is what I tired in Transformation Primitives
07:44:57 [fhirsch]
zakim, who is here?
07:44:57 [Zakim]
On the phone I see Executive_6, klanz2
07:44:59 [Zakim]
On IRC I see fhirsch, pdatta, rigo, tlr, rdmiller, bal, brich, csolc, Zakim, RRSAgent, klanz2, trackbot
07:45:29 [klanz2]
q+
07:49:07 [brich]
we have more protection with digital signature than paper signature today, as we have content protection...seems like whitespace preservation is beyond what is required
07:49:36 [tlr]
q+
07:50:22 [fhirsch]
q+
07:50:29 [fhirsch]
ack klanz
07:51:01 [brich]
konrad...if want whitespace preservation, could allow option
07:51:02 [fhirsch]
ack tlr
07:51:20 [fhirsch]
if we wish to simplify then we need to simplify
07:51:41 [brich]
csolc...how does application know whether whitespace is significant, to be able to request it or not?
07:51:43 [fhirsch]
both tlr and csolc asked how does app know whether space is signficant to set option
07:52:20 [fhirsch]
prefer to avoid options and complexit
07:53:41 [Norm]
Norm has joined #xmlsec
07:53:58 [klanz2]
http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0000.html:
07:53:58 [klanz2]
if one would apply those to the referenced document itself (by
07:53:58 [klanz2]
actually changing it) then the processing of the transforms, despite
07:53:58 [klanz2]
some serialization, could be omitted on verification as those transforms
07:53:58 [klanz2]
are idempotent.
07:53:59 [klanz2]
In case it fails, the transformations may be executed again assuming an
07:54:01 [klanz2]
allowed change has happened. If it fails again it fails overall.
07:54:03 [klanz2]
We should hence further revise the paradigm of not changing the
07:54:05 [klanz2]
dereferenced/parsed document.
07:54:06 [brich]
norm...<p><span>do</span><span>not</span></p>
07:54:20 [klanz2]
q+
07:54:36 [Norm]
Critically, in the original document, there's a newline between the two spans
07:55:04 [Norm]
q+ to ask about pipelines
07:55:18 [brich]
frederick...need to drive to simplification
07:55:53 [kyiu]
kyiu has joined #xmlsec
07:57:59 [brich]
bal...whitespace insignificance is only possible via DTD, and that is legacy...no longer to be used
07:59:21 [klanz2]
q+
07:59:35 [Norm]
q-
08:00:06 [fhirsch]
ack fhirsch
08:00:18 [fhirsch]
ack klanz
08:01:19 [brich]
bal..."sign what is seen" is at end of dsig doc, was not primary focus, should not overemphasize
08:02:11 [klanz2]
But it should be chewed away befor the document is signed ,,,
08:02:21 [klanz2]
s/befor/before/
08:03:12 [klanz2]
So there is obviously enough potential if Information in XML is secure ....
08:04:33 [brich]
Subtopic: Pratik's presentation
08:04:47 [klanz2]
s/potential/potential to discuss/
08:05:01 [brich]
http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0000.html
08:07:36 [klanz2]
@bal: Point 1) in Pratik's presentation is to some extend equivalent to sections 8.1.1 to 8.1.3
08:08:07 [klanz2]
q+
08:08:50 [brich]
pdatta...Building dsig on XPath 1.0 data model leads to lots of work to deal with namespace inheritance when nodes are omitted
08:08:51 [fhirsch3]
fhirsch3 has joined #xmlsec
08:10:02 [brich]
norm...xpath2 may help, not required to support namespace nodes and a namespace axis
08:10:27 [klanz2]
http://www.w3.org/TR/xpath20/:
08:10:27 [klanz2]
In [XPath 1.0], the in-scope namespaces of an element node are represented by a collection of namespace nodes arranged on a namespace axis. In XPath Version 2.0, the namespace axis is deprecated and need not be supported by a host language. A host language that does not support the namespace axis need not represent namespace bindings in the form of nodes.
08:10:48 [brich]
pdatta...subtrees most important to support, and perhaps included/excluded subtrees
08:11:40 [brich]
pdatta...Enveloped signatures require the exclusion of the signature subtree itself
08:12:17 [brich]
norm...will help find "Schema Key Constraints"
08:13:41 [brich]
tlr...put this in "Proposed Breaking Changes" in requirements doc
08:14:20 [brich]
pdatta...going to Streaming signatures...
08:15:44 [brich]
norm...streaming XSLT...need email reminder
08:16:33 [klanz2]
q+
08:16:43 [tlr]
Summary: namespace prefix undeclarations will continue to haunt us forever.
08:16:52 [fhirsch3]
ack klanz
08:17:17 [brich]
norm...namespace prefix undeclaration is NOT in xml 1.0 but is in 1.1...this will NOT change
08:17:51 [Norm]
Konrad observes that the XPath 2.0 data model can't be serialized as XML 1.0.
08:18:36 [brich]
tlr...would like to change gears...XSLT serialization...what is the domain? what nodesets does it operate on?
08:18:38 [klanz2]
s/XPath 2.0/XPath 1.0/
08:19:31 [brich]
norm...will serialize any XDM subtree...doesn't throw anything away(?), may add things (indentation)
08:19:46 [brich]
tlr...why not c14n?
08:19:57 [brich]
norm...not on radar
08:21:44 [fhirsch3]
xproc may use c14n as serialization for serialization method
08:22:15 [brich]
norm...XProc pipeline would output nodeset...would not make sense to have c14n...as that would output octet stream
08:25:18 [klanz2]
All this XML == XML' ? Is allover the place in XML and causes so many headaches ... http://www.w3.org/TR/xslt#strip
08:25:19 [klanz2]
q+
08:25:34 [klanz2]
and many more places and so on ...
08:25:52 [brich]
frederick...these two requirements are linked...looks like must do both
08:25:58 [fhirsch3]
removing the requirement to allow transforms to move from octet stream to nodeset and back as well as enabling c14n only has pre-hash signing step could greatly improve performance, simplification
08:26:13 [fhirsch3]
can not do both!
08:27:02 [fhirsch3]
q+
08:27:11 [fhirsch3]
ack klanz
08:28:49 [tlr]
Konrad is unfortunately right about XSLT
08:28:51 [tlr]
http://www.w3.org/TR/xmldsig-core/#sec-XSLT
08:30:01 [tlr]
ISSUE: Revise XSLT transform; it's currently octet-stream to node-set.
08:30:02 [trackbot]
Created ISSUE-67 - Revise XSLT transform; it's currently octet-stream to node-set. ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/67/edit .
08:30:31 [brich]
frederick...not arguing against "sign-what-you-see" but did we make this more complicated than what was needed?
08:31:07 [brich]
bal...whole reason for xform chains was for document subsets
08:31:16 [klanz2]
Document subsets is XPointer
08:31:55 [klanz2]
q+
08:32:06 [brich]
frederick...do we really need the transform chain mechanism?
08:32:21 [klanz2]
Imagine Database A and Database B ....
08:32:36 [brich]
bal...do you need to have subselection of URI-addressable parts?
08:32:50 [klanz2]
and you send a detached signature from A to B ...
08:33:32 [klanz2]
and the transforms dereference data from those data bases and the signature shall verify without actually transferring the data#
08:34:08 [klanz2]
so would could make this a NON use case
08:34:49 [klanz2]
but currently these things are used ...
08:36:00 [brich]
tlr...XSLT transform requirement will constrain us...unless dealt with somehow
08:37:06 [brich]
Subtopic: XProc futures
08:37:30 [brich]
norm...going to CR the end of this week
08:37:51 [brich]
norm...may get uptake early next year
08:38:40 [brich]
norm...if case that dsig is atomic operation with few options, could argue that is part of XProc
08:39:23 [brich]
norm...seems more complicated, would be compound steps, more than can be added to XProc
08:40:23 [klanz2]
q+
08:40:38 [brich]
rdmiller...some work has already gone into this dsig+Xproc step/steps, will share later
08:41:18 [klanz2]
is an XProc chain delivering the same output if executed on different processers ...
08:41:52 [klanz2]
I mean if you stuck it into a digest will it deliver the same digest
08:42:46 [klanz2]
q+
08:43:36 [fhirsch3]
ack fhirsch
08:43:42 [fhirsch3]
ack klanz
08:43:45 [klanz2]
maybe that is an interesting idea and then all other specs would have to assure that their output is canonical to some extend ..
08:46:46 [brich]
konrad...if security is of concern to authors of XML apps, should have canonical form
08:47:13 [brich]
tlr...most specs tell how to parse, not how to serialize, canonicalize
08:48:57 [klanz2]
Security is inconvenient and costly, but is necessary to assure long term survival of any technology ...
08:49:48 [brich]
frederick...what is going on with encryption?
08:50:05 [brich]
norm...deferred until later, just as signature
08:51:35 [klanz2]
q+
08:55:31 [klanz2]
q-
08:55:44 [amy]
amy has joined #xmlsec
08:55:58 [thomas]
frederick?
08:56:06 [thomas]
let's meet in the Webapps room
08:56:10 [thomas]
they have more room
09:01:45 [ArtB]
ArtB has joined #xmlsec
09:02:03 [amy]
amy has left #xmlsec
09:02:11 [ArtB]
Frederick - Thomas says you folks should join us @ 11:00 in Isle A
09:02:12 [ArtB]
OK?
09:02:35 [ArtB]
Isle A is behind the registration desk on floor 0
09:02:45 [ArtB]
Please ACK
09:05:27 [Zakim]
-Executive_6
09:11:22 [brich]
brich has joined #xmlsec
09:11:41 [bal]
bal has joined #xmlsec
09:12:32 [csolc]
csolc has joined #xmlsec
09:12:44 [brich]
zakim, call iles_a
09:12:44 [Zakim]
ok, brich; the call is being made
09:12:46 [Zakim]
-klanz2
09:12:46 [Zakim]
+klanz2
09:12:46 [Zakim]
+Iles_a
09:13:23 [fhirsch3]
fhirsch3 has joined #xmlsec
09:13:49 [fhirsch3]
zakim, who is here?
09:13:49 [Zakim]
On the phone I see klanz2, Iles_a
09:13:50 [Zakim]
On IRC I see fhirsch3, csolc, bal, brich, ArtB, kyiu, rdmiller, Zakim, RRSAgent, klanz2, trackbot
09:14:41 [brich]
ScribeNick: brich
09:15:00 [brich]
TOPIC: WebApps meeting
09:17:42 [tlr]
tlr has joined #xmlsec
09:18:36 [brich]
http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0077.html
09:19:12 [brich]
WebApps: SHA-256 issues?
09:20:06 [fhirsch3]
bal: deprecate sha-1 for signing, continue verification, support SHA-256
09:22:43 [brich]
WebApps: how to deal with knowing which alg to use?
09:23:16 [brich]
WebApps: Signature alg?
09:26:00 [fhirsch3]
see wam minutes here
09:27:05 [fhirsch3]
bal: 1024 key length good for a year...
09:32:03 [fhirsch3]
if cert is long lived for code signing, e.g 3 year verisign cert, could drive desire to use long lived signing key at 1024...
09:32:14 [fhirsch3]
s/if/kelvin, if
09:33:49 [fhirsch3]
wam minutes - http://www.w3.org/2008/10/21-wam-minutes.html
09:37:44 [klanz2]
q+
09:39:18 [klanz2]
q-
09:40:59 [brich]
bal...said XAdES would have helpful info, some might be picked up in Signature futures
09:41:17 [bal]
he asked about timestamps and I pointed to xades
09:41:31 [brich]
link to XAdES already in WAM channel
09:42:15 [klanz2]
re timestamps also poit to best practices for ephemeral signatures and timestamps, i.e. the contributon from Hal about webservices and timestamps
09:44:52 [tlr]
We expect to do the algorithm changes, minor clean-ups, low-hanging simplifications in XML Signature 1.1. No change of namespace. No clear time plan quite yet.
09:59:33 [fhirsch3]
tlr: identify spec in signature as signature property, so to identify profile
10:26:41 [fhirsch3]
zakim, who is here?
10:26:41 [Zakim]
On the phone I see klanz2, Iles_a
10:26:42 [Zakim]
On IRC I see tlr, bal, brich, ArtB, Zakim, RRSAgent, klanz2, trackbot
10:27:21 [fhirsch3]
fhirsch3 has joined #xmlsec
10:27:28 [fhirsch3]
zakim, who is here?
10:27:28 [Zakim]
On the phone I see klanz2, Iles_a
10:27:29 [Zakim]
On IRC I see fhirsch3, tlr, bal, brich, ArtB, Zakim, RRSAgent, klanz2, trackbot
10:32:48 [klanz2]
yes
10:33:05 [klanz2]
I can howevr hardly hear anything
10:36:05 [klanz2]
q+
10:36:09 [klanz2]
q-
10:37:41 [klanz2]
do we have a requirement to clarify dereferencing from within a ZIP file, it seems ODF and Widgets need this?
10:38:22 [Zakim]
-klanz2
10:38:23 [Zakim]
-Iles_a
10:38:25 [Zakim]
T&S_XMLSEC()2:30AM has ended
10:38:26 [Zakim]
Attendees were Executive_6, klanz2, Iles_a
10:40:12 [klanz2]
things that may play a role here are: http://tools.ietf.org/html/rfc3986#section-5.1.2
10:40:12 [klanz2]
Java has soemthing in the format jar:<url>!/[<entry>]
10:40:14 [klanz2]
http://java.sun.com/j2se/1.5.0/docs/api/java/net/JarURLConnection.html
11:01:46 [Zakim]
T&S_XMLSEC()2:30AM has now started
11:01:53 [Zakim]
+Ed_Simon
11:24:14 [Zakim]
-Ed_Simon
11:24:16 [Zakim]
T&S_XMLSEC()2:30AM has ended
11:24:16 [Zakim]
Attendees were Ed_Simon
11:24:33 [Zakim]
T&S_XMLSEC()2:30AM has now started
11:24:40 [Zakim]
+Ed_Simon
11:27:20 [esimon2]
esimon2 has joined #xmlsec
11:27:55 [esimon2]
Hi Konrad, where is everyone?
11:35:24 [Zakim]
-Ed_Simon
11:35:26 [Zakim]
T&S_XMLSEC()2:30AM has ended
11:35:26 [Zakim]
Attendees were Ed_Simon
11:51:50 [fhirsch3]
fhirsch3 has joined #xmlsec
11:52:13 [pdatta]
pdatta has joined #xmlsec
11:52:21 [fhirsch3]
zakim, call executive_6
11:52:21 [Zakim]
ok, fhirsch3; the call is being made
11:52:22 [Zakim]
T&S_XMLSEC()2:30AM has now started
11:52:23 [Zakim]
+Executive_6
11:52:36 [kyiu]
kyiu has joined #xmlsec
11:52:49 [fhirsch3]
zakim, who is here?
11:52:49 [Zakim]
On the phone I see Executive_6
11:52:51 [Zakim]
On IRC I see kyiu, pdatta, fhirsch3, esimon2, Zakim, RRSAgent, klanz2, trackbot
11:53:15 [kyiu]
ScribeNick: kyiu
11:54:03 [kyiu]
zakim, who is here?
11:54:03 [Zakim]
On the phone I see Executive_6
11:54:04 [Zakim]
On IRC I see kyiu, fhirsch3, esimon2, Zakim, RRSAgent, klanz2, trackbot
11:54:05 [fhirsch3]
zakim, who is here?
11:54:05 [Zakim]
On the phone I see Executive_6
11:54:08 [Zakim]
On IRC I see kyiu, fhirsch3, esimon2, Zakim, RRSAgent, klanz2, trackbot
11:55:27 [csolc]
csolc has joined #xmlsec
11:55:46 [pdatta]
pdatta has joined #xmlsec
11:56:54 [kyiu]
TOPIC: NVDL Introduction
11:57:05 [pdatta]
pdatta has joined #xmlsec
11:57:45 [Zakim]
+??P4
11:57:47 [Zakim]
-??P4
11:57:47 [Zakim]
+??P4
11:57:51 [pdatta]
pdatta has joined #xmlsec
11:57:56 [klanz2]
zakim, ? is klanz2
11:57:56 [Zakim]
+klanz2; got it
11:58:27 [klanz2]
do we have a link to NVDL
11:58:54 [kyiu]
it's getting uploaded
12:01:01 [bal]
bal has joined #xmlsec
12:01:08 [kyiu]
RobMiller: how to move XML in an assured way - has paper that shows how to constrain schema
12:01:10 [klanz2]
what slide are we on
12:01:35 [kyiu]
I think 2
12:01:41 [klanz2]
What is NVDL
12:02:48 [kyiu]
NVDL=Namespaces-based Validation Dispatching Language
12:03:13 [klanz2]
I know, but is that the heading of the slide you have been seeing
12:03:20 [klanz2]
yes
12:06:02 [kyiu]
zakim, who is there?
12:06:02 [Zakim]
I don't understand your question, kyiu.
12:06:11 [kyiu]
zakim, who is here?
12:06:11 [Zakim]
On the phone I see Executive_6, klanz2
12:06:12 [Zakim]
On IRC I see bal, pdatta, csolc, kyiu, esimon2, Zakim, RRSAgent, klanz2, trackbot
12:09:02 [klanz2]
q+, what PSVI is added when multiple schmas is validated against?
12:09:52 [kyiu]
fhirsch3: how do you identify a component? how do you express constraints?
12:10:45 [bal]
ack klanz2
12:11:43 [brich]
brich has joined #xmlsec
12:16:26 [kyiu]
fhirsch3: can possibly put NVDL on our best practices list
12:21:55 [klanz2]
q+
12:22:38 [csolc]
ack klanz2
12:23:50 [fhirsch3]
fhirsch3 has joined #xmlsec
12:24:24 [klanz2]
Very Good Point
12:25:23 [klanz2]
rob: NVDL can be used to mitigate many things on a schema validation level already
12:26:01 [fhirsch3]
slides for NVDL http://www.w3.org/2008/xmlsec/f2f-2008-10-20/NVDL-plus-XML-Signature.ppt
12:26:14 [klanz2]
there is a potential to tackle certain things in our best practices using NVDL ...
12:26:58 [fhirsch3]
NVDL pdf http://www.w3.org/2008/xmlsec/f2f-2008-10-20/NVDL-plus-XML-Signature.pdf
12:30:20 [klanz2]
e.g.: Limit http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/#id114072 -> give an NVDL example of how to prevent this ...
12:30:24 [kyiu]
TOPIC: Transform Requirements
12:30:25 [klanz2]
q+
12:30:43 [kyiu]
ack klanz2
12:30:47 [fhirsch3]
ack klanz
12:31:12 [klanz2]
http://tools.ietf.org/html/rfc3986#section-5.1.2
12:31:34 [kyiu]
TOPIC: WebApps followup
12:31:46 [bal]
pwd
12:32:09 [tlr]
tlr has joined #xmlsec
12:32:20 [fhirsch3]
5.1.2 RFC 3986 ODF uses zip files and XML dsig inside zip files
12:32:36 [fhirsch3]
s/5/konrad, 5
12:33:12 [bal]
s/pwd//
12:34:45 [kyiu]
klanz2: add test cases for zip based packaging formats?
12:35:53 [kyiu]
tlr: xmldsig already allows relative paths in uris. not xmldsig's responsibility
12:35:57 [fhirsch3]
group noted that other groups may have to test Reference uri retrieval, really out of scope for signature
12:36:41 [kyiu]
TOPIC: Transform Requirements
12:36:42 [rdmiller]
rdmiller has joined #xmlsec
12:37:05 [fhirsch3]
http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/att-0036/00-part
12:38:43 [kyiu]
pdatta: very difficult to find out what is signed. Model is run transform, get digest
12:39:28 [kyiu]
pdatta: seems verifying processor doesn't know what is going on. in practice, we restricts what transform sequences are allowed
12:39:41 [kyiu]
pdatta: should step back and try to do things in a different way
12:40:13 [kyiu]
pdatta: how to identify what is signed - not responsibility of a transformation
12:41:23 [kyiu]
csolc: may want to canonicalize binary formats
12:41:56 [fhirsch3]
separate what is signed, selection, and digesting/canonicalization
12:42:08 [kyiu]
csolc: 2 steps: selection and canonicalization
12:43:31 [kyiu]
pdatta: klanz2 brought up using xslt to remove whitespaces, but it should be done within canonicalization
12:44:17 [kyiu]
kyiu has joined #xmlsec
12:44:52 [klanz2]
q+
12:47:26 [kyiu]
klanz2: new use case for transforms: generate xhtml on the fly and signed
12:54:42 [kyiu]
fhirsch3: seems like you can simplify signature greatly if data is first retrieved from database, run through xslt, then signed, instead of running the xslt as part of xmldsig
12:58:21 [kyiu]
bal: you would have to generate a uri for the results from the database query
12:59:10 [klanz2]
q+
12:59:21 [kyiu]
ack klanz
13:01:01 [klanz2]
8.1 Transforms
13:01:01 [klanz2]
A requirement of this specification is to permit signatures to "apply to a part or totality of a XML document." (See [XML-Signature-RD, section 3.1.3].) The Transforms mechanism meets this requirement by permitting one to sign data derived from processing the content of the identified resource. For instance, applications that wish to sign a form, but permit users to enter limited field data withou
13:01:01 [klanz2]
t invalidating a previous signature on the form might use [XPath] to exclude those portions the user needs to change. Transforms may be arbitrarily specified and may include encoding transforms, canonicalization instructions or even XSLT transformations. Three cautions are raised with respect to this feature in the following sections.
13:01:03 [klanz2]
Note, core validation behavior does not confirm that the signed data was obtained by applying each step of the indicated transforms. (Though it does check that the digest of the resulting content matches that specified in the signature.) For example, some applications may be satisfied with verifying an XML signature over a cached copy of already transformed data. Other applications might require
13:01:08 [kyiu]
csolc: seems transforms for document manipulation should not be part of dsig
13:01:08 [klanz2]
that content be freshly dereferenced and transformed.
13:01:22 [klanz2]
*to sign data derived from processing the content of the identified resource*
13:03:17 [kyiu]
bal: thinks we had requirement from we wanted to sign parts of a document. xpath was a means of selection, xslt is selecting and transforming
13:03:37 [klanz2]
q+
13:03:58 [kyiu]
fhirsch3: what would we lose if we keep only selection, but not transform?
13:05:47 [kyiu]
tlr: 2 possible assertions: if we take msg, apply transform, then you are assured the information is result. you don't get the assurance if you don't apply it.
13:07:01 [kyiu]
fhirsch3: push back on putting all information about a workflow into xmldsig
13:08:00 [klanz2]
q+
13:09:22 [klanz2]
q-
13:10:36 [klanz2]
q+
13:10:38 [kyiu]
bal: looking back on v1 requirements, we may have just over defined transforms when reqs were mostly inclusions and exclusions
13:14:14 [klanz2]
XPointer is still a WD ...
13:20:07 [kyiu]
tlr was arguing to keep selection
13:21:48 [klanz2]
q+
13:21:50 [bal]
(discussion of what auditors do when they audit)
13:22:32 [kyiu]
where info is stored (inside or outside of the signature) should not affect the auditor
13:23:35 [klanz2]
What about this: http://www.w3.org/TR/xmldsig-core/#sec-Base-64
13:23:54 [klanz2]
That is a clear indication that what is to be secured is the derived and not the data as such
13:24:46 [klanz2]
but the empty transform chain degenerates to the situation where there is identity between what is dereferenced data and digested data
13:24:52 [Zakim]
+ +1.781.993.aaaa
13:25:11 [tlr]
zakim, aaaa is hlockhart
13:25:11 [Zakim]
+hlockhart; got it
13:25:53 [kyiu]
fhirsch3: it may be difficult for an app to define a transform if the API doesn't support it or complex
13:26:50 [klanz2]
similar thoughts could be applied if only transfrom primitives were used ...
13:27:41 [kyiu]
fhirsch3: xproc is about defining processing chain and would like to see a simple processing step for signing
13:28:00 [klanz2]
q+
13:28:28 [kyiu]
fhirsch3: trying to get things simpler, not sure if we can meet our security and perf objectives without simplification
13:29:01 [kyiu]
bal: then you can make canonicalization the last transform before digest
13:29:21 [klanz2]
q+
13:29:33 [fhirsch3]
ack klanz
13:30:33 [Zakim]
+Ed_Simon
13:30:57 [kyiu]
klanz2: doesn't think supporting transformation is contrary to our goals
13:31:59 [kyiu]
fhirsch3: we don't eliminate the transform step, but questioning whether it belongs within xmldsig.
13:32:59 [klanz2]
q+
13:34:26 [kyiu]
klanz2: removing transformation may not be supported by the community
13:35:24 [kyiu]
fhirsch3: convinced that we should be on a path to do a version 1.1. Would be nice to get feedback beforing going to last call
13:35:56 [kyiu]
fhirsch3: pretend we have a small part of 2.0 ready way ahead and ask for feedback
13:37:06 [kyiu]
tlr: would be very valuable if we reach out to etsi, ietf and oasis. proposal would have to be public and not member only
13:37:28 [kyiu]
tlr: brief design not may be the right way to get feedback
13:37:37 [tlr]
s/design not /design note/
13:37:49 [esimon2]
zakim, mute me
13:37:50 [Zakim]
sorry, esimon2, I do not know which phone connection belongs to you
13:39:08 [klanz2]
For 1.1 we could start with things like http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0000.html Transfromation primitives ...
13:39:17 [kyiu]
pdatta: could present in 2 ways: new syntax or retain old syntax but restrict
13:41:02 [klanz2]
Some quickly drafted examples for such transformation primitives could be:
13:41:02 [klanz2]
a) some sort of minimal canonicalization as defined in RFC 4051 [2] ...
13:41:02 [klanz2]
b) normalization of namespace prefixes, ...
13:41:02 [klanz2]
c) normalization of multiple successive whitespace characters ...
13:41:02 [klanz2]
d)sorting of attributes ...
13:41:03 [klanz2]
e) a non-XPath-Filter based version of the enveloped signature
13:41:05 [klanz2]
transform ...
13:41:07 [klanz2]
f) and the like ....
13:48:44 [Zakim]
-klanz2
14:01:10 [Zakim]
-Executive_6
14:01:55 [csolc]
zakim, call Executive_6
14:01:55 [Zakim]
ok, csolc; the call is being made
14:01:56 [Zakim]
+Executive_6
14:03:03 [bal]
bal has joined #xmlsec
14:04:10 [fhirsch3]
fhirsch3 has joined #xmlsec
14:05:39 [fhirsch3]
zakim, who is here?
14:05:39 [Zakim]
On the phone I see Executive_6, hlockhart, Ed_Simon
14:05:41 [Zakim]
On IRC I see fhirsch3, bal, kyiu, tlr, brich, pdatta, csolc, esimon2, Zakim, RRSAgent, klanz2, trackbot
14:06:19 [Zakim]
+??P4
14:06:27 [klanz2]
zakim, ? is klanz2
14:06:27 [Zakim]
+klanz2; got it
14:06:43 [fhirsch3]
http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/att-0036/00-part
14:08:22 [kyiu]
pdatta: don't want DOM because of amount of memory used, pass around a stream of nodes instead
14:09:17 [fhirsch3]
pratik , 2-3 passes max...
14:10:00 [kyiu]
brich: 1 pass is ideal
14:11:00 [kyiu]
pdatta: verification is difficult for 1 pass.
14:12:31 [kyiu]
bal: key is knowing what to hash
14:15:33 [klanz2]
q-
14:15:59 [kyiu]
pdatta: wss use case often has signature detached
14:17:13 [fhirsch3]
ack hlockhart
14:17:26 [kyiu]
pdatta: wss has signature before rest of body. possible 1 pass when verifying, but not possible to have 1 pass for signing
14:18:41 [kyiu]
hlockhart: when sending, you know content is ok, verify cannot assume that
14:20:24 [kyiu]
fhirsch3: have question about streaming - should we have another level?
14:20:37 [kyiu]
fhirsch3: trying to figure out how to act on it
14:21:17 [kyiu]
fhirsch3: should streaming be a core requirement, or optional
14:21:29 [kyiu]
bal: streaming is often the reason people choose CMS instead of XMLDSIG
14:21:51 [kyiu]
pdatta: even if you go with 2 passes, what are the problems wiht the current model?
14:22:06 [kyiu]
pdatta: nodeset itself requires a DOM, everything is loaded at the same time
14:22:28 [kyiu]
pdatta: xpath expressions can go anywhere in the document
14:23:15 [kyiu]
pdatta: could limit to only the xpath axis that allows streaming
14:24:37 [kyiu]
pdatta: filtering namespace nodes - there is a very complicated test vector and wondering if we can do without it
14:24:41 [klanz2]
Some bits of the streaming discussions in the maintenance WG back then:
14:24:41 [klanz2]
http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008May/0026.html
14:24:41 [klanz2]
http://lists.w3.org/Archives/Member/member-xmlsec-maintwg/2008Jun/0002.html
14:25:24 [kyiu]
fhirsch3: may want to run regression test cases against proposal and see how many are broken
14:26:24 [kyiu]
pdatta: perhaps we can have more than 1 digest for each reference?
14:26:43 [klanz2]
q+
14:26:50 [anil]
anil has joined #xmlsec
14:27:09 [kyiu]
klanz2: 2 digest processing should not be too expensive
14:28:19 [kyiu]
pdatta: because signature breaks too often, if we have multiple types of canonicalization, then it may be easier to make a determination
14:28:40 [kyiu]
fhirsch3: could also have an attack where it changed one canonicalization but not all
14:29:00 [kyiu]
klanz2: it could help analyze broken signatures
14:30:12 [kyiu]
klanz2: main problem is we have tools that break assumption that XML should not be touched after signing
14:31:05 [klanz2]
s/we have/there are/ ;-)
14:31:49 [fhirsch3]
konrad notes possible requirement is that the xml environment allows flexibility or even apps to break rules, signatures still need to verify
14:32:26 [kyiu]
fhirsch3: ACTION to pdatta to put proposal into requirements doc
14:33:38 [kyiu]
fhirsch3: does the WG agree to explore simplifying transform chain processing
14:33:50 [kyiu]
bal: let's make sure we agree on the roadmap
14:34:17 [kyiu]
bal: do a version 1.1, plus and early note about transform processing in 2.0
14:34:32 [klanz2]
I'd like to have this added as a requirement: the xml environment allows flexibility or even apps to break rules, signatures still need to verify
14:35:39 [kyiu]
tlr: sketch out the breaking change briefly and get feedback as early as possible
14:35:51 [kyiu]
fhirsch3: want input from entire WG
14:36:13 [klanz2]
is sean mullan here?
14:36:46 [kyiu]
bal: from the charter, WG will communicate breaking changes early and broadly
14:37:50 [kyiu]
resolution: accept pdatta stuff into requirement doc
14:39:12 [kyiu]
ACTION to klanz2 to write his database use case to add to requriements doc
14:39:12 [trackbot]
Sorry, couldn't find user - to
14:39:48 [kyiu]
fhirsch3: can we communicate that streaming is now a core requirement?
14:42:10 [kyiu]
RESOLUTION we'll add a requirement that there should be a clearly defined subset of XMLDSIG that is streamable
14:42:30 [klanz2]
q+
14:43:58 [kyiu]
fhirsch3: do v1.1 early to include algorithm updates
14:44:14 [kyiu]
sha2 and ecc
14:45:10 [kyiu]
clarify processing around handling of absent uri
14:45:46 [kyiu]
no new namespace, no breaking changes, no need to invoke version policy
14:45:59 [kyiu]
include careful update of versioning policy
14:46:02 [klanz2]
I'd like to discuss to add a set of very simple transfroms ..
14:46:02 [klanz2]
http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0000.html
14:46:13 [kyiu]
also other simple obvious clarificatinos
14:46:29 [bal]
s/clarificatinos/clarifications/
14:46:48 [kyiu]
roadmap item2: note to describe simplifcation of transform
14:47:07 [kyiu]
roadmap item3: uri index note
14:47:26 [fhirsch3]
note that smmarizes uris defined in various places, encryption, sig, rfcs etc
14:47:48 [fhirsch3]
item2 is selection and c14n+digest only transforms
14:48:34 [fhirsch3]
item1 is for signature
14:48:46 [kyiu]
item 4 update xmlenc with new ecc algs
14:49:07 [fhirsch3]
item4 probably also careful clarification of versioing
14:49:16 [fhirsch3]
s/versioing/versioning
14:49:56 [kyiu]
item 1: should point to NIST doc for key sizes
14:51:12 [kyiu]
sentiment in the room is to accept the roadmap with info we have now
14:51:38 [tlr]
RESOLUTION: roadmap accepted, subject to possible agreement by those not attending face-to-face
14:51:50 [tlr]
http://lists.w3.org/Archives/Member/member-xmlsec/2008Oct/0014.html
14:53:18 [klanz2]
Where are we on the AGENDA? http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0037.html
14:54:31 [klanz2]
you are loosing me entirely
14:55:11 [klanz2]
are we talink on 2.0 1.1 ???
14:55:35 [tlr]
2.0
14:55:36 [klanz2]
s/talink/talking/
14:55:51 [fhirsch3]
The WG is considering restricting the transform model in XML Signature 2.0 to limit the transforms to selection of material for signing and also to enable digesting and canicalization
14:56:28 [fhirsch3]
The current ability to support complicated arbitrary transform streams might be better handled at the applciation,perhaps using xproc steps.
14:57:08 [klanz2]
Well I object this because it is optional anyway ...
14:57:08 [fhirsch3]
For example, XSLT would no longer be supported as a signature transform but could still be used before signing is initiated.
14:57:17 [klanz2]
Well I object this because it is optional anyway ...
15:01:04 [bal]
my proposed wording
15:01:06 [bal]
The Working Group is considering modifying the Reference Processing Model in XMlDSIG 2.0 to consider only "selection", "canonicalization" and "digesting" transformations. The Working Group believes that there are significant security advantages to making this change to the XMLDSIG structure, but it does constitute a restriction on behavior that is currently permitted by XMLDSIG 1.0. Specifically, this change would still permit signing of document subsets but wou
15:01:06 [bal]
ld prohibit transformations of arbitrary complexity (e.g. XSLT) from being used within the XMLDSIG sturcture itself.
15:01:09 [klanz2]
q+
15:05:05 [klanz2]
http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/Index.en.html
15:05:21 [klanz2]
http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/viewerformat/ViewerFormat.en.html
15:08:03 [klanz2]
q+
15:08:37 [fhirsch3]
ack klanz
15:08:59 [bal]
The Working Group is considering modifying the Reference Processing Model in XMlDSIG 2.0 to consider only "selection", "canonicalization" and "digesting" transformations. The Working Group believes that there are significant security and performance advantages to making this change to the XMLDSIG structure, but it does constitute a restriction on behavior that is currently permitted by XMLDSIG 1.0. Specifically, this change would still permit signing of document
15:08:59 [bal]
subsets but would prohibit transformations of arbitrary complexity (e.g. unconstrained XSLT) from being used within the XMLDSIG sturcture itself.
15:10:24 [tlr]
http://lists.w3.org/Archives/Member/member-xmlsec/2008Oct/0015.html
15:11:59 [klanz2]
http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/minimum/Minimum.en.html
15:12:07 [klanz2]
Minimum Implementation of the Security Layer
15:12:45 [klanz2]
http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/minimum/Minimum.en.html#profilXMLSig.erstellung.transformationsalgorithmen
15:13:49 [tlr]
http://lists.w3.org/Archives/Member/member-xmlsec/2008Oct/0015.html
15:15:49 [esimon2]
1+ for message in chat
15:21:19 [fhirsch3]
add requirement to requireents doc for migration and legacy support
15:25:14 [esimon2]
Just fyi, I'm sporadically unavailable for the next half hour.
15:25:31 [fhirsch3]
http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0036.html
15:25:44 [Zakim]
-Ed_Simon
15:27:03 [Zakim]
+Ed_Simon
15:27:46 [kyiu]
TOPIC Web Services Requirements
15:29:13 [esimon2]
q+
15:31:21 [klanz2]
q+
15:32:52 [kyiu]
hal: we know there are naive implementations that verify signatures without ensuring if the right keys are used, or if the signature met cryptographic requirements of the organization
15:33:10 [klanz2]
q-
15:33:29 [kyiu]
fhirsch3: running out of time quickly, want to decide if we want a call next week
15:33:29 [esimon2]
q-
15:36:12 [fhirsch3]
ws security msg is about environment, not specific to xml signature requirements
15:36:51 [fhirsch3]
question of whether wss is constraint or whether it might change based on work in xml security
15:36:57 [klanz2]
q+
15:37:03 [fhirsch3]
ack klanz
15:38:57 [kyiu]
WG will review Hal's proposal and provide further comments over email
15:39:06 [tlr]
zakim, remind me in 10 minutes
15:39:06 [Zakim]
ok, tlr
15:39:14 [esimon2]
gotta go for a bit
15:39:21 [klanz2]
http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0000.html
15:39:30 [kyiu]
TOPIC Transform Primitives
15:39:37 [klanz2]
a)some sort of minimal canonicalization as defined in RFC 4051 [2] ...
15:39:37 [klanz2]
b)normalization of namespace prefixes, implying that they are not of
15:39:37 [klanz2]
significance to the data object. It does not contain QNames in
15:39:37 [klanz2]
content referred to by this ds:Reference.
15:39:37 [klanz2]
Hence this ds:Transform specifies a numbering scheme for namespace
15:39:37 [klanz2]
prefixes with some NCName [3] parameter P so that prefixes are
15:39:39 [klanz2]
replaced by concat(P,'1') ... concat(P,'n') ... and so on .
15:39:41 [klanz2]
The transformation MUST by default throw an error on the discovery
15:39:43 [klanz2]
of the string concat(P,x,':') in attribute values or out side tags,
15:39:45 [klanz2]
where x is a decimal integer ....
15:39:47 [klanz2]
c)normalization of multiple successive whitespace characters,
15:39:50 [klanz2]
implying that they are not of significance to the referenced data
15:39:51 [klanz2]
object and are replaced by a single white space character, ...
15:39:53 [klanz2]
1) appreciating the usually line based processing of text formats
15:39:55 [klanz2]
either line breaks are added/normalized after each start and end TAG
15:39:57 [klanz2]
2) alternatively the indention algorithm XYZ is applied
15:39:59 [klanz2]
... multiple/contradicting usage of c) is prohibited ...
15:40:01 [klanz2]
d)sorting of attributes
15:40:03 [klanz2]
e)a non-XPath-Filter based version of the enveloped signature
15:40:05 [klanz2]
transform
15:40:07 [klanz2]
f) and the like ....
15:40:17 [kyiu]
klan2 need a set of commonly needed transfroms that are streamable
15:41:25 [kyiu]
can inspect to ensure only the right set of transforms are used
15:42:33 [kyiu]
klanz2: could help hardware based implementations. Would like to get people's opinions on whether it is useful
15:44:43 [kyiu]
fhirsch3: should defer to later
15:45:48 [kyiu]
proposal is essentially parameters on canonicalization
15:46:04 [klanz2]
but you then inherit the problems from c14n
15:49:06 [Zakim]
tlr, you asked to be reminded at this time
15:49:14 [kyiu]
ACTION fhirsch3 write a draft for the note
15:49:14 [trackbot]
Created ACTION-93 - Write a draft for the note [on Frederick Hirsch - due 2008-10-28].
15:49:48 [tlr]
ACTION-93: "the note" is the note to explain the transform proposal
15:49:49 [trackbot]
ACTION-93 Write a draft for the note notes added
15:50:19 [kyiu]
,TOPIC Action Item Review
15:50:28 [tlr]
Topic: action item review
15:50:35 [tlr]
ACTION-38 closed
15:50:35 [trackbot]
ACTION-38 Enlist kelvin to write up scenarios he's interested in; split of classes closed
15:50:51 [tlr]
ACTION-52?
15:50:51 [trackbot]
ACTION-52 -- Konrad Lanz to attempt summarizing recent discussions as input for design document -- due 2008-09-02 -- OPEN
15:50:51 [trackbot]
http://www.w3.org/2008/xmlsec/track/actions/52
15:51:06 [tlr]
action-54 closed
15:51:21 [tlr]
action-57 closed
15:51:22 [trackbot]
ACTION-57 Review best practices document from implementation standpoint closed
15:51:28 [tlr]
action-81 closed
15:51:29 [trackbot]
ACTION-81 Provide draft answer to hoylen, http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0003.html closed
15:52:24 [klanz2]
13 I'll review, 52 still open, 74 closed 81 closed,
15:52:42 [kyiu]
86 and 90 looks like duplicate
15:53:04 [kyiu]
ACTION-74 closed
15:53:04 [trackbot]
ACTION-74 Summarize recursive retrievalmethod point closed
15:53:12 [kyiu]
action-81 close
15:53:44 [kyiu]
action-92 pending
15:55:38 [kyiu]
cancel call on 10/28
15:58:01 [kyiu]
ACTION kyiu provide draft note on new algorithms for 1.1
15:58:01 [trackbot]
Created ACTION-94 - Provide draft note on new algorithms for 1.1 [on Kelvin Yiu - due 2008-10-28].
15:58:36 [klanz2]
q+
15:59:35 [tlr]
action-http://www.w3.org/2007/10/htmldiff
15:59:57 [tlr]
ACTION: to introduce Kelvin to W3C spec editing
15:59:57 [trackbot]
Sorry, couldn't find user - to
16:00:08 [Zakim]
-hlockhart
16:00:09 [tlr]
ACTION: thomas to introduce Kelvin to W3C spec editing
16:00:10 [kyiu]
ACTION tlr send kelvin information about editing tools
16:00:16 [trackbot]
Created ACTION-95 - Introduce Kelvin to W3C spec editing [on Thomas Roessler - due 2008-10-28].
16:00:17 [trackbot]
Created ACTION-96 - Send kelvin information about editing tools [on Thomas Roessler - due 2008-10-28].
16:00:49 [Zakim]
-Ed_Simon
16:00:50 [Zakim]
-Executive_6
16:00:59 [Zakim]
-klanz2
16:01:00 [Zakim]
T&S_XMLSEC()2:30AM has ended
16:01:01 [Zakim]
Attendees were Executive_6, klanz2, +1.781.993.aaaa, hlockhart, Ed_Simon
16:03:32 [tlr]
rrsagent, draft minutes
16:03:32 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/10/21-xmlsec-minutes.html tlr
16:03:41 [tlr]
rrsagent, make draft member
16:03:41 [RRSAgent]
I'm logging. I don't understand 'make draft member', tlr. Try /msg RRSAgent help
16:39:24 [Norm]
Norm has joined #xmlsec
16:39:39 [Norm]
Norm has left #xmlsec
17:02:02 [anil]
anil has left #xmlsec
18:15:37 [Zakim]
Zakim has left #xmlsec
20:04:56 [anil]
anil has joined #xmlsec
21:41:47 [anil]
anil has left #xmlsec