XML Security Spec Maint WG face-to-face

Administrative

<Ed> Yes, Ed is Ed Simon

<fjh> Members of the group introduced themselves

Approval of 2007-04-17 telecon minutes

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

RESOLUTION: 2007-04-17 telecon minutes approved

Teleconference schedule

fjh: weekly Tuesdays 9-10 am Eastern, 6-7 am PT, 3pm
... European
... no call next week

F2F plans

fjh: will want to do a workshop at some point to solicit additional input for future work
... also Joint Technical Plenary and AC Meetings Week, 5-10 November 2007, Cambridge MA

tlr: first two days working meetings, third day plenary, followed by more working meetings
... we could plan on 1.5 days thu-fri

fjh: need a decision this week
... this group chartered through the end of the year. ideally our work is done by november

<tlr> http://www.w3.org/2002/09/wbs/34786/TPAC07/

tlr: one of the outputs of this group will be a proposal for a charter for continued work
... in preparation for workshop: call for participation, prepare agenda
... second f2f = workshop

<Ed> I agree with the November plans.

Introduction to W3C, W3C process and Tools [Thomas Roessler]

tlr: slides at http://www.w3.org/2007/xmlsec/w3c101

<fjh> ack

<Zakim> fjh, you wanted to test this

<fjh> if you are on the queue and muted, when acked are unmuted

fjh: starting again

