IRC log of xmlsec on 2007-09-25

Timestamps are in UTC.

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