XML Security Specifications Maintenance WG Conference Call
9 Nov 2007


See also: IRC log


Frederick Hirsch, Thomas Roessler, Hal Lockhart, Sean Mullan, Phill Hallam-Baker, Pratik Datta, Rob Miller, Ed Simon, Prateek Mishra, Juan Carlos Cruellas, Bruce Rich
Eric Cohen, Donald Eastlake, John Kemp, Michael McIntosh, Amit Parashar, Bede McCall, Graham Rong
Frederick Hirsch
hal, pdatta


action items

<klanz2> action 98 overthrown by events ...

ACTION-71 open

ACTION-74 open

ACTION-81 closed

<klanz2> re action 108 there is a need to change the RFC3986 algo so that join-uri-reference(" no/", "../") will result in "" for all inputs that joins relative uri references and results in removing all non ".." segements by means of ".."

ACTION-93 definitely closed

ACTION-109 & ACTION-114 are successors to 93

ACTION-99 closed

<fjh> no issues found

ACTION-103 closed

ACTION-105 open

ACTION-106 closed

ACTION-107 open

ACTION-108 closed

<fjh> "The URI attribute identifies a data object using a URI Reference

<fjh> [URI]. The mapping from this attribute's value to a URI reference

<fjh> MUST be performed as specified in part 2, section 3.2.7 of

xml signature section

<fjh> [XMLSCHEMA]. Additionally: Some existing implementations are known to

<fjh> verify the value of the URI attribute against the grammar in [URI].

<fjh> It is therefore safest to perform any necessary escaping while

<fjh> generating the URI attribute."

<fjh> using a string interpreted as a URI reference

klanz: should say "using a string as a URI reference"

<fjh> 1st sentence update

konrad: concern that 1st sentence is too constraining

<klanz2> maybe s/URI attribute/the reference model/

hal: should be able to get sense of text w/o reference to another document

<klanz2> "The reference model identifies a data object using a URI Reference

<klanz2> [URI]. The mapping from this attribute's value to a URI reference

<klanz2> MUST be performed as specified in part 2, section 3.2.7 of

<klanz2> [XMLSCHEMA]. Additionally: Some existing implementations are known to

<klanz2> verify the value of the URI attribute against the grammar in [URI].

<klanz2> It is therefore safest to perform any necessary escaping while

<klanz2> generating the URI attribute."

<fjh> rec text at http://www.w3.org/TR/xmldsig-core/#sec-URI

<MikeMcIntosh> I can hear that he is speaking but not understandable

<MikeMcIntosh> I understand Hal and Frederick - but not Thomas

<jcc> 3.2.17

<fjh> This proposed text replaces text in from "The URI attribute identifies" through "able to parse URI syntax"

jcc: reference should be to 3.2.17 not 3.2.7

tlr: should not use sections numbers - apparently not stable

tlr: use titles of sections + links

<tlr> http://w3.org/2007/xmlsec/drafts/xmldsig-core

<tlr> -1 to Konrad's change

<klanz2> reason?

<tlr> 1. Reference model is more than just the URI attribute

<tlr> (as hal just said)

<EdS> http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-URI-reference

<klanz2> well, there is a change going on towards LEIRI and HRRI ....

<fjh> tlr: goal is to enable adoption of IRIs

<klanz2> http://tools.ietf.org/html/draft-duerst-iri-bis-01#section-7

<klanz2> http://tools.ietf.org/html/draft-walsh-tobin-hrri-01

<deastlak> http://www.ietf.org/internet-drafts/draft-duerst-iri-bis-01.txt ?

<klanz2> some more reading on this topic: http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Nov/0007.html

<deastlak> Existing RFC ftp://ftp.rfc-editor.org/in-notes/rfc3987.txt

hal: konrad noted that xml core noted that an inappropriate value in a URI attribute value is a user error

<fjh> schema aware c14n not in current scope

<tlr> fyi, Exi is ready for us

<pdatta> we are not doing any URI escaping either. 99% of the URIs that we deal with are in document references

