XML Security Specifications Maintenance Working Group Teleconference -- 8 Nov 2007

Convene

<fjh> draft minutes from last meeting http://lists.w3.org/Archives/Member/member-xmlsec-maintwg/2007Oct/att-0032/2007-10-30-xmlsec-minutes.html

The minutes were not approved because they contain some confidential information.

XML Core

<fjh> minutes from xml core http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Nov/0002.html

<fjh> red line http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Nov/0003.html

Frederick reviewed the outcomes of XML Core C14N11 discussion that was held on Tuesday.

<Frederick> XML Core discussion on Tuesday included clarification of XML Base and Appendix A issues.

<klanz2> dialing in ...

Frederick reviewed the "red line".

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Nov/att-0003/c14n11-2-4-redline-v2.pdf

<fjh> agenda http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Oct/0023.html

klanz2 joined on Zakim.

tlr: Append a '/' character to a trailing ".." <ins>segment</ins

<fjh> proposal add "segment" to the end of "Append a “/” character to a trailing “..” "

konrad: not sure whether .. elimination on a relative uri reference might lead to a "/", which would be wrong

<klanz2> no/../ may result in a slash, but I'll double check

<klanz2> in RFC 3986

<tlr> ACTION: klanz2 to double-check on relative-to-absolute resolution [recorded in http://www.w3.org/2007/11/08-xmlsec-minutes.html#action01]

<trackbot-ng> Created ACTION-108 - Double-check on relative-to-absolute resolution [on Konrad Lanz - due 2007-11-15].

<klanz2> the test cases are also in the latest version of the to be removed Appendix

Issue raised in xml core joint meeting

<fjh> Consider this example

<klanz2> The test cases from there http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/att-0044/Apendix.html will remain in the spec wouldn't they ...

<fjh> now consider removing elements b and c

<fjh> incorrect result would be "../x"

<fjh> due to left hand side algorithm

<fjh> should get ../../x

<klanz2> http://tools.ietf.org/html/rfc3986#page-33

<fjh> section 5.2.3

<klanz2> That's what I previously said about this http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0044.html

<klanz2> Further in the concourse of these initial tests I also found a potential

<klanz2> ambiguity in the merge_path function in rfc3986

<klanz2> http://tools.ietf.org/html/rfc3986#section-5.2.3

<klanz2> Which says: " i.e., excluding any characters after the right-most "/" in

<klanz2> the base URI path"

<klanz2> However I don't think this applies if a base URI has two trailing dots

<klanz2> (assuming the optional normalization mentioned in the second paragraph

<klanz2> of http://tools.ietf.org/html/rfc3986#section-5.2.1 was not performed).

<klanz2> So I'm unsure what would happen to an inherited xml:base URI reference

<klanz2> of the form "../.." to be joined with a URI reference of the form "..".

<klanz2> For the least surprising output I would bet on "../../../" as an output

<klanz2> and I think this would also deserve a mention in section 2.4 of C14n 1.1 .

<fjh> from 5.2.3 return a string consisting of the reference's path component

<fjh> appended to all but the last segment of the base URI's path (i.e.,

<fjh> excluding any characters after the right-most "/" in the base URI

<fjh> path, or excluding the entire base URI path if it does not contain

<fjh> any "/" characters).

tlr: This is not an Appendix A problem.

<klanz2> we could also say that trailing .. will be replaced with ../

<klanz2> before processing

<fjh> Add bullet to join-URI-References text "Replace a trailing .. with ../ before processing"

<tlr> Replace a trailing ".." segment with "../" before processing.

<klanz2> no/../

klanz2: If all segments get removed from other .. segments the trailing / must be removed as well.

<fjh> If all segments are removed through .. segment processing, any lone / must be removed as well

<fjh> Three suggested changes

<fjh> 1 Append a '/' character to a trailing ".." <ins>segment</ins

<fjh> 2. insert Add bullet to join-URI-References text "Replace a trailing ..sgment with "../" before processing

<fjh> 3. Add If all segments get removed from other .. segments the trailing / must be removed as well.

<klanz2> join-uri-reference("no/", "../") := ""

<klanz2> and not "/"

tlr: If the path component of both inputs are not absolute then the result should not be absolute.

<klanz2> join-uri-reference("no/", "/") ="/"

<fjh> if path component of both not absolute (e.g. not start with /) then result is not absolute (e.g. no /)

<klanz2> join-uri-reference("no/", "/") :="/"

<klanz2> join-uri-reference("{whatever}", "/{whatever2}") :="/{whatever2}"

<klanz2> I still understand why we would have to this all again

<klanz2> just for the new algorithm

<klanz2> well lets make just the test cases normative

<klanz2> and put the algorithm informative

<tlr> The algorithm is modified to ensure that a combination of two xml:base attribute values that include relative path components (i.e., path components that do not begin with a '/' character) results in an attribute value that is a relative path component.

<klanz2> I still follow the opinion is that the problem is and was sticking to rfc 3986 remove dot function

thomas: add example + language I put in chat

<klanz2> examples are always good +1

<pdatta> I think refering to RFC3986 and putting modifications on it, is a bad idea

<klanz2> +1 to pdatta

<pdatta> because RFC3986 is very complicated

<klanz2> uneccesarily complicated

<klanz2> http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Oct/0024.html and the algorithm by bruce

<klanz2> we should just ask them if they give c14n 1.1 to us

<klanz2> and they offerded that may times in the past

<pdatta> a more intuitive algorithm is one that splits up the path into segments with / delimiter. and then use a stack to push the segments in. And a dot dot will pop segments

<klanz2> http://tools.ietf.org/html/rfc3986#page-34 :

<klanz2> Some applications may find it more efficient to implement the

<klanz2> remove_dot_segments algorithm by using two segment stacks rather than

<klanz2> strings.

<klanz2> We actually need just one stack ;-)

