See also: IRC log
<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
<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 4.3.3.1 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
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
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
<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