IRC log of xmlsec on 2007-09-26

Timestamps are in UTC.

00:00:21 [bhill]
hal: processing model vs. structural integrity protection
00:00:46 [bhill]
tlr: id based vs. structure based approaches. how do they fit together?
00:01:48 [bhill]
scott: middle ground?
00:02:00 [bhill]
hal: remove troublesome features vs. educate on risks
00:02:37 [FrederickHirsch]
FrederickHirsch has joined #xmlsec
00:03:24 [gpilz]
gpilz has joined #xmlsec
00:04:21 [rdmiller]
rdmiller has joined #xmlsec
00:04:23 [bhill]
tlr: tactical vs. long-term concerns
00:04:23 [esimon2]
esimon2 has joined #xmlsec
00:04:31 [esimon2]
test
00:05:12 [FrederickHirsch]
hi ed
00:05:40 [bhill]
scott: id has lots of problems not discussed today, e.g. id uniqueness in the context of protocol layering
00:06:18 [bhill]
scott: has been said that "id-ness" is impossible without a DTD
00:06:52 [ht]
http://www.w3.org/TR/xml-id/
00:08:34 [bhill]
scott: xml world needs to get on same page about what an id means (tlr: vs XPointer barename)
00:08:56 [ht]
http://www.w3.org/TR/xptr-framework/#shorthand
00:09:01 [FrederickHirsch]
hal - uniqueness, id in content so add/remove can break signature, positional attacks
00:09:07 [klanz2]
klanz2 has joined #xmlsec
00:09:10 [FrederickHirsch]
scott - how to know what is an id
00:09:27 [sdw]
sdw has joined #xmlsec
00:10:42 [FrederickHirsch]
q+
00:11:27 [esimon2]
test
00:11:43 [bhill]
ht: spec exists now, didn't at the time
00:11:53 [hal]
hal has joined #xmlsec
00:12:07 [bhill]
ht: can provide a way to re-ground XMLDsig in what an id is
00:12:42 [smullan]
smullan has joined #xmlsec
00:12:48 [bhill]
ht: clause 4: sometimes an id is externally known (app specific, e.g. XHTML)
00:13:36 [bhill]
scott: what people want is layered, independent processing. not possible
00:14:46 [bhill]
jimmy: put id issue into overall context of other xml working groups - need broader analysis of big picture
00:14:58 [brich]
brich has joined #xmlsec
00:15:11 [bhill]
jimmy: xml is a tree, not a list, id considered harmful
00:15:40 [klanz2]
q+
00:16:56 [bhill]
scott disagrees, tlr kills as rathole - how to do ids without whole id-ness thing, specific XPointer type?
00:17:20 [bhill]
scott: ids defined as signature metadata - this is an id in signature context
00:18:04 [bhill]
konrad: uniqueness problems?
00:18:21 [bhill]
ht: uniqueness of ids not a well-formedness property, only a property of validation
00:18:44 [esimon2]
Ed: Can use ID where the "tree-ness" of XML is not important (which it often is). Where tree-ness is important, one needs a tree language --> XPath (perhaps profiled).
00:19:33 [esimon2]
s/which it often is/often is important/
00:20:07 [bhill]
ht: XPointer defines what a pointer means, doesn't require validation, therefore not an error if not-unique. Pointer foo is the first foo
00:21:57 [ht]
Note that we are all behaving, as we have for years, that ....#foo identifies the XML element with identifier foo, but this is strictly speaking not true until RFC3023bis comes out :-(
00:22:05 [esimon2]
Can use Xpointer and ID together (e.g. /Signature/Object[@ID='obj1']
00:24:35 [bhill]
eric: annotate attribute to tell processor what an id is
00:24:38 [esimon2]
Sounds like xsl:key in XSL
00:24:41 [klanz2]
q+
00:25:07 [bhill]
michael: would change how xml works outside of scope of signature, hard to get apps to play along
00:26:20 [bhill]
konrad: best practices guidance? use xpath for dereferencing instead of doing transformation
00:27:04 [bhill]
topic: key management
00:27:24 [klanz2]
use xpath transformation, allowing in soi
00:27:42 [bhill]
fh: key retrieval management, KeyInfo underspecified, difficult to use
00:28:15 [bhill]
fh: do people understand it?
00:29:00 [bhill]
hal: have a reasonable way to handle naked keys as a single binary/b64 value
00:29:19 [klanz2]
s/soi/some best practices for an xpath transformation to be treated as if it was dereferencing an ID according to the xpointer framework not having to change the current xmldsig spec/
00:29:30 [bhill]
hal: vs. self-signed cert
00:30:03 [bhill]
hal: (was speaking on behalf of scott, who has left)
00:30:23 [bhill]
topic: algorithms
00:30:45 [MikeMc]
I suspect Scott's issue would be address by adding a new <RSAKeyValue><PEMValue>
00:31:46 [bhill]
tlr: nsa suite b, randomization [ rsa-pss, rmx ], mandatory algorithms
00:31:56 [bhill]
tlr: important - what's next after SHA1?
00:32:40 [bhill]
tlr: dealing with mandatory algorithms as they fail, changing defaults over time
00:33:56 [bhill]
phb: XKMS for symmetric keys? ready for the quantum computer PKI doomsday?
00:35:01 [bhill]
phb: adaptations to make XKMS like Kerberos, need to specify subject/target tuples vs. just target
00:36:14 [bhill]
konrad: define future altorithims in style used for RSA-PSS
00:36:35 [bhill]
fh: key-length issues?
00:37:34 [bhill]
scott: protocol to re-encapsulate/re-encrypt broken cryptosystems
00:38:06 [gpilz]
gpilz has left #xmlsec
00:38:37 [bhill]
general: long term archival issues, DSS, LTANS, XADES
00:40:04 [bhill]
tlr: who is not coming back tomorrow?
00:40:28 [bhill]
hugo, BEA crew other than hal
00:41:00 [bhill]
ht: other issues: excl c14n, schema extensibility
00:41:37 [bhill]
tlr: adjourning for dinner
00:42:27 [PHB]
PHB has left #xmlsec
00:42:41 [MikeMc]
http://www.bucadibeppo.com/locations/location.aspx?location=0501
00:42:59 [bhill]
http://maps.google.com/maps?f=d&hl=en&geocode=&saddr=643+Emerson+Street,+palo+alto,+ca+&daddr=675+E+Middlefield+Rd,+Mountain+View,+CA+94043&sll=37.0625,-95.677068&sspn=42.901912,80.683594&ie=UTF8&ll=37.423208,-122.102051&spn=0.084387,0.157585&z=13&om=1
00:43:07 [Zakim]
-Ed_Simon
00:45:36 [MikeMc]
MikeMc has left #xmlsec
00:47:11 [Zakim]
-[Workshop]
00:47:13 [Zakim]
T&S_XMLSEC()10:30AM has ended
00:47:14 [Zakim]
Attendees were +1.650.426.aaaa, [Workshop], Ed_Simon
00:48:24 [tlr]
tlr has joined #xmlsec
16:02:05 [RRSAgent]
RRSAgent has joined #xmlsec
16:02:05 [RRSAgent]
logging to http://www.w3.org/2007/09/26-xmlsec-irc
16:02:15 [ht]
Meeting: XML Security futures workshop
16:03:19 [ht]
Chair: Frederick Hirsch
16:03:36 [ht]
Agenda: http://www.w3.org/2007/xmlsec/ws/agenda.html
16:05:14 [sdw]
sdw has joined #xmlsec
16:07:13 [EdSimon]
What is our current status?
16:07:18 [EdSimon]
test
16:07:21 [MikeMc]
waiting
16:07:33 [EdSimon]
OK
16:07:34 [MikeMc]
Jimmy isn't here yet
16:07:49 [EdSimon]
I'm ready to go on this end if you like.
16:12:54 [rdmiller]
rdmiller has joined #xmlsec
16:14:05 [smullan]
smullan has joined #xmlsec
16:15:19 [rdmiller]
Topic: Rethinking the overall approach
16:16:31 [klanz2]
klanz2 has joined #xmlsec
16:16:53 [rdmiller]
Efficient XML Interchange with XML Signature and XML Encryption Presentation by Stephen D. Williams
16:17:54 [PratikDatta]
PratikDatta has joined #xmlsec
16:21:53 [rdmiller]
Hal: Would XQuery be more efficient in EXI?
16:22:26 [rdmiller]
Stephen: The short answer is yes.
16:23:19 [klanz2]
klanz2 has joined #xmlsec
16:24:13 [rdmiller]
Link to slides: http://www.w3.org/2007/xmlsec/ws/slides/13-williams/Overview.pdf
16:31:01 [FrederickHirsch]
noted that XML not fully self-contained or self-describing, e.g. external schema information. EXI also has additional external information to record redundancy information removed
16:32:29 [FrederickHirsch]
XMS records additional info to be shared
16:34:00 [PratikDatta]
PratikDatta has joined #xmlsec
16:42:18 [hal]
hal has joined #xmlsec
16:42:48 [rdmiller]
Frederick: How will you use XML Dsig and Enc with EXI since they don't work with binary?
16:43:28 [rdmiller]
Stephen: First step would be to convert things to XML and roundtrip them into EXI.
16:43:53 [rdmiller]
Stephen: Next step is to look at EXI specific canonicalization.
16:47:16 [FrederickHirsch]
q?
16:48:05 [rdmiller]
Konrad: Is there some kind of DOM API in EXI?
16:48:21 [rdmiller]
Stephen: Initial API is STAX.
16:50:26 [rdmiller]
q?
16:51:02 [FrederickHirsch]
konrad asks about using fidelity options for c14n
16:51:33 [rdmiller]
Stephen: EXI has adjustable fidelity where the default is most compact and options can be enabled to increase fidelity.
16:53:42 [FrederickHirsch]
konrad asks whether signing EXI is consistent with see what you sign
16:53:51 [klanz2]
klanz2 has joined #xmlsec
16:55:27 [rdmiller]
Thomas asked about signing the binary information as a blob with an external reference.
16:56:20 [EdSimon]
30 min should be fine for me.
16:56:53 [EdSimon]
Sounds like the current discussion is a good prelude to my presentation.
16:57:37 [rdmiller]
Henry asked if EXI could be used to replace canonicalization.
17:00:48 [klanz2]
As EXI WG is based on the Infoset and normalizes the Information in XML documents, do you have a comprehensive set of normalization use cases that can be used as an Input to future c14n work?
17:00:52 [FrederickHirsch]
q+
17:02:38 [rdmiller]
Frederick asked if there was an interoperability issue because of the need to interpret EXI with a separate piece of software.
17:02:40 [klanz2]
williams: there is a substantial amout of work on fidelity
17:03:16 [rdmiller]
Stephen noted that he thought it was more of a library adoption issue.
17:04:03 [bhill]
bhill has joined #xmlsec
17:04:34 [klanz2]
could you sign the EXI directly being acompainged by some schema. Is that suficiently equal to a text representation of XML to fulfill "sign what you see"
17:07:05 [rdmiller]
Michael Leventhal noted that EXI should be built with security built in and does not believe that is the current direction.
17:08:24 [EdSimon]
Ed: I strongly agree with Michael. The W3C must be thinking about security in all its specifications, especially core ones. Not sufficient to think security can just be patched on afterwards.
17:09:55 [rdmiller]
Ed Simon Presentation - A Layered Approach to XML Canonicalization
17:10:53 [sean]
sean has joined #xmlsec
17:11:23 [rdmiller]
Link to slides: http://www.w3.org/2007/xmlsec/ws/slides/18-edsimon-xmlsec/
17:28:33 [FrederickHirsch]
q+
17:30:18 [rdmiller]
Jimmy does not understand what XML canonicalization has to do with security and asked for some clarification.
17:31:19 [rdmiller]
Ed explained that it is not required if the XML will not be modified in transmission.
17:33:58 [FrederickHirsch]
ack FrederickHirsch
17:34:30 [rdmiller]
Ed explained that schema aware canonicalization can validate "10" and "+10" as the same integer value.
17:34:53 [rdmiller]
Thomas asked how floating point rounding issues may be handled.
17:35:34 [rdmiller]
Ed suggested that the rounding issues shouls be handled as part of the business process and should be done before signing.
17:36:06 [rdmiller]
Konrad asked how wildcards should be treated in schemas.
17:36:14 [rdmiller]
Ed has not thought about it.
17:37:41 [rdmiller]
Konrad postulated that there should be application aware namespace canonicalization.
17:38:21 [hal]
q+
17:39:22 [rdmiller]
Konrad: How does EXI deal with namespace prefixes?
17:40:08 [rdmiller]
Stephen: Namespaces are fully computed for every element and every attribute.
17:42:55 [rdmiller]
Hal: Preservation of the prefix is a requirement of XML digital signature in order to support XPath etc.
17:44:15 [FrederickHirsch]
q?
17:45:09 [tlr]
ack hal
17:47:07 [rdmiller]
Jimmy does not think shema validation is a good thing and is of the opinion that trhe application should handle the normalization.
17:47:30 [klanz2]
q+
17:47:48 [rdmiller]
Stephen: EXI is tunable and can be configured to preserve prefixes.
17:49:09 [tlr]
q?
17:50:15 [rdmiller]
Phillip agrees with Jimmy that schema based canonicalization is not a good idea.
17:51:47 [jcc]
jcc has joined #xmlsec
17:52:59 [tlr]
ack klanz
17:55:24 [rdmiller]
Phillip does not think that the 10, +10 question is a security issue and that should be hanled by application developers.
17:55:44 [rdmiller]
Konrad disagrees with Phillip strongly.
17:56:49 [Pratik]
Pratik has joined #xmlsec
17:57:57 [sdw]
sdw has joined #xmlsec
17:58:15 [rdmiller]
Konrad noted that transforms are not allowed to change the document so schema based canonicalization should be used for normalization.
17:58:43 [rdmiller]
On break for 20 minutes until 11:20 PDT
18:04:00 [Pratik]
This is in defence of Schema aware canonicalization. One big problem for our signatures to break is that some people put line breaks in base64 encoded values whereas others don't
18:04:43 [EdSimon]
Hal is correct in that the final version of Canonicalization v1.0 eliminated namespace rewriting which was present in the prior drafts. Version 1.1 of Canonicalization summarized the namespace rewriting issue as such:
18:04:45 [Pratik]
if c14n were schema aware, it would know that line breaks in base64 encoded values is not significant
18:05:07 [EdSimon]
The C14N-20000119 Canonical XML draft described a method for rewriting namespace prefixes such that two documents having logically equivalent namespace declarations would also have identical namespace prefixes. The goal was to eliminate dependence on the particular namespace prefixes in a document when testing for logical equivalence. However, there now exist a number of contexts in which namespace prefixes can impart information value in an XML document. Fo
18:09:35 [EdSimon]
My objection to c14n 1.1 is that while not rewriting namespaces for that particular document preserves that document's integrity, it does not allow comparison with a completely equivalent document that happens to use a different namespace. There should be a way of canonicalizing namespaces that neither corrupts a document but also allows logical equivalence. Not rewriting does the first but not the second. Namespace-aware canonicalization, with namespace can
18:17:17 [tlr]
http://www.ximpleware.com/security/
18:19:33 [rdmiller]
Presentation by Jimmy Zhang
18:19:43 [Pratik]
Pratik has joined #xmlsec
18:19:49 [PratikDatta]
PratikDatta has joined #xmlsec
18:21:35 [FrederickHirsch]
design issues versus implementation issues
18:25:35 [EdSimon]
Yes, I can thanks.
18:28:53 [rdmiller]
Henry: The goal of the infoset spec is to provide a standard terminology for spec writers.
18:31:22 [jcc]
jcc has joined #xmlsec
18:35:37 [klanz2]
http://tools.ietf.org/html/rfc4051#page-9
18:35:48 [klanz2]
Minimal Canonicalization
18:37:04 [rdmiller]
Presentation by Pratik Datta
18:39:26 [EdSimon]
Is there a link to the slides?
18:40:34 [rdmiller]
Link to slides: http://www.w3.org/2007/xmlsec/ws/slides/12-mishra-oracle/
18:41:18 [FrederickHirsch]
XML signature expensive because of node sets, node sets requires DOM
18:41:33 [FrederickHirsch]
expands 20x in memory
18:41:47 [FrederickHirsch]
each transform requires 2 nodesets, each of which has to be in memory
18:41:58 [FrederickHirsch]
streaming can address memory issue
18:42:47 [FrederickHirsch]
if not needing DOM for doc processing
18:50:14 [hal]
RFC 4051 (and RFC 3275) only define the identifier for Minimal C14N
18:50:37 [hal]
the description is in 3075
18:51:31 [hal]
http://tools.ietf.org/html/rfc3075#page-43
18:53:35 [rdmiller]
Frederick asked if the document information would be stored for every pipeline.
18:54:09 [jcc]
jcc has joined #xmlsec
18:54:43 [rdmiller]
Preteek said that it was not an issue because most XML documents are not more than 20 pipelines.
18:57:31 [bhill]
another good case for a minimal XPath profile
18:57:40 [EdSimon]
s/Preteek/Pratik/
19:00:08 [FrederickHirsch]
konrad: xpath data model does not say what it means when you remove namespace
19:00:19 [FrederickHirsch]
node from nodeset
19:02:49 [EdSimon]
What Phill says works for cases where there are not intermediary rewriters.
19:03:45 [FrederickHirsch]
discussion of layering, whether to verify sigs before other processing, varying application needs for xml security etc
19:04:49 [FrederickHirsch]
konrad: nodesets have underlying document available
19:13:44 [FrederickHirsch]
phill: transform changes instance, also concurrently schema changes, so you have new document effectively
19:14:11 [FrederickHirsch]
konrad: +1, need to distinguish transformations from selections. This should be on WG agenda,
19:15:02 [EdSimon]
To paraphrase Konrad (I hope), transformations require full document; selections may not.
19:19:39 [FrederickHirsch]
how to do both look ahead and behind, to allow both sig generation and verification?
19:20:07 [FrederickHirsch]
pratek: 2 pass applies here, still good
19:20:26 [FrederickHirsch]
concern expressed that in network 2 pass might not be good
19:21:06 [EdSimon]
s/pratek/Prateek/
19:21:32 [EdSimon]
s/Pratik/Prateek/
19:22:52 [FrederickHirsch]
sean: apache implementation has pipelining model, but some limitations
19:23:36 [FrederickHirsch]
konrad: jsr 105 constrains order in documents (?)
19:23:46 [rdmiller]
Presentation by Henry S. Thompson: Radical proposal for Vnext of XML Signature
19:23:56 [rdmiller]
Link to slides: http://www.w3.org/2007/xmlsec/ws/slides/20-thompson/
19:30:59 [EdSimon]
q+
19:31:44 [bhill]
q+
19:31:55 [FrederickHirsch]
ht: proposal, use XMill encoding and digest that
19:32:34 [FrederickHirsch]
http://www.liefke.com/hartmut/xmill/xmill.html
19:33:03 [FrederickHirsch]
http://sourceforge.net/projects/xmill
19:35:19 [FrederickHirsch]
ht: consider replacing c14n in subsequent wg
19:35:30 [rdmiller]
q?
19:35:44 [FrederickHirsch]
konrad: sign what you see, need to be able to examine what is digested
19:37:04 [FrederickHirsch]
ht: avoid issues of namespaces, simplify by avoiding
19:37:22 [FrederickHirsch]
EdSimon: +1 to ht
19:38:16 [rdmiller]
q?
19:38:36 [EdSimon]
q-
19:38:59 [FrederickHirsch]
phill: remove requirement to end with well formed xml can simplify c14n
19:39:45 [FrederickHirsch]
ht: focus on c14n output to only be input for digest, not viewable etc
19:40:19 [EdSimon]
q+
19:41:27 [EdSimon]
q-
19:41:32 [FrederickHirsch]
ack bhill
19:41:39 [FrederickHirsch]
q?
19:43:51 [EdSimon]
q+
19:45:08 [FrederickHirsch]
Brad: concern about actual usage, ability to view c14n output
19:45:23 [FrederickHirsch]
konrad: +1, concern about ability to view, legal requirements etc
19:45:59 [FrederickHirsch]
tlr: cannot display much on a 2 line card reader
19:46:43 [FrederickHirsch]
mike: output of c14n is octet stream, also can sign anything, not just xml
19:46:57 [sdw]
You can display things like transaction total. This is key.
19:48:00 [sdw]
Not using the C14N version of data means that unsigned information can leak.
19:48:04 [rdmiller]
q?
19:48:09 [FrederickHirsch]
q?
19:48:10 [sdw]
q+
19:49:02 [FrederickHirsch]
phill: need to interpret output of transforms to avoid attacks, but not necessariy output of c14n which is part of digest/sig processing
19:50:00 [FrederickHirsch]
... want integrated serialize+sign operation
19:50:11 [FrederickHirsch]
ack EdSimon
19:50:44 [FrederickHirsch]
ack sdw
19:50:52 [FrederickHirsch]
ack sdw
19:51:19 [FrederickHirsch]
sdw: make sure you use data that was actually signed
19:52:28 [FrederickHirsch]
... regarding see what you sign, don't see raw xml, so other processing happens. Summary might be displayed, such as "transaction total"
19:52:57 [ht]
http://www.w3.org/2007/xmlsec/ws/slides/20-thompson/
19:53:26 [ht]
[sorry]
19:53:28 [FrederickHirsch]
jimmy: argues for output of well-formed xml in transform. Don;t assume DOM
19:53:59 [FrederickHirsch]
... byte level processing
19:54:52 [EdSimon]
There is a difference between signing to prevent attacks and signing to provide a trustable, semantically-meaningful application action. The view Henry and I share is focused on the latter. This does not exclude the use of say, even canonicalization-free, signing for the issues Brad and Konrad raised. XML Signature has this flexibility.
19:55:07 [FrederickHirsch]
erik: trust in engine for signing
19:55:28 [FrederickHirsch]
konrad: is question, add another form of c1n4 for non-xml
19:55:34 [FrederickHirsch]
break for lunch
19:55:42 [Zakim]
-Ed_Simon
19:55:50 [EdSimon]
test
19:56:12 [EdSimon]
Just some comments relating to previous topics...
19:56:30 [EdSimon]
Prateek wrote (above, after Ed's presentation): "This is in defence
19:57:37 [EdSimon]
Prateek wrote (above, after Ed's presentation): "This is in defence of Schema aware canonicalization. One big problem for our signatures to break is that some people put line breaks in base64 encoded values whereas others don't. If c14n were schema aware, it would know that line breaks in base64 encoded values is not significant."
19:57:54 [EdSimon]
Ed: Yes, that is a good example where schema-aware canonicalization is necessary.
19:58:32 [EdSimon]
Ed: Minimal canonicalization only really addresses the character set -- not really XML-specific -- usable for many text documents not just XML.
19:59:00 [EdSimon]
Ed: About XML Canonicalization vs. minimal canonicalization...XML Canonicalization is necessary, perhaps a necessary evil, when there is the chance that an XML instance has been read and rewritten by an intermediate application (otherwise don't canonicalize!) or is being read and parsed by an end application (e.g. signature validator). That application may produce an XML instance that is not the same as the original on a per-character basis, but may be
19:59:50 [EdSimon]
I was cut off from the phone line before I heard when the group was reconvening. Could you please state the reconvening time in the IRC?
19:59:57 [MikeMc]
1:45
20:00:04 [EdSimon]
Thanks
20:00:06 [MikeMc]
np
20:43:14 [jcc]
jcc has joined #xmlsec
20:44:45 [Zakim]
+Ed_Simon
20:59:15 [tlr]
tlr has joined #xmlsec
20:59:44 [tlr]
Topic: wrap-up
21:02:25 [Pratik]
Pratik has joined #xmlsec
21:02:25 [PratikDatta]
PratikDatta has joined #xmlsec
21:05:03 [tlr]
zakim, who is on the phone?
21:05:03 [Zakim]
On the phone I see [Workshop], Ed_Simon
21:05:04 [smullan]
smullan has joined #xmlsec
21:05:08 [tlr]
ScribeNick: smullan
21:05:10 [ht]
rrsagent, where
21:05:10 [RRSAgent]
I'm logging. I don't understand 'where', ht. Try /msg RRSAgent help
21:05:18 [tlr]
rrsagent, bookmark
21:05:18 [RRSAgent]
See http://www.w3.org/2007/09/26-xmlsec-irc#T21-05-18
21:06:06 [smullan]
Konrad: xmldsig relies on xpath data model but does not specify it for 1.1
21:06:21 [smullan]
... put on agenda for future work
21:07:17 [smullan]
henry: xml 1.1 - encourage specs to move to it
21:07:52 [smullan]
konrad: need to find out who owns xpath 1.0 and ask if they want to shift to xml 1.1
21:08:17 [smullan]
brad: xpath 2.0 has more security issues
21:08:50 [smullan]
henry: use xpath 2.0 data model, not necessarily everything else
21:09:20 [EdSimon]
I believe the suggestion is to profile
21:09:39 [EdSimon]
XPath,using its data model, to limited functionality necessary for XML Signature.
21:09:49 [smullan]
tlr: use xproc to specify transforms?
21:10:01 [smullan]
s/tlr/henry
21:11:12 [smullan]
konrad: xpath 2.0 main difference is namespace declarations
21:13:03 [FrederickHirsch]
sean: node filters in apache is optimization to avoid creating node sets
21:14:36 [smullan]
Pratik: can extend pipelining model to work on octet streams
21:16:45 [smullan]
tlr: c14n part of discussion
21:17:06 [smullan]
tlr: overall c14n not satisfactory
21:18:56 [smullan]
phil: applications act on the output of transforms (the pre-hash)
21:21:41 [smullan]
tlr: interaction with other groups
21:22:03 [smullan]
... interact with exi early
21:22:26 [smullan]
konrad: add relation to wraping attacks to sign what you see
21:23:23 [smullan]
frederick: have we captured need for security considerations by other groups (saml, etc)
21:24:57 [smullan]
tlr: refactoring slide - what a future charter could look like
21:25:23 [smullan]
... 3 ways, 1) work on profiles, impl. guidance, constraining but back. compat
21:25:50 [smullan]
... 2) no constraints, refactor specs; incorporate lessons learned
21:26:15 [smullan]
3) back. compat as much as possible; break it only if you have to
21:27:07 [smullan]
pratik: have to be b.c. so many specs dependent on xml dsig
21:27:43 [smullan]
konrad: predefined sets to enforce different profiles good approach
21:29:05 [EdSimon]
I'm less concerned with backwards compatability; if specs want backward compatibility with the old spec, they can use the old spec. If specs want the new features, they will be rewriting their specs anyway.
21:29:11 [smullan]
jimmy: adoption for wss is modest; b.c. will hold us back; take long term view
21:30:21 [smullan]
hal: b.c. should not be requirement
21:30:26 [EdSimon]
+1 to hal
21:30:38 [rdmiller]
+1 Hal, Jimmy, and Ed
21:31:08 [EdSimon]
Hal: apps can continue to accept old signatures but may generate new version signatures
21:33:10 [smullan]
konrad: stay as close to current specification if we can
21:34:18 [smullan]
phil: don't think new apps need to read existing sigs
21:35:26 [FrederickHirsch]
need clear requirements generation as part of potentially chartered wg, clarity on tradeoffs as part of work item
21:37:05 [smullan]
hal: signed stuff out there that already exists; so still need to verify it
21:38:04 [EdSimon]
+1 to Phill
21:38:22 [smullan]
jimmy: performance has to be good enough
21:38:34 [smullan]
everyone: +1
21:39:49 [smullan]
jcc: don't forget requirements for keeping signed docs for 5 or more years
21:40:41 [smullan]
rdmiller: thinks jcc's comment is an application issue
21:41:46 [smullan]
frederick: old spec is not going away. may need 2 implementations
21:42:04 [EdSimon]
Ed: I imagine there are archival requirements for decades; I do not see how these requirements affect us. The archives in question need to archive the specifications for the archive, including old XML Signature, and, perhaps, old systems for validating them.
21:42:52 [EdSimon]
+1 to Henry from Ed
21:43:04 [smullan]
henry: if consensus, we need to say we are not deprecating xml dsig 1.0 in charter
21:43:21 [rdmiller]
+1 to Henry
21:44:04 [ht]
q+ to address PHB's point
21:45:30 [smullan]
phil: archival document requirement is overrated
21:45:49 [EdSimon]
It is up to the archivists to ensure their data continues to be usable; not us.
21:46:07 [smullan]
tlr: lot of complexity is about optional parts of spec
21:46:21 [smullan]
... lot of pain caused by optional features
21:46:56 [rdmiller]
+1 to Thomas
21:47:44 [smullan]
henry: should charter also say what of xml dsig 1.0 should be in scope for WG?
21:49:41 [smullan]
frederick: what is the outcome of this workshop, how is charter accomplished?
21:50:29 [smullan]
tlr: existing wg chartered to do maint of spec and c14n 1.1 and input into new charter proposal
21:52:05 [smullan]
tlr: useful to participate in maint. wg on charter development
21:52:37 [smullan]
tlr: but wg should take broad/public view into account
21:55:10 [smullan]
tlr: thinks we are hearing lets do a xml sig v.next
21:55:49 [smullan]
... one way to add layers to 1.0
21:58:17 [smullan]
mike: a lot of times applications want streamlined set of algs, specify something
21:58:30 [smullan]
.. efficient, if libraries want to imlement more, that is ok
21:58:50 [klanz2]
klanz2 has joined #xmlsec
21:58:56 [smullan]
frederick: we need to be specific about what features are needed
21:59:21 [smullan]
jimmy: 20% of complexity can cover 80% of use cases
21:59:42 [smullan]
... wants to see core cover as many use cases as possible
22:00:13 [smullan]
frederick: 20/80 can also apply to business
22:00:26 [smullan]
konrad: dss has basic processing
22:00:33 [EdSimon]
<Manifest> is used by the Office Open XML specification (e.g. Microsoft Office). That, in itself, would constitute fairly wide use.
22:00:40 [smullan]
... look at dss for ideas
22:01:45 [smullan]
jimmy: 5 minute tutorial should be goal
22:02:16 [smullan]
stephen: may not have luxury of doing this many times
22:02:36 [smullan]
henry: get one chance to do spec that breaks compatibility
22:05:49 [smullan]
tlr: one final pass through all slides to see whcih topics are of most interest
22:06:03 [smullan]
tlr: Profiles area
22:08:49 [smullan]
tlr: looking for rough numbers of who is interested in working on basic profile
22:09:11 [EdSimon]
I am interested in working on a number of topics (though my time is limited).
22:13:12 [smullan]
determistic-time processing: should be linear to size of document; robust against dos attack
22:14:00 [smullan]
... scaling behavior ... O(n)
22:15:20 [smullan]
sean: should be part of basic profile
22:16:01 [smullan]
jimmy: do we need to bring discussions to other WGs?
22:16:24 [smullan]
tlr: WGs should work together on topics of mutual interest
22:16:54 [smullan]
tlr: Profiles (II) slide
22:17:38 [EdSimon]
Ed is keen on profiling work.
22:18:06 [smullan]
frederick: other groups have worked on profiles; we need to include others
22:18:22 [smullan]
... even WGs whose charters have ended
22:19:46 [smullan]
tlr: use-case profiles - who is interested?
22:22:11 [smullan]
tlr: is there interest in working on guidelines for profiles? 4 hands
22:22:18 [EdSimon]
+1
22:22:58 [bhill]
edSimon - to which question are you +1?
22:23:07 [smullan]
tlr: interest in profiles beyond basic one? 1 hand?
22:23:26 [EdSimon]
+1 for the use-case profiles beyond the basic (I might have missed some audio).
22:25:45 [smullan]
tlr: efficiently verifiable profile -fine tune later
22:26:03 [smullan]
tlr: impl. guidance slide
22:27:15 [smullan]
4-5 interested in working on this
22:27:28 [smullan]
key mgmt slide
22:28:08 [EdSimon]
Yes to having XKMS spec on the table.
22:28:13 [smullan]
Interest in working on XKMS?
22:28:47 [smullan]
konrad: can we attract others to work on xkms?
22:29:19 [smullan]
frederick: would this be a broader xml security WG if we include XKMS?
22:29:46 [smullan]
6-7 interested in XKMS
22:31:08 [smullan]
frederick: goal is to get everything of interest on table; decide later what to do
22:31:48 [smullan]
phil: version of XKMS that use new version of xml dsig and some additions for symmetric keys
22:32:00 [EdSimon]
Just a reminder that Ed thought it might be good move KeyInfo out of XML Signature -- ideally into XKMS.
22:32:10 [smullan]
tlr: who is interested in refactoring KeyInfo?
22:32:41 [smullan]
7 people interested
22:32:54 [smullan]
tlr: referencing model slide
22:34:13 [smullan]
interest in improving id-based approaches?
22:34:42 [EdSimon]
Ed: yes
22:36:18 [smullan]
eric: we need to make ids more efficient and work in absense of schema
22:39:05 [smullan]
mike: doesn't like idea of transform specifying id attributes
22:39:33 [smullan]
hal: want to fix references but don't know best way to do it
22:39:57 [MikeMc]
not sure I like or don't like - but see potential pitfalls in changing data that the signature depends on
22:40:35 [smullan]
11 people interested in fixing IDness problems
22:40:49 [smullan]
tlr: Algorithms slide
22:41:19 [smullan]
work on adding new algorithms
22:41:45 [smullan]
mike: need a standard mechanism for adding new algs
22:42:38 [smullan]
hal: how to anticipate adding alg parameters, not just alg URI
22:43:58 [smullan]
10 people interested in working on this
22:44:14 [smullan]
tlr: Other issues slide
22:45:02 [smullan]
frederick: excl c14n is just an algorithm issue
22:45:37 [EdSimon]
If by algorithms, one is including more than just crypto algorithms, then I'm interested.
22:45:41 [smullan]
konrad: would we be open to ammend c14n to include excl c14 parameter list
22:46:09 [EdSimon]
Maybe one should distinguish between the crypto and non-crypto algorithms. (If we are, I missed it on the audio.)
22:46:42 [smullan]
I think it is all algorithms
22:47:26 [smullan]
hal: mechanism to encapsulate xml?
22:50:06 [smullan]
henry: where is the requirement for this coming from?
22:50:50 [EdSimon]
Is not base64'ing the XML and putting it into an <Object> sufficient?
22:51:03 [EdSimon]
q+
22:52:22 [ht]
q-
22:52:44 [ht]
Ed, yes, but you shouldn't have to do that
22:53:01 [ht]
ack ed
22:53:03 [smullan]
6 people interested in encapsulating xml
22:55:40 [ht]
HST hears MM as requesting a chroot functionality :-)
22:56:11 [smullan]
Transform model slide
22:56:15 [EdSimon]
If base64'ing the XML is not the right solution because you want it parsable, then you may need a special XML packaging element that tells the processor that the contained XML is to be processed as if it was an independent document.
22:56:37 [ht]
Thanks -- between you and Mike I know get the point, I think
22:56:43 [ht]
s/know/now/
22:57:20 [EdSimon]
Ed is interested in the Transform model
22:57:24 [smullan]
10 people interested in transform work
22:57:37 [smullan]
C14N Slide
22:59:16 [smullan]
tlr: interest in revisiting mandatory to implement c14n?
22:59:23 [EdSimon]
Ed is interested in C14N
22:59:34 [smullan]
14 people interested
23:07:35 [EdSimon]
Thanks everyone and VeriSign for making an excellent conference.
23:08:18 [MikeMc]
MikeMc has left #xmlsec
23:10:12 [Zakim]
-Ed_Simon
23:19:44 [Zakim]
-[Workshop]
23:19:46 [Zakim]
T&S_XMLSEC()10:30AM has ended
23:19:47 [Zakim]
Attendees were [Workshop], Ed_Simon
23:25:38 [bhill]
bhill has left #xmlsec
23:52:10 [FrederickHirsch]
Zakim, list particpants
23:52:10 [Zakim]
I don't understand 'list particpants', FrederickHirsch
23:52:19 [FrederickHirsch]
Zakim, list particpants
23:52:19 [Zakim]
I don't understand 'list particpants', FrederickHirsch
23:52:27 [tlr]
zakim, list participants
23:52:27 [Zakim]
sorry, tlr, I don't know what conference this is
23:52:36 [tlr]
rrsagent, please draft logs
23:52:36 [RRSAgent]
I'm logging. I don't understand 'please draft logs', tlr. Try /msg RRSAgent help
23:52:42 [tlr]
rragent, please draft minutes
23:52:54 [tlr]
rrsagent, please draft minutes
23:52:54 [RRSAgent]
I have made the request to generate http://www.w3.org/2007/09/26-xmlsec-minutes.html tlr