<klanz2> Didn't hear that ;-)

<klanz2> what was it

<tlr> ACTION: tlr to provide example for "isolated .." case [recorded in http://www.w3.org/2007/11/08-xmlsec-minutes.html#action02]

<trackbot-ng> Created ACTION-109 - Provide example for \"isolated ..\" case [on Thomas Roessler - due 2007-11-15].

<klanz2> btw. regrets from jcc, he will join tomorrow morning ...

<fjh> ACTION: frederick update redline and share with xml:core [recorded in http://www.w3.org/2007/11/08-xmlsec-minutes.html#action03]

<trackbot-ng> Created ACTION-110 - Update redline and share with xml:core [on Frederick Hirsch - due 2007-11-15].

Interop Status

<tlr> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Oct/0038.html

<klanz2> sean please speak up, ...

<tlr> Sean describing above message

<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Oct/0039.html

<fjh> konrad - be consistent between spec and test cases

<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Oct/0040.html

sean: Is it too late to change c14n 1.1?

Frederick: I think we should do it.

RESOLUTION: Update c14n 1.1 spec example 3.8 and also rerun interop test cases accordingly.

<tlr> ACTION: Frederick to review examples in C14N 1.1 and propose detailed changes to use xml:Id [recorded in http://www.w3.org/2007/11/08-xmlsec-minutes.html#action04]

<trackbot-ng> Created ACTION-111 - Review examples in C14N 1.1 and propose detailed changes to use xml:Id [on Frederick Hirsch - due 2007-11-15].

Interop report status

<tlr> ACTION: tlr to prepare interop report template [recorded in http://www.w3.org/2007/11/08-xmlsec-minutes.html#action05]

<trackbot-ng> Created ACTION-112 - Prepare interop report template [on Thomas Roessler - due 2007-11-15].

<tlr> ACTION: sean to update testcase document [recorded in http://www.w3.org/2007/11/08-xmlsec-minutes.html#action06]

<trackbot-ng> Created ACTION-113 - Update testcase document [on Sean Mullan - due 2007-11-15].

<klanz2> ok

<tlr> ACTION: tlr to ensure that result from ACTION-109 goes into test suite [recorded in http://www.w3.org/2007/11/08-xmlsec-minutes.html#action07]

<trackbot-ng> Created ACTION-114 - Ensure that result from ACTION-109 goes into test suite [on Thomas Roessler - due 2007-11-15].

<tlr> http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/explain.html

Graham Rong from MIT/Sloan entered the meeting.

<fjh> interop to do: verify that all implementations are now up to date and checked in, verify test caes doc is up to date, run test for xml:id once accpeted by xml core, run new test for .. processing

<fjh> report generation

<klanz2> Seen your mail, thanks ...

<fjh> Donald mentioned RFC 4051

<klanz2> thomas talked in Mountainview about a registry maechanism ...

<fjh> informational RFC

On Break 3:06pm to 3:30pm

XBRL Requirements

Eric E Cohen presents; slides: http://www.w3.org/2007/xmlsec/f2f-2007-11-08/XBRLintro71108.pdf

<klanz2> http://www.oasis-open.org/apps/org/workgroup/dss-x/download.php/25700/proposal-visible-signatures-v1.1.pdf

<fjh> semantics of signatures important

hal: What do "different syntaxes" mean?

discussion around policies, semantics.

cohen: as much interoperability as possible

ed, frederick: signatures have to adhere to policies

ed: can xacml be used for specifying these kinds of policies?

how to reconcile XML Signature syntax with XBRL syntax?

<klanz2> yes

<klanz2> not very good

<klanz2> I can hear Ed fine

<klanz2> I could infer from the slides what it was about ...

<klanz2> a lot better

<fjh> www.sec.gov

FJH: sign what you see?!

ecohen: content not limited to presentation
... in Sweden, they have a standard rendering based solution ...
... throwing away the machine-readable structure in turn ...

fjh: make the report a first-class object?

ecohen: does it have to have a visual representation?

EdS: Check out my whitepaper for mountain view
... might be relevant for your canonicalization use case ...

eric: "what you see is what you sign" model doesn't really work these days

<fjh> tlr: XBRL canonicalization - canonical XML with differences, definition?

<klanz2> tlr, please speak up

tlr: what's XBRL canonicalization?

ecohen: what we need

<klanz2> works again

<rdm> Bede McCall of MITRE entered the meeting.

<klanz2> order is important in XML ....

(discussion about reordering)

<klanz2> use XSLT sort

<klanz2> to sort elements

ecohen: XBRL can live with reordering
... more losely defined, since some relations defined elsewhere ...

hal: careful about semantics of order

<klanz2> if elment order doesn't matter, just sort it ...

ed: sign structure?

hal: signature software has no idea what semantics is
... run risk of basically signing something that can't be modified, but moved ...
... so it's good news that order doesn't matter, since that makes stuff more robust ...
... also, what's lifecycle?

eric: there's a workflow business requirement here

hal: layer processing might break for signature

<klanz2> thanks for the insights, looks like you need some research on this ...

fjh: What do we get out of this?

<klanz2> fjh, could you please turn the mic sensitivity higher ...

tlr: known gaps?

<klanz2> ok

hal: support for profiles -- not very desirable to have 27 different ways to do the signature

<klanz2> does some one have this as pdf, can't read odp ...

hal: would rather have a superset document than a lot of individual profiles ...

<klanz2> thx, use old one in the mean time ...

<Donald3> http://bits.blogs.nytimes.com/2007/11/08/bring-this-to-the-next-meeting/index.html?hp

Signature 2.0 strawman (Ed Simon)

ed: single-pass validation and creation

etc

<fjh> pdf http://www.w3.org/2007/xmlsec/f2f-2007-11-08/XML-Signature-Proposal-2.pdf

<fjh> ed: use SAML assertions to specify signer identity...

<fjh> SAML subject element.

<fjh> (correction)

<fjh> support multiple signers for single SignedInfo

<klanz2> I'm not sure this will all fit into the core, btw. we may want to concentrate on staying as close as possible to the current spec ... yet still enable better streaming ... and extend in places where signature can be extended anyway

<klanz2> cf. ConterSignature in XAdES ...

<tlr> which you could do using the current infrastructure, except for the semantics part

<klanz2> we can put additional semantic stuff into ds:Object s

<klanz2> CounterSignature, vs. Parallell Signatures

<klanz2> let's not mix things here

<fjh> konrad: use extension points in current spec where we can

<klanz2> re: CounterSignatures http://webapp.etsi.org/action/PU/20060307/ts_101903v010302p.pdf#page=35

<klanz2> http://webapp.etsi.org/action/PU/20060307/ts_101903v010302p.pdf#page=61

<fjh> discussion need XML C14N for xml, text canonicalization for text, none for binary

<klanz2> Multiple signatures and countersignatures

<klanz2> the ref above

<fjh> proposal - define in XML Signature how to reliably hash SignedInfo without talking about canonicalization in general

<klanz2> one thing really tricky about SignedInfo is indention and whitespace and that there is no transforms allowing to heal differences in parsing and so on ...

<klanz2> Re streaming, for enveloping signatures we can do something easily putting ds:Object just before the digest value ... for enveloped signatures we have to be more creative ... like factoring DigestMethod and Transforms outside the signature

<klanz2> maybe using xi:Include

<klanz2> just brainstorming

frederick: note we might want to use different word for different concept despite namespaces due to people's understanding, e.g. ds:Object vs proposed Object to embedd or include references
... question - is nesting profiles adding run time complexity to processing, perhaps only allow single profile

tlr: could wrap current signature element with new element with profile attribute vs defining new attribute on signature element

pratik: we should explore approach of using existing Signature 1.0 where we can

hal: real backward compatibility requires same signature value, probably not likely if we fix stuff

hal: dislike namespace profiles, agree with rich

<klanz2> Thats what 1.0 looks like (*where we may want to make additions*, changes #):

<klanz2> (<Transforms>)? # use xi:include to including the transforms positioned at the beginning of the document

<klanz2> <DigestMethod> # use xi:include to including the DigestMethod positioned at the beginning of the document

<klanz2> (*add <ds:Object> here to stream it*)

<klanz2> </Reference>)+

<klanz2> (<KeyInfo>)?

<klanz2> (<Object ID?>)*

<klanz2> such additions and changes would allow new processors to read old signatures

<klanz2> and old processors could x:include first and then verify / doesn't work for a new ds:Object

<fjh> sean: great presentation, agree with Konrad and Pratik re building on existing spec

<fjh> konrad: streaming issue is conflicting needs for signing and verifying with current spec

<fjh> konrad: at beginning, specify DigestMethod and transforms, at end values, ease streaming

<fjh> ed correct presentation, digest ahead of object

<fjh> hal: streaming has issue of node sets vs infoset

<klanz2> navigational commands in XPATH

<klanz2> allowing to go in reverse document order

<fjh> which XPath?

<klanz2> in transforms

<fjh> Thank you to Eric and Ed for excellent presentations.

<klanz2> what we'd need here is that transforms depend on their ancestor context only

<klanz2> re to what hal said

<klanz2> re to what hal said also, transforms should be decoupled as if they had documents in between ...

<klanz2> Hal, that should cover most of whatr I recall

<klanz2> I may have more readable versions of this stuff in a single document availiable by christmas time

<klanz2> thanks everyone, just had to type this rest not to forget ...

<klanz2> bye bye

XML Security Specifications Maintenance Working Group Teleconference

8 Nov 2007

Attendees

Contents