RESOLUTION: accept proposed text with correct section #

<pdatta> for in document references, there is no escaping required

<pdatta> and out of document references (i.e. file system, external web servers) are risky

<klanz2> http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Nov/0016.html

<klanz2> System identifiers (and other XML strings meant to be used

<klanz2> as URI references) are LEIRIs [ref]. Failure to match the

<klanz2> applicable syntax productions of [LEIRI] is not an error.

<klanz2> Note, however, system identifiers which do not conform to

<klanz2> LEIRIs are not in practice likely to be useful.

<klanz2> well, this is just for system identifiers

Joint session with EXI WG

See also: EXI WG minutes

<fjh> slides here http://lists.w3.org/Archives/Public/public-exi/2007Nov/

<fjh> EXI overview slides and Santiago's slides

<klanz2> http://lists.w3.org/Archives/Public/public-exi/2007Nov/att-0001/EXIandXMLSec.pdf

<fjh> EXI overview slides http://lists.w3.org/Archives/Public/public-exi/2007Nov/0002.html

<fjh> EXI and XMLSec slides http://lists.w3.org/Archives/Public/public-exi/2007Nov/0001.html

<fjh> exi bases compression techniques on knowlege of general XML infoset, possibly schema, possibly detecting repeats

<fjh> also has some special techniques

hal: which processing is being optimized (what is faster)

<MikeMcIntosh> I think its an old phone - Frederick can you donate something designed after 1970?

<fjh> exi best practices doc describes use of xml sec with exi

<fjh> noted that infoset transform view is of changes to xml, even though sig etc is octet based for digesting

<fjh> exi process: perform all xml security, then exi encode, then exi decode, then xml sec processing

<fjh> benefits of exi not apparent with this approach...

<fjh> apart from on the wire space benefit

phb: questionn of inefficiency, 2 serializations

<fjh> discussion of whether only one parsing is required

phb: issue of signed SOAP message in addition to documents

phb: need new packaging a la p7
... order

<klanz2> link, please?

<fjh> http://www.w3.org/TR/exi/#fidelityOptions

<fjh> these options allow exi to preserve items that matter for signatures, e.g. not lose comments inappropriately

<fjh> preserve comments, PIs, DTD, prefixes, lexicalValues

<fjh> need to verify what is in preserve and relationship to C14N

<klanz2> I'll check

<fjh> tlr did, you are correct, PIs not ignored

<fjh> summary: verify that preserve items in exi are correct with respect to C14N11

<fjh> e.g. PIs, comments preserved, prefixes preserved

<fjh> DTDs

<klanz2> What I would be interested in if they are sensitive to the loction of namespace declarations

<fjh> lexicalForm of element and attribute values, e.g. conversion of values such as 01 to 1 for integer, to give one example, is prevented if preserve set

<klanz2> well C14n probably cares more about what is in the input node set

ed: essentially have to profile exi to be less efficient when using xml security
.. schema aware c14n would allow option in exi for lexicalForm preservation

<klanz2> or define modes that are exi proof

phb: define which preserve options used based on scenarios, e.g. schema avialallable

<fjh> talking about using exi as canonicalizations step

<fjh> note - continuing into break

<fjh> suggestion - canonical EXI as canonical xml

<fjh> also suggestion in slides - use type in xml encryption, need to note encoding, possible need for additional information for encoding/mime type

frederick: question of using exi as canonicalization alg, then can still have xml with digest values based on exi

phb: q regarding chunking, also notes lexicalForm consistency can be of value to apps

<fjh> discussion re xml adjacent text nodes in xml serialized as one, part of chunking discussion

phb: concern is being able to process stream canonicalization with small chucnks at a time

<fjh> issue of parallism

<fjh> exi really talking 80-20 focus

phillipe: need canonicalization uri for each preservation choice in conjunction with exi

<fjh> discussion of whether exi header useful, not in this case, need explicit uri

<klanz2> what about memory footprint?

<klanz2> is there an in memory DOM or XPathDataModel of EXI possible, that expands values when they are read?

