15:57:53 RRSAgent has joined #xmlsec 15:57:53 logging to http://www.w3.org/2007/09/25-xmlsec-irc 15:57:59 Meeting: XML Security Workshop 15:58:07 Scribe: Henry S. Thompson 15:58:11 ScribeNick: ht 15:58:20 bridge is setup 15:58:36 -Ed_Simon 15:59:08 +Ed_Simon 15:59:17 Agenda: http://www.w3.org/2007/xmlsec/ws/agenda.html 15:59:59 smullan has joined #xmlsec 16:00:10 esimon2 has joined #xmlsec 16:00:36 Hi, I've phoned in and can hear voices; not sure if you can hear me. 16:00:43 we haven't heard you so far 16:00:51 I'm talking now. 16:00:56 we don't hear you 16:01:22 Don't worry too much about not hearing me, I'll type in anything I need to say. 16:01:28 I can hear you. 16:02:20 I can hear you. 16:02:23 We can't hear you :-( 16:02:37 Don't worry too much about not hearing me, I'll type in anything I need to say. 16:02:54 Wait a mo, Chris will turn on the voice from God feature 16:02:56 Speak now 16:03:05 you can stop now 16:03:07 I'm countin 16:04:12 Was there a web link to see slides; I think Phill had mentioned something about a Sharepoint server. Again, if it is not set up, that is fine. I'm OK with just listening in. 16:04:54 Yes, I can hear Frederick. 16:05:12 -Ed_Simon 16:06:42 hiroki has joined #xmlsec 16:06:47 +Ed_Simon 16:07:40 what? 16:08:06 FH: The purpose is not to do the work here, but to decide if and how to take work forward -- how much interest is there in participating in a follow-on to the XMLSec Maint WG -- what would the charter look like, what issues we would addresss 16:08:20 ... We will use IRC to log and to provide background info 16:08:36 sdw has joined #xmlsec 16:08:48 Chair: Frederick Hirsch 16:09:17 s/The purpose/The purpose of this workshop/ 16:10:43 MikeMc has joined #xmlsec 16:10:48 ht has changed the topic to: Agenda: http://www.w3.org/2007/xmlsec/ws/agenda.html 16:11:26 FH: Please consider joining the XMLSecMaint WG 16:11:39 ... Weekly call, interop wkshp on Thursday 16:11:54 ... Thanks to the members of the WG who reviewed papers for this workshop 16:12:48 ThomasRoessler: Existing WG has a limited charter, maintenance work only 16:12:58 I can hear very well, thanks. 16:13:11 ... ALso chartered to propose a charter for a followon WG 16:13:37 ... We won't draft a charter at this workshop, but we hope to produce a report which indicates support and directions 16:13:44 gpilz has joined #xmlsec 16:13:49 ... That in turn will turn into a charter, if the outcome is positive 16:14:12 ... Which then goes to the Advisory Committee for a decision 16:14:23 ... The timescale is next year and beyond 16:15:17 s/what?/Topic: Introduction/ 16:15:42 TR: [walks throught the agenda] 16:17:04 Attendance: approx. 25 people in the room 16:19:47 TR: Slides which are on the web, drop URI here; otherwise send in email to ht@w3.org and tlr@w3.org 16:22:25 FrederickHirsch has joined #xmlsec 16:25:05 zakim, who is here? 16:25:06 On the phone I see [Workshop], Ed_Simon 16:25:06 On IRC I see FrederickHirsch, gpilz, MikeMc, sdw, hiroki, esimon2, RRSAgent, ht, rdmiller, tlr, trackbot-ng, Zakim 16:25:25 I spoke, did you hear me? 16:25:38 ed, you were 100% clear 16:27:02 cgi-irc has joined #xmlsec 16:27:12 http://cgi.w3.org/member-bin/irc/irc.cgi 16:27:45 ht_ has joined #xmlsec 16:27:52 [Talks will not be scribed, scribing will resume for discussion] 16:28:14 http://www.w3.org/2007/xmlsec/ws/slides/04-hill-isecpartners/Overview.pdf 16:29:17 zakim, cgi-irc is brich 16:29:17 sorry, cgi-irc, I do not recognize a party named 'cgi-irc' 16:29:29 bruce, don't worry. ;) 16:30:00 klanz2 has joined #xmlsec 16:32:33 test ... 16:33:35 can use xslt and xpath2.0 to create signature malware 16:38:43 Audio has ended for me. 16:38:58 we can tellsomething changed - phil is looking into it 16:39:08 audio is back! 16:39:16 switched mics 16:39:47 ed do you have audio now? 16:41:42 [Following is approximate, apologies for mistakes] 16:41:45 Attendance: Frederick Hirsch, Konrad Lanz, Juan Carlos Cruelas, Bruce Rich, Mike McIntosh, Hugo Krawczyk, Gilbert Pilz, Hiroki Ito, Brad Hill, Rob Miller, Jeannine Schmidt, Henry Thompson, Sean Mullan, Gary Chung, Michael Leventhal, Steven Williams, Pratik Data, ? Chen, Phillip Hallam-Baker, Thomas Roessler, Ed Simon (via phone) 16:45:52 TR: Questions of clarification 16:46:12 FH: Restricting to only a few transformations? 16:46:32 BH: Yes, restrict to just small well-known set 16:47:10 SC: Mostly to implementations, rather than specs 16:47:18 smullan has joined #xmlsec 16:47:29 ... Need to reduce the attack surface of implementations 16:47:39 ... so we need an implementors guide, right? 16:48:12 BH: Right 16:48:39 KL: XSLT should default to _dis_able features, not _en_able 16:49:26 s/Sean Mullan/Scott Cantor, Sean Mullan/ 16:50:01 s/Pratik Data/Pratik Datta/ 16:50:46 http://www.w3.org/2007/xmlsec/ws/slides/07-gajek-rub/ 16:55:04 zakim, code? 16:55:04 the conference code is 965732 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), tlr 16:59:02 Ed's comment: If the structure of a document is important to the meaning of the document (as shown in the examples), then signing by ID (which is movable) is insufficient. 16:59:22 BH: How would you compare doing a hashed retrieval compared to ??? 17:00:02 Presentation highlights the need to rethink the XPointer functionality. 17:00:05 [scribe didn't get the question] 17:00:25 MM: Apps certainly need to interact better with signature processing 17:01:07 ... Need for overlapping signatures implies a need for a signature object model, so you can iterate over all the signatures and treat them independently 17:02:18 Ed says: I don't know that apps need to interact with signature processing better; rather, apps need to ensure the signatures they use sign all the critical information -- content as well as structure. 17:02:32 TR: Open up discussion of security vulnerabilities, other than crypto 17:03:17 MM: It's a pain that I have to encrypt the signature block 17:04:42 MM: DigestValue should be optional 17:04:55 ScribeNick: tlr 17:05:07 q+ 17:05:52 ack klanz 17:06:34 MM: presence of DigestValue means that plaintext guessing attack is possible if plaintext encrypted 17:06:51 ... therefore, would have to encrypt the signature as well ... 17:06:55 FH: why is tha tpainful? 17:06:58 MM: tried xml ecn? 17:07:01 s/ecn/enc/ 17:07:37 Konrad: having digest necessary for manifest procesing 17:07:51 Scott: should be optional to have digests 17:08:18 Konrad: also verification on constant parts that are archived separately etc 17:08:29 klanz: Know of manifest use in electronic billing context 17:10:08 s/Datta/Datta, Corinna Witt, Jeff Hodges, Jimmy Zhang/ 17:11:59 http://www.iaik.tugraz.at/teaching/11_diplomarbeiten/archive/scheibelhofer.htm 17:12:17 Signing XML Documents and the Concept of “What You See Is What You Sign” 17:12:47 scott: need profiles *and* implementation guidelines 17:13:25 q+ 17:14:45 frederick: asks about clarifying what implementation guide is versus profiling 17:15:12 Scott: need to have hooks in code that enable best practices to be followed ,implementation guide 17:15:55 ... for example, saying signature is valid isn't enough if you are not sure what has been signed, hooks may be needed for this 17:16:59 ack klanz2 17:17:05 q- 17:18:49 Ed: I am OK with just listening in and typing comments on IRC. No need to complicate things for others on my account. 17:19:46 q+ 17:19:52 Symon: policy can be used to limit what is done with xml security, anohter approach to avoid problems 17:20:29 ack klanz 17:20:59 discussion as to whether xmlsig spec is broken 17:21:14 The XSLT 2.0 specification mentions a number of security considerations dealing with issues raised earlier. 17:21:31 Agree with Konrad. 17:22:24 Hal Lockhart presenting; slides later 17:23:48 yes 17:24:24 q? 17:25:01 Thanks very much. 17:27:12 jcc has joined #xmlsec 17:37:55 hal: notes various issues have been document in ws-security, ws-i basic security profile and other places 17:38:08 frederick: also liberty alliance work 17:41:53 q+ 17:42:09 ack klanz2 17:42:36 klanz2: false negatives will be perceived very badly 17:43:21 ... need to focus on what you see is what you sign, then false negatives main issue 17:43:32 hal: agrees 17:44:34 hal: challenge is interface between applicatoin and security processing to get proper security for applciation 17:45:23 henry thomson: liaison issues - schema, processing model wg, 17:45:48 ... say to validate you must decrypt, perhaps 17:45:57 q+ 17:47:08 I agree, I think, with Henry re his comments about XPointer to help resolve the ID issue. 17:47:15 ... re id issue , maybe new xpointer version? 17:47:50 s/xpointer version/xpointer scheme/ 17:48:12 scott: +1 to klanz, concern about false positivies, issues for adoption 17:48:26 ack klanz2 17:48:30 ack klanz 17:48:40 ack klanz 17:49:28 scott: most xml processing is not schema aware, xsi:type is not visible to processing 17:50:24 ht: would issue be solved if sig re-worked to be signing of Infosets 17:52:03 klanz: tradeoff performance & infoset signing 17:53:47 PHB has joined #xmlsec 17:54:19 q+ 18:02:22 ack PHB 18:02:59 PHB: could use some examples of difference between infoset and current signing approach. What is really different. 18:05:43 Symon has joined #xmlsec 18:06:08 q- 18:30:58 ScribeNick: tlr 18:31:03 Topic: cryptographic aspects 18:31:27 http://www.w3.org/2007/xmlsec/ws/slides/11-mcintosh-ibm/ 18:31:35 Hugo Krawczyk presenting 18:31:46 the slides for this session are at http://www.ee.technion.ac.il/~hugo/rhash/ 18:32:47 hugo: post-wang trauma, how do we deal with it... 18:33:01 actually - the papers are there - not the slides - sorry 18:33:22 slides are at the link I gave above 18:33:42 sean has joined #xmlsec 18:35:55 sean has joined #xmlsec 18:36:06 FH has joined #xmlsec 18:36:36 zakim, who is on the phone? 18:36:36 On the phone I see [Workshop], Ed_Simon 18:36:58 zakim, who is here? 18:36:58 On the phone I see [Workshop], Ed_Simon 18:36:59 On IRC I see FH, sean, Symon, PHB, jcc, smullan, ht, cgi-irc, gpilz, MikeMc, sdw, hiroki, esimon2, RRSAgent, rdmiller, tlr, trackbot-ng, Zakim 18:48:13 FrederickH has joined #xmlsec 18:48:21 klanz2 has joined #xmlsec 18:49:14 hal: any attacks for which we need to check whether random strings are diferent? 18:49:25 hugo: critical for the signer to check that these strings are different 18:49:35 hal: if random value same for every signature, then can do offline attacks 18:49:51 mike: every time you create new signature, you create new value 18:49:58 hal: how important is it to the verifier that this is the case? 18:50:05 ... suppose there's no real signer, just a blackhat sending messages ... 18:50:15 ... do you have to keep track of fact that he sends same random number? ... 18:50:53 hugo: if you don't find 2nd preimage on one-way function, then attacker can't 18:51:03 hal: thinking about guessing attack or so 18:51:17 ... there are attacks against CBC if IV isn't always different ... 18:51:30 hugo: uniqueness of randomness per signature is not requirement 18:51:41 ... requirement is that the attacker must not know randomness that legitimate signer is going to use ... 18:52:09 ... question is a valid concern, though ... 18:52:14 ... in this case, there's no more to it .. 18:52:36 phb: fuzzy about what security advantage is ... 18:52:55 ... we're nervous about hash functions for which malicious signer can create signature collisions ... 18:53:01 ... that's attack we're concerned with ... 18:53:26 ... randomness proposal makes this the same difficulty as the legitimate signer signing document, and attacker tries to do duplicate ... 18:53:44 ... how does this make anything more secure against malicious signers? ... 18:54:04 hugo: technique does not prevent legitimate signer from finding two messages that have same hash value ... 18:54:17 ... legitimate (not honest) signer could in principle find two messages that map to same hash value ... 18:54:26 ... can't be case if hash function is collision resistant .. 18:54:33 ... if it isn't, problem could in principle occur ... 18:54:48 ... if you receive message with signature, then signer is committed to that signature ... 18:55:01 ... (example) ... 18:56:12 ... point is: every message that has legitimate signature commits signer ... 18:56:41 ... note that hash function might be collision-resistant, but signature algo might not be ... 18:57:15 hal: attack is to get somebody to sign a document, and have that signature make something else 18:57:19 phb: ok, now i get it 18:57:28 ... more relevant to XML than certificate world ... 18:58:02 "not *any* randomness" backup slide 18:58:40 phb: what I can see as attractive here is -- once SHA3 discussions -- .... 18:59:01 ... instead of having standard compressor, have compressor, MAC, randomized digest all at once ... 18:59:04 ... with parameters ... 18:59:49 frederick: time! 19:00:13 hugo: re nist doc, it applies to any hash function 19:00:32 ... exactly like CBC and block cyphers ... 19:01:12 q? 19:01:48 mcIntosh on implementing it 19:02:04 ... implemented preprocessing as Transform 19:02:29 (occurs after c14n on slide) 19:07:50 http://www.w3.org/2007/xmlsec/ws/slides/08-lanz-iaik/ 19:08:54 hugo: rsa-pss doesn't solve same problem as previous randomization scheme ... 19:08:57 ... orthogonal problem ... 19:09:01 konrad: ack 19:14:16 second hash function in diagram for RSA-PSS 19:21:35 tlr: asks about unique urls for two different randomizations, yet could they be combined? 19:22:03 e.g. RSA-PSS vs Randomized hashing as described by Hugo 19:22:07 tlr: these are two different randomization schemes, they're orthogonal to each other, yet both affect the same URI space to be addressed 19:22:15 ... so the proposed integrations can't be integrated ... 19:22:25 konrad: ?? 19:22:30 hugo: streaming issue (?) 19:22:56 s/??/maybe can share randomness between two approaches/ 19:23:20 s/streaming issue (?)/want randomness in different places from ops perspective; streaming issue/ 19:27:20 sean: why did tls not adopt RSA-PSS 19:27:58 hugo: inertia, people also are staying with SHA-! versus SHA-256 19:29:27 phill: tls different in terms requirements it is meeting. Documents different than handshake reuqiremnets 19:30:10 konrad: moving defaults... 19:30:12 ... time for that 19:31:15 zakim, who is on the phone? 19:31:16 On the phone I see [Workshop], Ed_Simon 19:31:40 http://www.w3.org/2007/xmlsec/ws/slides/17-roddy-nsa/ 19:31:47 jeanine schmidt presenting. 19:32:41 jeanine: Crypto Suite B algorithms ... 19:32:45 ... regrets from Sandi ... 19:34:57 use of 1024 through 2010 by NIST, indicates potential key size growth issue 19:35:46 ecc offers benefits for key size and processing 19:36:33 looking for convergence of standards in suite B 19:37:02 NSA would like to see Suite B incorporated in XML Security 19:37:28 DoD requirements aligned with this 19:38:27 details could be worked out in collaboration 19:39:10 hugo: specifically saying key agreement is ECDH? 19:39:15 jeanine: yes, preliminarily 19:39:22 hugo: IP issue behind not talking about ECMQV? 19:39:31 jeanine: yeah, that's an issue ... 19:39:36 ... but ECDH might be more appropriate algorithm for XML ... 19:39:44 ... whether one or both is a question for future work ... 19:39:50 hugo: Can you make this analysis available? 19:40:08 jeanine: this is something that should be worked out betw w3c and nsa 19:40:12 ... preliminary recommendation ... 19:40:35 tlr: w3c would need to mean "community as a whole" 19:40:50 frederick: I hear "nsa could participate in WG"? 19:40:52 jeanine: yes 19:41:03 phb: ECC included with recent versions of Windows ... 19:41:10 ... doesn't believe they've licensed that from Certicom ... 19:41:16 ... given MS's caution in areas to do with IP ... 19:41:23 ... maybe ask them how they navigate this particular minefield ... 19:41:36 ... if there is a least encumbered version ... 19:41:45 ... then will follow the unencumbered path ... 19:41:56 hal: what is involved here in terms of spec? 19:42:02 jeanine: primarily identifiers 19:42:48 frederick: some unifying effort for identifiers might be needed 19:43:04 konrad: spirit of specs is to reuse identifiers 19:43:18 frederick: also recommended vs required 19:43:43 rfc 4050 has identifiers 19:43:46 sean: in RFC 4054, there's already identifiers for ECDSA with SHA-1 19:44:13 phb: keyprov would like to track down as many of algo ids as possible 19:44:26 ... if you have uncovered any (OIDs, URIs), please send a link 19:44:34 hal: start with gutmann's list 19:44:42 frederick: please share with xmlsec WG 19:44:50 http://www.faqs.org/rfcs/rfc4050.html has URIs for ECDSA-SHA1 19:45:01 frederick: what is next step for NSA at this point -- see what happens here? 19:45:05 jeanine: yes 19:45:38 lunch break; reconvene at 1:30 19:46:12 yes 19:46:28 reconvene: 1:45 20:06:39 -Ed_Simon 20:18:17 smullan has joined #xmlsec 20:45:12 +Ed_Simon 20:46:42 I am on the call. 20:47:54 scribe: sdw 20:48:13 are slides available online? 20:49:14 Must Implement 20:49:30 A-la-cart - Combinatorial explosion 20:50:08 Hidden Constraints: Often not any to any for implementations 20:51:33 http://www.w3.org/2007/xmlsec/ws/slides/02-baker-verisign/Overview.pdf 20:51:57 Thanks 20:51:58 Result: many variations to test, many configurations for analysis, deviation from specification 20:52:28 Proposal: Quantum Profiles 20:53:02 Unique URI for profile that fully specifies choices at each level. 20:55:46 Discrete options combinations, modes are more complicated. 20:59:09 Negotiation of specific combinations. 20:59:29 URIs that are intentionally opaque, not sub-parsed. 21:02:11 sdw: a possible analogy is font strings in X11 21:02:57 konrad: would be useful to have uri's that indicate strength (eg weakest key length) 21:02:59 Partial ordering of profiles may make sense, but might not be good. 21:03:58 smullan has joined #xmlsec 21:04:15 Meeting certain requirements, such as for a country, may be more of a private profile, possibly including country name, for instance. 21:04:42 Hugo: Are you making similar proposals in other groups such as IETF? 21:05:43 Phillip: This is something that I would like to take up in other groups. The problem with IETF is that we're dealing with protocols that already have slots for OIDs and it would be difficult to see how to go forward with ASN-based infrastructure and change. 21:06:21 Where picking profiles, CFIG and other groups would likely participate to define OIDs, etc. for certain coherent suites. 21:06:53 How is that approach applicable to signature? We are already in A-la-carte situation. 21:10:23 Presentation: The Importance of incorporating XAdES extensions into ongoing XML-Sig work 21:13:24 FrederickHirsch has joined #xmlsec 21:13:48 http://www.w3.org/2007/xmlsec/ws/slides/03-cruellas-etal/Overview.pdf 21:13:48 slides? 21:13:57 thanks 21:14:15 Agenda now has more slide pointers. . . 21:14:47 FH has joined #xmlsec 21:14:49 gpilz has joined #xmlsec 21:16:06 Defines XAdES forms that incorporates specific combinations of properties. 21:16:28 Agenda: http://www.w3.org/2007/xmlsec/ws/agenda.html 21:17:11 Use of these profiles allows much later use and auditing of signed data. 21:18:07 jcc slides http://www.w3.org/2007/xmlsec/ws/slides/03-cruellas-etal/ 21:21:02 Supports signer, verifier, and storage service. 21:23:46 Signature policy identifier references specific rules that are followed when generating and verifying signature. 21:24:00 Includes digest of policy document. 21:26:50 SignatureTimeStamp verifies that signature was performed earlier. 21:27:17 CompleteCertificateRefs has references to certificates in certpath that must be checked. 21:31:38 Has change been made to change countersignatures to include whole message rather than just original signature? 21:31:47 Don't believe that has been done yet. 21:34:24 Report in ETSI summarizes state of current cryptographic algorithms and makes certain recommendations. 21:35:40 Only minor changes to the standards are in process. 21:39:12 Can individuals use these signatures with the force of laws? 21:41:47 Depends on legal system: Rathole. 21:42:36 Thanks. 21:47:16 Presentation: XML Signature Performance and One-Pass Processing issues 21:47:30 klanz2 has joined #xmlsec 21:48:14 DOM provided good implementation but has performance issues 21:50:20 Event processing requires one or more passes. 21:51:12 Two passes, 1+, cache all elements with ID, or use profile-specific knowledge 21:56:04 Signature information needed before data vs. signature data etc. needed after data. 21:56:12 Can't do with current XML Signature standards. 21:57:38 XML DSig Streaming Impl.: STaX, JSR 105 API, exclusive C14N, forward references, enveloping signatures, Bas64 transform 21:58:28 sean: recommend best practices for streaming implementations 21:58:47 Apache project... 21:59:07 hal: integrity protecting data stream? 21:59:15 ... example is movie 22:00:09 ht: w3c xml pipelining language wg 22:01:00 q+ 22:01:08 q+ 22:02:22 ack FH 22:03:27 ack sdw 22:03:39 q? 22:04:21 steve: xml fragments are similar to streaming, but can sign/integrity protect fragments 22:04:34 s/similar to/can be used in/ 22:06:58 ScribeNick: ht 22:07:44 FH: The combination of streaming and signature is odd -- you can't release the beginning of the document until you've verified the signature at the end 22:07:54 pratik: streaming is for performance, rationale for doing it 22:08:14 one point I was making is that sometime you do not need integrity protection for streaming, e.g. in cases where it is ok to drop data 22:08:46 HT: Following on, it's precisely for that reason that not doing signature generation is at least odd, since in that case you surely can ship the beginning of the doc while still working on the signature 22:09:18 brad: +1 to pratik, value of streaming is performance 22:09:40 various: Dispute the relevance of signature to streaming XML and/or dispute the value of streaming at all 22:10:30 hal has joined #xmlsec 22:11:00 HT: Requirements on XML Pipeline to support streaming of simple XML operations, interesting to understand how to integrate some kind of integrity confirmation _while_ streaming XML 22:11:51 s/FH: The combination/?? The combination/ 22:12:08 jcc has joined #xmlsec 22:12:08 Audio seems to be dead. 22:12:30 yes i can, thanks 22:12:42 Streaming is important in memory constrained or bandwidth / processing constrained applications. 22:13:11 Yes, thanks. 22:14:17 RRSAgent, pointer 22:14:17 See http://www.w3.org/2007/09/25-xmlsec-irc#T22-14-17 22:15:24 scott: notes adoption in scripiting languages an issue, using c library not good enough 22:15:39 jeff: example is use of XMLSig is barrier to saml adoption in OpenID 22:18:16 peter gutman, "why xml security is broken" http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt 22:18:50 s/gutman/Gutmann/ 22:18:54 s/peter/Peter/ 22:19:51 Scott: Liberty Alliance worked at producing xml signature case that addresses many of the threats discussed. 22:20:02 s/case/usage/ 22:20:59 scott: need simpler way of conveying bare public keys 22:21:10 ... eg pem block 22:21:43 http://www.w3.org/2007/xmlsec/ws/slides/15-hodges-neustar/ 22:21:43 bhill has joined #xmlsec 22:22:29 scott: Retrieval method point to KeyInfo or child, issue with spec 22:26:03 simplesign - sign whole piece of xml as a blob 22:27:30 Ed: I agree with the above. If the XML is not going to be transformed by intermediate processes, one can just sign the XML as one does text. And use a detached signature. 22:28:17 have seen this approach successfully in use with XML in DRM and payment systems as well 22:28:30 What is needed is perhaps a packaging convention like ODF and OOXML use. 22:28:52 how is this different from PKCS7 detached? is it the embedding of the signature in the signed data? 22:30:19 I would have to review PKCS7 detached but I would say the idea is quite similar. 22:30:59 konrad: need XML Core to allow nesting of XML, e.g. no prolog etc 22:32:24 jeff: using for protocols is different use case than docs, sign before sending to receiver 22:33:20 q? 22:34:10 jimmy: how aboutnamespaces? 22:34:21 jeff: well, we don't care. 22:34:52 jimmy: has to be processed in context of original XML 22:35:09 mike: Why not PKCS#7 detached? 22:35:09 re: PKCS#7 - average Web-era developer doesn't like ASN.1 22:35:25 XML is successful and text wrangling is simple in any scripting language 22:35:37 cantor&hodges: this is for an as simple as possible use case 22:35:59 ... point is, people tend to back off from XML Signature in certain use cases ... 22:36:05 ... perhaps find a common way for the very simple cases ... 22:36:48 mike: well, there's a simple library, and then there's been 90% of the way to an XML Signature gone 22:37:05 sdw: want to emphasize that there are a number of different situations where you just simply want to encrypt a blob 22:37:07 ... or sign it ... 22:37:18 ... and be able to validate later without necessarily having complexity ... 22:37:26 ... not only protocol-like situations (WS being a good example) ... 22:37:42 ... but also in cases where you have sth that resembles more a traditional signed document ... 22:38:06 ... store in a database, that way, archival ... 22:39:30 scott: what may be needed to solve my problem is basically a lot more ID attributes than schema (?) 22:39:37 scott: more id atttributes in xml sig schema might be helpful 22:39:43 ... s/than schema (?)/than in the current schema/ 22:39:59 ... there is room for improvement here for the ID attributes ... 22:40:08 ... with more of these, a lot of referencing is likely to become possible ... 22:40:11 konrad: xml:id? 22:40:18 scott: might be a rationalization here 22:40:30 ... if I want to say "htis key is the same as that key", ... 22:40:40 ... looks like you need to reference keyInfo and then find the child with XPath ... 22:40:45 ... which seems to be a heck of a lot of work ... 22:41:34 konrad: historic context -- at the time, wary of using mechanisms, hence "reference + transform" element 22:41:52 Dinner: anyone coming back by SJC airport? 22:43:20 Dinner @ http://www.bucadibeppo.com/locations/location.aspx?location=0501 22:43:52 gpilz has joined #xmlsec 22:45:36 rragent, please make log public 22:45:38 RRSAgent, make logs world-visible 22:48:23 (unminuted discussion about xpath vs id attributes) 22:49:19 scott: standard minimal version of xpath? 22:49:25 ... preferably not implement the whole pile of work ... 22:49:38 ... all of this is begging the question: ... 22:49:45 ... ought to be standardized profiles for different problem domains ... 22:49:48 Ed: ID is simple, but flawed for apps. XPath can be complicated but applications, including XML Signature, can profile its use for specific uses. 22:50:19 +1 for minimal XPath 22:50:41 ... without standardized profiles for specific problem domains, a bit too much ... 22:50:55 What time do we resume? 22:51:15 We called our implementation of "Simplified XPath" Spath. 22:51:43 OK 22:51:44 sdw, is that publicly visible anywhere? 22:55:48 brich has joined #xmlsec 23:27:24 Not currently. 23:31:04 OK 23:33:49 I am interested. 23:34:48 topic: profiles summary 23:35:00 basic robust profile 23:35:05 klanz2 has joined #xmlsec 23:35:05 bulk signing - blob signing 23:35:11 use specific? 23:36:14 metadata driven implementation 23:36:20 brad - like policy 23:39:18 konrad: can this be done with / expressed as a schema? 23:40:29 FH: policy implies a general language vs. a hard/closed specification for a profile 23:41:05 tlr: difference between runtime and non-runtime profiles 23:41:07 I believe the next version of XML Signature and XML Encryption should have an attribute designating the profile. I have also pondered whether this should not even be in XML Core. 23:41:59 tlr: implementation time avoids unwanted complexity - teach how to do this with use case examples 23:42:54 scott: implementers want to build a general library and constrain behavior, rather than many implementations 23:44:01 phb: profile reuse: catalog, wiki 23:45:07 Pratik_ has joined #xmlsec 23:45:54 PratikDatta has joined #xmlsec 23:45:57 Pratik_ has left #xmlsec 23:46:24 michael leaventhal: robust is misleading, ease more important than flexibility, more performance and interop fundamentals over flexibility 23:47:53 jz (?): keep spec understandable and as short as possible 23:47:57 FrederickH has joined #xmlsec 23:51:02 brad: be able to limit total resource consumption even in languages like Java and .Net where platform services to limit low-level resource usage do not exist 23:51:20 konrad: some of these issues belong to Core, not just XML Security 23:51:54 fh: need to support scripting languages like Python 23:53:48 bhill: implementation guidelines to partition attack surface, order of operations 23:53:54 tlr: wrapping countermeasures 23:54:46 eric: possible to make it easier to verify than to sign? 23:56:20 konrad and jimmy: what is the scope/charter? 23:56:36 tlr: exploring interest, from profiling to deep refactoring 23:57:22 hiroki has joined #xmlsec 23:58:28 fh: how to really do see what you sign? 23:59:37 topic: referencing model