<scribe> ACTION: Frederick to update scribe instructions [recorded in http://www.w3.org/2007/05/02-xmlsec-minutes.html#action01]

<scribe> ACTION: Frederick to provide instructions on using bugzilla [recorded in http://www.w3.org/2007/05/02-xmlsec-minutes.html#action03]

<trackbot-ng> Created ACTION-4 - Provide instructions on using bugzilla [on Frederick Hirsch - due 2007-05-09].

<tlr> ACTION: Thomas to teach tracker about common aliases [recorded in http://www.w3.org/2007/05/02-xmlsec-minutes.html#action04]

<trackbot-ng> Created ACTION-5 - Teach tracker about common aliases [on Thomas Roessler - due 2007-05-09].

<fjh> We would like to avoid reaching need for formal objection

<fjh> Consensus is for "in the set", i.e. people in good standing.

<fjh> Good standing based on attendance and delivering on deadlines. See Thomas slides.

<tlr> http://www.w3.org/2005/10/Process-20051014/policies.html#coi

<fjh> please review conflict of interest policy, noted in the link above

grw: what is conflict of interest in the context of this group?

tlr: see process document for explanation of conflict of interest

<fjh> current patent practice link - http://www.w3.org/TR/2002/NOTE-patent-practice-20020124

tlr: XML Signature predates current patent policy
... see patent policy transition procedure

<fjh> Transition procedure link - http://www.w3.org/2004/02/05-pp-transition.html

Presentation: Overview of Canonical XML 1.1 and XPath essentials [Konrad Lanz]

<Ed> No, I do not have the slides.

<tlr> http://www.w3.org/2007/xmlsec/20070502-klanz-c14n.pdf

<fjh> see also http://www.w3.org/TR/DSig-usage/

<fjh> XPointer used in URI, XPath Filter in Transform both allow getting document subset

<tlr> ACTION: konrad to share example for transform that depends on information beyond the transform input nodeset [recorded in http://www.w3.org/2007/05/02-xmlsec-minutes.html#action05]

<trackbot-ng> Created ACTION-6 - Share example for transform that depends on information beyond the transform input nodeset [on Konrad Lanz - due 2007-05-09].

<tlr> http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Feb/att-0013/C14N-diff.html

<fjh> grw: Is C14N11 needed for SIgnedInfo?

<fjh> Konrad: could use id on signed Info other than schema

<fjh> juan-carlos: focus on current attributes in xml namespace

old behavior is to inherit all xml: attributes

proposal to change that to not inherit by default

fjh: can we ask xml core to specify inheritance rules when new attributes defined?

hal: no, we can't count on that

<fjh> ISSUE: C14N11 does not clearly define how new attributes in xml namespace are to be handled (as inheritable, non-inheritable, undefined)

klnaz2: raised this issue with xml core, but not solved there

<tlr> +1 to Frederick

<tlr> PROPOSED: up on groups that define XML namespace attributes to tell whether simply inheritable or not

<tlr> (by juan Carlos)

<fjh> proposal is to propose sentence and give to XML Core, other attributes in xml namespace are non-inheritable by default

jcc: should be up to group defining xml attributes whether inheritable
... should have a registry of attributes

klnaz2: maybe this is better for future work

hal: c14 doc should be explicit, don't include implict rules

tlr: how is conformance affected by future additions that break a current algorithm

fjh: if c14 1.1 is to be compatible with 1.0 can we change the rules around xml: attribute inheritance

phb: not relevant since you will never mix 1.0 and 1.1 (eg sign with 1.0 and verify with 1.1)

<fjh> ie clear because you explicitly specify canonicalization method

deastlak: default should be not inheritable since you can always work around that, but not the reverse

<fjh> deastlak: desireable not to have to rev canonicalization

deastlak: would be nice if inheritably could be determined syntactically
... alternatively, could have some explicit indication of inheritability

hal: no way to anticipate future special cases

klanz2: could have an extensibility parameter but not a big fan of that

phb: just ask xml core what default they prefer: inheritable or not

<Zakim> PHB, you wanted to raise the issue of qname mess

<fjh> greg whitehead: need to change from default of inheriting for xml namespace attributes

<fjh> ... perhaps extensibiilty to indicate how handled as input to canon algorithm

<fjh> ... perhaps extensibiilty to indicate how handled as input to canon algorithm

<fjh> ... perhaps uri

<fjh> ... diminishing returns depending on how far this goes

<fjh> ack

<fjh> tlr: undefined behaviour leads to both security and interoperability issue

tlr: inheritance issue could be handled by a prefilter using existing extensibility points
... if you define a attribute that requires special processing, define a transform to do that processing

klnaz2: this won't work because transforms always refer back to the original document, changes apply to original
... could do this only if we change the transform processing model to output a copy of input

proposal - for attributes in xml namespace, not listed in c14n 1.1, there will be no special processing

rationale - exceptional processing for future xml attributes can be handled by some mechanism without revving c14n (such as pre-processing)

fjh: proposes to propose this to xml core
... also convey security concerns

security concern - with this proposal, security may be compromised if new attributes are defined that require special processing

<deastlak> for clarity suggest "no special processing' -> "no special process, that is, they will be treated as not inheritable"

hal: alternative is to stop with an error if an unknown xml attribute is found

tlr: this would prevent using existing extension points to handle special processing
... c14n would have to revved in all cases
... error proposal is safer, but has higher deployment cost

deastlak: fixed behavior best, not inherited a better default since you can always copy attributes as a workaround
... not desireable to keep revving c14n

<klnaz2> http://www.w3.org/TR/C14N-issues/#S3

ed: prefers inherited to be default

<Ed> Ed prefers inheritance, but wants to study this issue more, and also see examples of the arguments against inheritance

break

<fjh> return at 1:15 ET, about 1/2 hour

<Ed> I'm back

<fjh> Resuming meeting

<tlr> ScribeNick: rdmiller

<tlr> Scribe: RobMiller

XML 1.1 and C14N

<fjh> konrad: this means cannot sign xml 1.1 at all

<fjh> ... suggests looking at xml core archives

Ed: wondering about XPATH 2.0

klnaz2: Canonical XML is currently defined for XPath 1.0 and not XPath 2.0

<Ed> Ed's point was whether XPath 2.0, though not defined in Canonical XML, might address or be of help in the issues re XPath 1.0 and XML 1.1

<fjh> klanz2: canonization need not generate valid XML, is this a good decision.

<fjh> klanz2: namespace undelarations in xml 1.1 can cause issues in canonicalization

fjh: where is this applicable?

klnaz2: this applies to XML 1.1 and canonicalization

fjh: what are we trying to accomplish with this conversation right now? this is a discussion for future charterting.
... will submit a comment to propose wording be added to C14N11 that C14N11 is applicable only to XML 1.0 and XPath 1.0

<tlr> don, http://www.w3.org/2007/xmlsec/20070502-klanz-c14n.pdf

fjh: did we address the qname issue properly?

tlr: not using qnames is a good topic for best practices.

<scribe> ACTION: Phil to propose a change to C14N11 to handle the qname issue due 5/3/2007 [recorded in http://www.w3.org/2007/05/02-xmlsec-minutes.html#action07]

<trackbot-ng> Sorry, couldn't find user - Phil

XML Signature Syntax and Processing - Overview and Proposed Changes [Thomas Roessler]

<Ed> are there slides?

tlr: The reference processing model should use C14N 1.0 as a default.
... the transform used for signing should be explicitly defined.

<tlr> http://www.w3.org/2007/xmlsec/20070502-tlr-dsigchange.pdf

<sean> q

<fjh> ack

sean: RetrievalMethod has a sequence of transforms.

<fjh> Dsig proposal has three parts

<fjh> a. receivers must assume c14n10

<fjh> b generators must put explicit transforms to be clear on c14 version

fjh: if you use xml:base with exclusive canonicalization there may be issues, but it is something that can be addressed.

<fjh> c mandatory algs c14n1.0 and c14n11 (both)

<scribe> ACTION: Thomas to provide precise wording for issues with exclusive canonicalization and xml:base [recorded in http://www.w3.org/2007/05/02-xmlsec-minutes.html#action08]

<trackbot-ng> Created ACTION-7 - Provide precise wording for issues with exclusive canonicalization and xml:base [on Thomas Roessler - due 2007-05-09].

<tlr> ACTION: Thomas to propose spec wording for conformance-affecting changes [recorded in http://www.w3.org/2007/05/02-xmlsec-minutes.html#action09]

<trackbot-ng> Created ACTION-8 - Propose spec wording for conformance-affecting changes [on Thomas Roessler - due 2007-05-09].

<tlr> ACTION-7 closed

<trackbot-ng> Sorry... I don't know how to close ACTION yet

Review of XML Signature errata

<Ed> Is there a link to errata slides?

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

<tlr> http://www.w3.org/2001/10/xmldsig-errata

<scribe> ACTION: Sean to review E01 [recorded in http://www.w3.org/2007/05/02-xmlsec-minutes.html#action10]

<trackbot-ng> Created ACTION-9 - Review E01 [on Sean Mullan - due 2007-05-09].

<tlr> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0039.html

<tlr> ACTION-9 also covers reviewing the old material -- "what was meant by it"

fjh: E01 was meant to be editorial
... added a note addressing E02 stating that Exclusive XML Canonicalization may be used

RESOLVED: E02 accepted

<tlr> http://www.w3.org/TR/xmldsig-filter2/#sec-Algorithm-Identifier

RESOLVED: E03 edits accepted

<Ed> I was cut off again; will call back shortly

<tlr> ed, we were cut off

RESOLVED: E04 edits accepted, but will require wordsmithing to replace "since" with "because".

<tlr> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002AprJun/0109.html

<scribe> ACTION: Whitehead to review E05 [recorded in http://www.w3.org/2007/05/02-xmlsec-minutes.html#action11]

<trackbot-ng> Created ACTION-10 - Review E05 [on Greg Whitehead - due 2007-05-09].

<tlr> ACTION: klanz2 to investigate Austrian eGov use case for Type attribute [recorded in http://www.w3.org/2007/05/02-xmlsec-minutes.html#action12]

<trackbot-ng> Created ACTION-11 - Investigate Austrian eGov use case for Type attribute [on Konrad Lanz - due 2007-05-09].

<fjh> Greg W: consider changing "signed" to "referenced" in "type of object being signed"

jcc: In E05 propose changing the word "signed" to "processed".

<fjh> sean: implementation may need Type for RetrievalMessage processing

<deastlak> RFC 4051 section 3.2 defines many additional RetreivalMethhod types

fjh: action-10 is reassigned to Konrad
... we think that E05 might be correct due to RFC 4051 section 3.2 and other language in that section may need to be adjusted.

<fjh> General agreement to this

E06, base64 URI

<fjh> question whether "base64" should be allowed or only URI allowed

<fjh> Thomas suggests interop test for URI use for this

E06 edits accepted

klanz2: "#base64" is different than "base64"

<fjh> Section 6.6.2 describes base64 URI for transform

<fjh> see also 6.1

<fjh> thomas: base64 encoding is manditory, URI declares the encoding in 6.1

<fjh> ... No section that lists encoding algorithms

<grw> base64 transform URI not listed in 6.1 (only base64 encoding URI)

<fjh> update to errata would be to complete the list of transforms in 6.1

tlr: explain what the base64 URI means in an encoding context

<fjh> Konrad: "base64" is a URI

<fjh> discussion whether this is an appropriate URI, issue of scheme

<fjh> thomas: non normative change

<fjh> juan carlos: usage of attribute is an application matter, so is it a concern here for platform?

Ed: plain base64 is not defined anywhere in the spec, but the URI is
... are we going to have a new namespace for dsig?

<deastlak> Gak no....!

<tlr> http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html

tlr: our charter precludes us creating a new namespace for dsig
... the base64 URI issue has been settled in previous attribute testing. base64 was only tested as a URI

Thomas proposed closing the discussion on E06 and accepting the edits

RESOLUTION: E06 accepted

RESOLUTION: E07 accepted

deastlak: E08 looks correct to me

RESOLUTION: E08 accepted

fjh: do we need to go through dsig errata line by line or can we review Thomas' proposed changes?

<fjh> ack

fjh: by default the usage of URI is optional and the DTD requires it

on break

<fjh> return in 15 minutes

<Ed> To clarify the XML DSig namespace question above -- my question was whether the current "xmlns="http://www.w3.org/2000/09/xmldsig#"" might be changed to indicate a later version, say "xmlns="http://www.w3.org/2007/12/xmldsig#"", based on this WG's activities. Answer: No, that implies changes beyond the scope of this WG.

Interop discussion and planning

tlr: immediate next step for Dsig is an updated editors draft.
... is the inheritance issue something that will need to be in interop testing?

fjh: yes, and it may cause some schedule slip.

tlr: what are people expecting as timelines with regard to implementing and testing?

fjh: we should look at interop testing in the the June or July timeframe.
... July is probably too late

<fjh> Konrad: how will xml:base interact with xml Signature

<fjh> thomas: impact on meaning of URI in Reference and RetrievalMethod

<fjh> thomas: is an XML Signature with xml:base within it schema conformant

<tlr> http://www.w3.org/TR/xmlbase/

<fjh> from the xml base spec - "The deployment of XML Base is through normative reference by new specifications, for example XLink and the XML Infoset. Applications and specifications built upon these new technologies will natively support XML Base. The behavior of xml:base attributes in applications based on specifications that do not have direct or indirect normative reference to XML Base is undefined."

<fjh> Juan Carlos: xml base for chartering activity

<fjh> thomas: +1

fjh: we are not defining any behavior for xmlbase so let's dodge it.

<Ed> I expect xml:base, namespace canonicalization, and qnames will require chartering activity.

fjh: how are we going to deal with confidentiality and interop?
... we may need a private interop mailing list.

tlr: we will need to keep interop testing confidential, with a public report at the end.

fjh: i would like to keep a record of who says they can do interop and what state they are in.
... members can use the member list to report status.

tlr: technical work on test cases should be on the public list, all other interop communication should be on the member list.

interop

<tlr> ACTION: all to investigate interop testing capabilities [recorded in http://www.w3.org/2007/05/02-xmlsec-minutes.html#action13]

<trackbot-ng> Sorry, couldn't find user - all

<tlr> ACTION: frederick to contact participants in previous interop testing [recorded in http://www.w3.org/2007/05/02-xmlsec-minutes.html#action14]

<trackbot-ng> Created ACTION-12 - Contact participants in previous interop testing [on Frederick Hirsch - due 2007-05-09].

<tlr> interop testing logistics and availability to be discussed on the member list

<tlr> ACTION: thomas to put up WBS form to ask about interop testing interest [recorded in http://www.w3.org/2007/05/02-xmlsec-minutes.html#action15]

<trackbot-ng> Created ACTION-13 - Put up WBS form to ask about interop testing interest [on Thomas Roessler - due 2007-05-09].

tlr: I would like to get a timeframe, facility and next steps toward a workshop.

fjh: That will be the first thing on the agenda tomorrow.

grw: we can solicit information via email.

fjh: we may not even need a workshop

Thomas explained the workshop process.

klanz2: why cant we put everything into a wiki and decide later if we need to meet?

tlr: that would work well among the memnbers of the WG, but we are also targeting the public.
... we are looking at the entire stack regarding dsig/decryption. What comes next?

Future work topics

<fjh> xml base and xml:id support with xml sig

<fjh> (reference processing)

<fjh> C14N support for xml 1.1?

<fjh> XPath data model adjustments

<fjh> Infoset data model

<fjh> XPath 2.0

<fjh> -- this material should go on the wiki

<fjh> transform chaining referening original document, modification of original data

<fjh> e.g. pass by value, not reference

<fjh> canonicalization that throws out more "ruthless canonicalization"

<fjh> additional algorithms (eg SHA-256)

<fjh> performance bottlenecks

<fjh> simplicity

<fjh> issues related to protocol use

<fjh> relationship with binary xml, combinations etc

<fjh> (efficient xml)

<fjh> discussion with efficient xml interchange group possibililty

<fjh> implicit parsing that is not schema aware (in transform chain)

<fjh> workshop item - what is canonicalization in sig context

<deastlak> FIN

<Ed> Thanks, I'm happy to stay and listen.

<fjh> may wish to ask others that define XML languages to define canonicalization or canonicalization properties for them

<Ed> language-specific canonicalization has its limits; e.g. canonicalizing mixed language xml instances still requires core canonicalization