<fjh> any questions from the phone ;)?

phb: probably want to use exi when using both xml enc and sig, since enc is binary anyway

<fjh> next steps for exi and xmlsec

<fjh> 1. xmlsec wg should review exi material, note if any issues or misunderstandings with current xml sec

<fjh> 2. outline areas that could be requirements to chartering

konrad: can we streamline xml security processes
... does exi have capability to work with random acess to stream

john schneider yes areas exi could be used, one is canonicalization as faster canonical form

konrad: how to have multiple transforms, how would this work

js: probably not for such transformations
.... due to internal memory model
... exi may have material in final spec, not current spec - indexability
... ability to jump to point in stream, e.g page in large PDF

klanz: xpath filters, xslt transforms need to be constrained to parent context,then would exi help

js: not sure, need to understand parent context

santiago: all in-memory processing, so exi might not help

<fjh> we are going to take 1/2 hour break, until 11:30 eastern

Review of EXI discussion

Fhirsch: 2 goals for EXI - a) see if what they are doing is correct

<pdatta> Ed and Hal are interested in delving into EXI

hal: we should verify if EXI really works as claimed or they break anything

klanz: can we submit test case to exi?

konrad: we should check their testcases, give new testcases

<EdS> EXI Testing Framework: http://www.w3.org/XML/EXI/#TestingFramework

fhirsch: do we have a date for when EXI needs our input?

phil: interested in combination of SOAP, EXI and XML Sig, Encr

<fjh> issue - reviewing exi for consistency with current xml signature

tlr: EXI originally planning to have last call in December...
... would like review comments before last call ...

