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