<fjh> ACTION: jcc to review EXI with respect to correct XML Security usage [recorded in http://www.w3.org/2007/11/09-xmlsec-minutes.html#action01]

<trackbot-ng> Created ACTION-115 - Review EXI with respect to correct XML Security usage [on Juan Carlos Cruellas - due 2007-11-16].

<tlr> http://www.w3.org/TR/2007/WD-exi-20070716/

<fjh> need to update tracker to change date to 10 December 2007

<EdS> Ed and Phill discussed the use of profiles to limit schema variances. Ed mentioned the potential of using the proposed signature element @Profile attribute (see Ed's strawman proposal). Phill said that he felt specs should be designed to precisely define allowed values (e.g. no '+' signs on integers even though XML Schema would say '+10' and '10' are equivalent; ideally limitation of variances would be specified in the protocol.

fhirsch: discussion about posting interop results

fhirsch: we decided yesterday that we will ask xml core if it is ok to change examples to use xml:id, and if so generate test cases and interop wih them

fhirsch: all interop participants are set, everything is checked into CVS, all that needs to be done is to update the test cases if required, and generate a test report

<klanz2> cu later

<EdS> test

charter discussion

<tlr> http://www.w3.org/2007/xmlsec/wiki/charter

fhirsch: whether we should xkms

prateek: is this for a completely new version of XML Sig

fhirsch: create a simplified profile

hal: goal to address requirements

tlr: need to consider profiles, extension points, possible new work

pratik: adoption requirement of minimal changes

pratik: we need some profiling which can be subsetting with complete backwards compatibility, and this will be easily adoptable by maintainence releases of higher level standards - WSS , SAML etc

sean: can charter be changed later

tlr: process more involved. Narrow helps chair keep work on target, broad enables more work

sean: short term and long term work
... can have different deliverables for phases?

tlr: yes

fhisrch: should not have two parallel groups - one in maintainence one if future.
... preference to have only one group, not two (e.g. maintance and new work in single group) ...

<fjh> +1 from hal and tlr

<fjh> charter will include deliverable of gap analsis and requirements etc,

<fjh> draft charter http://www.w3.org/2007/xmlsec/wiki/charter

tlr: draft charter has very little requirements work

tlr: draft charter does have slight maintainence work, bug fixed, encryption work

tlr: need more input on profiles and optional features

hal: if EXI doesn't reach rec, roadmap is not necessary

tlr: XML Signature should not have strong dependency on EXI

<EdS> EXI Timeline: http://www.w3.org/XML/EXI/#timeline

ed: xml sig was 2 years

Ed: XML Signature started off in mid-1999 and finished in 2002 February.

pratik: might not be bad if takes a while for REC if it breaks compatibility

hal: there are old signatures which cannot be regenerated, so if we break compatibility those cannot be verified

tlr: eg could incorporate exclusive c14n into deliverables

hal: we should break compatibility once, because we could have made mistakes in 1.0, but can't break compatibility again and again

tlr: consider all deliverables of sig and enc to be allowed for maintenance in charter

ed: need something for SignedInfo, perhaps not c14N, e.g. Eds proposal

ed: there are signature applications that do not canonicalize XML

klanz2: sometimes treat XML as binary sometimes need to C14N XML

ed: e.g. microsoft Word

<fjh> reasons for c14n, requiments etc - new wg question

tlr: chartering questions - need to constrain requirements work,
... need to include simple use cases
.... second pt - where to address, new c14n that works with old/new, or changes to both sig and c14n
... clarify deliverables

<EdS> +1 to tlr

hal: should not be restricted to not modify xml signature

phil: if we refactor signature then perahps not need complex mechanisms (e.g. if portions external

phil: how do you make c14n unncessary, transforms are complicated

<fjh> klanz possible requirement - new signature would also alllow old verifiers

<PHB> C14N is necessary because we have transforms, if we find ways to avoid the need to do transforms we avoid the need for C14N

<EdS> My guess is that requiring that new signatures could be refactored as old signatures that still verify is too restrictive.

fhirsch: what are requirements of a charter- should the charter should say just make it better, or put more hard constraints
... on what can be changed and what needs to be fixed

<klanz2> -1 phb

<klanz2> what about all the depending existing standards in ETSI and OASIS already using DSIG

<EdS> +1 to Phill (sorry Konrad!)

<klanz2> they need improvements

<PHB> they need improvements for particular use cases

<PHB> Does Konrad have a use case that is not being addressed?

phil: break up the problem into XML Sig for Web service, and XML Sig for documents

<klanz2> stream sign and verify current xml signatures

<klanz2> well and XMLDSig is all about End-to-End security and documents less about point to point security even in relayed SOAP etc. applications

phil: One approach - list scenarios to be treated independently and then classes of requirement for all...
... e.g. web svcs and static documents, perhaps also dss-x like signing ...
... then robustness, performance/streaming etc ...

eds: structural integrity, issues with referencing fragments

prateek: web services and static docs should be just examples

prateek: consider areas as *examples* not require in charter

tlr: WAF is talking about signing package contents...
... add WAF to charter as related work ...

tlr: use workshop results to list work to be included in chartering

hal: put more requirements into charter

<fjh> Changes to charter draft:

<fjh> add requirements deliverable after scope, including examples, use cases from workshop

tlr: abstract away from Reference/Transform, refer to "model", or details?

klanz: take problem based approach, list problems?

<fjh> that is requirements

hal: we must at first agree upon the requirements

<hal> I believe all reqs we should worry about have been raised in workshop of sec maint wg

hal: meet agreed requirements while considering backward compatibility...
... should not lightly remove backward compatability...

<hal> I believe some current reqs are mutually exclusive and we will have to pick an alternative

<fjh> constraints - not change meaning of existing signatures

<fjh> discussed whether v.next can have a profile that doesn't break existing signatures

<fjh> single pass processing makes this unlikely

<klanz2> we can have preprocessing that makes single pass processing signatures look like v1.0 signatures

<klanz2> otherwise they are streamable ...

<fjh> Consider a creating a new profile that is backward compatible withe existing signatures

<tlr> Future development can take form of profile or revised specification. Group is asked to consider the benefits of compatibility with existing specification environment.

brich: tony looking for maximal set of use cases where canonicalization is unnecessary
... eg using a tool to determine

<EdS> One often has to consider business processes, present and potential, when determining whether canonicalization can be bypassed or not; not sure how a WG tool could do that.

<fjh> use of redundant information could allow a streaming approach to work with existing implementations yet also allow new implmenetations

tlr: don't know yet, so charter shouldn't constrain

<EdS> I would like to see an example of how one can write the signature value before one has seen the object (as in eveloped objects).

klanz: cms might be approach to minimalize use of canonicalziation

<tlr> eds, multipart/signed enables both one-pass verification and generation, by having redundant information about the hash algorithm and canonicalization

hal: canonicalization maximizes changes of interoperability with minimum work

<tlr> eds, I didn't mean "multipart verification", but "one-pass verification" bove

pratik: in use case from ws-security you can load up signature and then stream body etc for processing, no need to change signature itself for streaming

<EdS> Just to clarify, I was NOT saying that single-pass processing is always impossible with v1.0; but that it is not always possible.

<EdS> In my strawman proposal, single-pass processing is always possible.

<EdS> To clarify, I am speaking of enveloped objects (enveloping signatures).

<klanz2> +1 to DOM bad

<fjh> enable event based processing

<klanz2> +1 SAX

klanz: how can WS security sig generate be 1 pass, because the signature is before the body

pdatta: 1 pass is not the goal. the goal is to be faster and use less memory, we can construct the WS packet in two parts and then prepend the header to the body

pdatta: need to avoid loading up the whole body into DOM

tlr: also consider business decisions, if we completely make it based on engineering decision, then implementors may not adopt it

Frederick: It can also be a bad business decision NOT to make breaking changes.

sean: it might take upto 10 years for all the higher level stacks to catch up and implement new xml sig

<deastlak> it worked

<klanz2> http://www.w3.org/2007/xmlsec/wiki/charter#head-f5aae59d37ff7b2f292c53f39255c9bacf4985f7

<klanz2> with the exception of namespace undeclarations

<klanz2> What about XPath data model vs Infoset for transforms and canonicalization?

<fjh> http://www.w3.org/2007/xmlsec/wiki/charter

sean: what is value of having a separate document on implementation requirement

klanz: consider strategies for defining new algorithms and parameters

donald: new sha-3 coming

ed: algorithms change more rapidly than xml signature, so better to have a separate document

<fjh> we can add sentence: "The WG can decide how to structure its deliverables and may consider re-organizing XML Signature from earlier versions."

sean: argument against separate document. can't say we support xml signature. need to say we support these algorithms

<fjh> Proposal ACTION; deastlak Review W3C pages for outdated xml security

donald: will review the dsig and encryption home pages for archaic information

<fjh> ACTION: Frederick to remind Donald to review XML Signature and Encryption home pages for accuracy [recorded in http://www.w3.org/2007/11/09-xmlsec-minutes.html#action02]

<trackbot-ng> Created ACTION-116 - Remind Donald to review XML Signature and Encryption home pages for accuracy [on Frederick Hirsch - due 2007-11-16].

<klanz2> ;-)

hal: add Decrption Transform

<fjh> rfc 4051 earlier draft

<tlr> http://lists.w3.org/Archives/Public/www-archive/2007Oct/0058.html

<tlr> (This is the public record of XML Core's current plan with XML 1.1.)

konrad: concern XPath 1.0 data model does not handle XML 1.1

tlr: can be addressed by core if issue if xml 1.0 updated with relaxation of element and attribute names

<fjh> close ACTION-71

<fjh> was previously closed

<fjh> action 98 should be closed

<fjh> action 107 closed

<fjh> comment on redline before Wed when fjh to send to xml core

<tlr> Next meeting 27 November.

<tlr> adjourned

Summary of Action Items

[NEW] ACTION: Frederick to remind Donald to review XML Signature and Encryption home pages for accuracy [recorded in http://www.w3.org/2007/11/09-xmlsec-minutes.html#action02]
[NEW] ACTION: jcc to review EXI with respect to correct XML Security usage [recorded in http://www.w3.org/2007/11/09-xmlsec-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/11/27 15:19:15 $