XML Security Working Group Teleconference

<trackbot> Date: 04 May 2010

Administrative

trackbot, start meeting

<trackbot> Meeting: XML Security Working Group Teleconference

<trackbot> Date: 04 May 2010

<scribe> Scribe: tlr

<esimon2> My phone does not seem to be working; might be chat only for me.

<fjh> Privacy Workshop

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0065.html

fjh: privacy workshop -- privacy on the web, apis, etc, 12/13 July in London

<fjh> Widget Signature proposed updates (Last Call review)

fjh: widget signature; MArcos did revision based on test work

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0068.html

fjh: some changes to normative requirements

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0070.html

fjh: there'll be a decision on the Widgets call on Thursday

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0000.html

<esimon2> * Ed now has a phone connection

minutes approval

<fjh> Approve 27 April minutes

<Cynthia> http://www.w3.org/2010/04/27-xmlsec-minutes.html

<fjh> http://www.w3.org/2010/04/27-xmlsec-minutes.html

RESOLUTION: 27 April minutes approved

editorial updates

fjh: pratik made some changes; later in the agenda

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0011.html

charter extension

fjh: made the request

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2010May/0000.html

tlr: it's on the agenda

XML Encryption 1.1

fjh: sent some comments, magnus looked

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0057.html

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0009.html

fjh: confused about ??info

magnus: if provide one value, need to provide the other one, too

<fjh> PartyVInfo="" should have value in example

<fjh> actoin: magnus to update XML Encryption 1.1 with changes from Frederick and his proposed changes, http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0009.html , also to give value to PartyVInfo="" should have value in example

<fjh> ACTION: magnus to update XML Encryption 1.1 with changes from Frederick and his proposed changes, http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0009.html , also to give value to PartyVInfo="" should have value in example [recorded in http://www.w3.org/2010/05/04-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-566 - Update XML Encryption 1.1 with changes from Frederick and his proposed changes, http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0009.html , also to give value to PartyVInfo="" should have value in example [on Magnus Nystrom - due 2010-05-11].

fjh: would like to get closure on 1.1 soon-ish

generic hybrid ciphers

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0066.html

fjh: there were some places where derived keys could be used; Magnus looked at that as well, agreed

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0010.html

fjh: chatted about shortname and namespace
... namespace in /2009/?

tlr: doesn't really matter, either

fjh: hearing no objection, leave them as they are?

edsimon: associate with a dated specification

tlr: if there are implementations around and make breaking changes to spec, then makes sense to change namespaces

magnus: /2009/gh -> /2010/ghc?

fjh: implementations?

-- silence --

<scribe> ACTION: magnus to change generic hybrid ciphers namespace to /2010/ghc [recorded in http://www.w3.org/2010/05/04-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-567 - Change generic hybrid ciphers namespace to /2010/ghc [on Magnus Nystrom - due 2010-05-11].

fjh: EC note?

magnus: spec is optiona

tlr: well, optional to implementers of signature, but there are implementation requirements in here

<fjh> http://www.w3.org/2008/xmlsec/Drafts/generic-hybrid-ciphers/Overview.html

<Cynthia> please add some of this discussion to the meeting minutes

tlr: so, does this spec need to include a mandatory set of algorithms?

magnus: nice security properties; future-proofing.

<Cynthia> I think it may

fjh: would like to see this move forward

tlr: so, in Enc and Sig, we're talking about specific curves. Here we don't.

bal: we're indeed not talking about curves here.

<fjh> is ghc simply an application of the ecc in dsig?

bal: it's a pre-stage to EC, right?

<fjh> or xenc

bal: defining encapsulation in a way that key derivation functions get applied

<fjh> so this may be a non-issue for IPR

tlr: so, we have had concerns about what's in Encryption and Signature. If this either simply uses what's in those specs, or is entirely different, and no concerns come up, then don't see why we can't move ahead.

<scribe> ACTION: magnus and bal to review relationship between ghc and material in encryption [recorded in http://www.w3.org/2010/05/04-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-568 - And bal to review relationship between ghc and material in encryption [on Magnus Nystrom - due 2010-05-11].

fjh: in encryption, section 6 marked as informative, schema example as non-normative

magnus: there was one other suggestion -- versioning section of the doc says that the namespace URI is used as a prefix for identifiers

<fjh> ACTION: implement changes to Generic Hybrid Ciphers as proposed by Frederick, and revisions from Magnus, http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0010.html [recorded in http://www.w3.org/2010/05/04-xmlsec-minutes.html#action04]

<trackbot> Sorry, couldn't find user - implement

<fjh> ACTION: magnus implement changes to Generic Hybrid Ciphers as proposed by Frederick, and revisions from Magnus, http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0010.html [recorded in http://www.w3.org/2010/05/04-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-569 - Implement changes to Generic Hybrid Ciphers as proposed by Frederick, and revisions from Magnus, http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0010.html [on Magnus Nystrom - due 2010-05-11].

<fjh> Replace "This namespace is also used as the prefix for identifiers defined by this

<fjh> > specification."

<fjh> The use of the gh prefix in this document is an editorial convention

<fjh> > - other prefix values could be associated with the namespace

<scribe> ACTION: thomas to revise gh namespace section [recorded in http://www.w3.org/2010/05/04-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-570 - Revise gh namespace section [on Thomas Roessler - due 2010-05-11].

ACTION-570 due today

<trackbot> ACTION-570 Revise gh namespace section due date now today

XML Enc errata

<fjh> Last Call planning - Errata Status

fjh: looks like they're all in the doc

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0003.html

Last call issues,actions

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0004.html

<fjh> ISSUE-91?

<trackbot> ISSUE-91 -- ECC can't be REQUIRED -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/91

ISSUE-178?

<trackbot> ISSUE-178 -- Highlight additional text constraints on XSD schema as such. -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/178

<fjh> suggest we only apply this to new 2.0 work

fjh: what do people think?

RESOLUTION: will not address issue-178 in 1.1 work

<fjh> issue=180?

<fjh> issue-180?

<trackbot> ISSUE-180 -- Section 8 identifies Joseph Reagle as the contact for the XML Encryption media type. This needs to be updated, perhaps to a generic identity? -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/180

ISSUE-178: will only address in 2.0 work

<trackbot> ISSUE-178 Highlight additional text constraints on XSD schema as such. notes added

<fjh> tlr notes that changes will not invalidate any review, so should not be an issue for going to Last Call

<fjh> action-11?

<trackbot> ACTION-11 -- Frederick Hirsch to ask for XPath 2.0 presentation to group -- due 2008-07-24 -- CLOSED

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/11

ACTION-511?

<trackbot> ACTION-511 -- Thomas Roessler to propose next steps on media type registration (ISSUE-180) -- due 2010-04-30 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/511

<fjh> action-511?

<trackbot> ACTION-511 -- Thomas Roessler to propose next steps on media type registration (ISSUE-180) -- due 2010-04-30 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/511

<fjh> ISSUE-192?

<trackbot> ISSUE-192 -- Namespaces for DerivedKey and pbkdf2 outside of xenc11 namespace -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/192

issue-192?

<trackbot> ISSUE-192 -- Namespaces for DerivedKey and pbkdf2 outside of xenc11 namespace -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/192

<fjh> issue-192 closed

<trackbot> ISSUE-192 Namespaces for DerivedKey and pbkdf2 outside of xenc11 namespace closed

<fjh> issue-194?

<trackbot> ISSUE-194 -- Is "the ECPublicKey element" in Encryption 1.1 and Signature 1.1 actually the ECKeyValue element? -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/194

<fjh> issue-194 closed

<trackbot> ISSUE-194 Is "the ECPublicKey element" in Encryption 1.1 and Signature 1.1 actually the ECKeyValue element? closed

<fjh> issue-194 ECPublicKey element change to ECKeyValue in document

<fjh> issue-194: ECPublicKey element change to ECKeyValue in document

<trackbot> ISSUE-194 Is "the ECPublicKey element" in Encryption 1.1 and Signature 1.1 actually the ECKeyValue element? notes added

issue-138?

<trackbot> ISSUE-138 -- What interoperability and security issues arise out of schema validation behavior? -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/138

scantor: people have run into issues with well-formedness
... lost namespaces etc
... but think schema validation problems are sort of a superset
... doesn't have the same infoset modifying issues which are what comes up in signature

esimon2: that issue is mine

<fjh> note issue-138 only applies to xml signature

esimon2: this is a long-term issue

<fjh> suggest this is a 2.0 issue

tlr: associate with signature 2.0?

esimon2: would associate with any version

tlr: if this is an issue against 1.1, then shouldn't have gone to last call

fjh: is this an issue that blocks 1.1?
... I'd argue that it isn't

esimon2: right

tlr: so we track this as an issue against 2.0?

esimon: all theoretical at this point, haven't proven at this point
... similar to the namespace questions
... made some progress thanks to Meiko and others

fjh: so, we deal with this in 2.0, *if* we deal with it, which depends on us figuring it out

scantor: neither spec addresses schema validation, therefore out of scope

esimon2: somewhat agree

fjh: you don't mind 1.1 becoming Rec without addressing this?

esimon2: I don't object against that, right

PROPOSED RESOLUTION: Won't address ISSUE-138 in XML Signature 1.1 work

RESOLUTION: We won't address ISSUE-138 in XML Signature 1.1 work

issue-138?

<trackbot> ISSUE-138 -- What interoperability and security issues arise out of schema validation behavior? -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/138

action-280?

<trackbot> ACTION-280 -- Magnus Nyström to produce test cases for derived keys -- due 2009-05-19 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/280

fjh: this isn't critical for LC. But what's the status?

magnus: developed test cases, but didn't develop code to build actual data

fjh: shouldn't hold up last call; keeping open

magnus: shouldn't affect LC; not sure when I'll get to it

ACTION-452?

<trackbot> ACTION-452 -- Scott Cantor to review the XML ENC v1.1 document -- due 2009-11-24 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/452

scantor: was supposed to review EXI changes and application implications. Think events have moved on

<fjh> action-452: focused on EXI

<trackbot> ACTION-452 Review the XML ENC v1.1 document notes added

ACTION-452 closed

<trackbot> ACTION-452 Review the XML ENC v1.1 document closed

ACTION-238?

<trackbot> ACTION-238 -- Thomas Roessler to update the proposal associated with ACTION-222 and send to list. -- due 2010-05-31 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/238

<fjh> action-222?

<trackbot> ACTION-222 -- Konrad Lanz to make proposal RIPE algorithms -- due 2009-03-03 -- CLOSED

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/222

<fjh> action-238: for possible algorithms RFC, not for XML Encryption specification

<trackbot> ACTION-238 Update the proposal associated with ACTION-222 and send to list. notes added

ACTION-515?

<trackbot> ACTION-515 -- Aldrin J D'Souza to propose the schema addition for issue-186 -- due 2010-02-23 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/515

action-515 closed

<trackbot> ACTION-515 Propose the schema addition for issue-186 closed

issue-186?

<trackbot> ISSUE-186 -- What is the normative content of section 5.4.2? (PBKDF2) -- CLOSED

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/186

action-533?

<trackbot> ACTION-533 -- Aldrin J D'Souza to implement proposed change to XML Encryption 1.1 per proposal to resolve ISSUE-186 -- due 2010-03-09 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/533

<fjh> issue-186?

<trackbot> ISSUE-186 -- What is the normative content of section 5.4.2? (PBKDF2) -- CLOSED

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/186

action-533?

<trackbot> ACTION-533 -- Aldrin J D'Souza to implement proposed change to XML Encryption 1.1 per proposal to resolve ISSUE-186 -- due 2010-03-09 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/533

http://lists.w3.org/Archives/Public/public-xmlsec/2010Feb/0043.html

ACTION-515: http://lists.w3.org/Archives/Public/public-xmlsec/2010Feb/0043.html

<trackbot> ACTION-515 Propose the schema addition for issue-186 notes added

tlr: the text proposed in ACTION-515 indeed has been added to the spec, so ACTION-533 done

ACTION-515 closed

<trackbot> ACTION-515 Propose the schema addition for issue-186 closed

ACTION-533 closed

<trackbot> ACTION-533 Implement proposed change to XML Encryption 1.1 per proposal to resolve ISSUE-186 closed

ISSUE-186 closed

<trackbot> ISSUE-186 What is the normative content of section 5.4.2? (PBKDF2) closed

fjh: there are some more things about test cases and interop; not critical path
... only actions that are relevant now are the three on magnus

tlr: ... and the one on me to fix the namespace piece

fjh: another item, references.
... anybody have a moment to scan through references and see if they're still up to date

-- silence --

<scribe> ACTION: fjh to review references in generic hybrids and encryption 1.1 [recorded in http://www.w3.org/2010/05/04-xmlsec-minutes.html#action07]

<trackbot> Created ACTION-571 - Review references in generic hybrids and encryption 1.1 [on Frederick Hirsch - due 2010-05-11].

<scribe> ACTION: frederick to get encryption 1.1 and GHC pubrules-ready [recorded in http://www.w3.org/2010/05/04-xmlsec-minutes.html#action08]

<trackbot> Created ACTION-572 - Get encryption 1.1 and GHC pubrules-ready [on Frederick Hirsch - due 2010-05-11].

<fjh> plan to Agree to Last Call at next week's call, 11 May

fjh: plan is to resolve on Last Call next week
... publish next Thursday
... have four week last call

tlr: checking IETF meeting dates -- late July
... that's much later; suggest not to wait

fjh: send note to EXI chairs on timing

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0002.html

fjh: any worries about the schema files?

tlr: well, if we make a change to the GH namespace, that also needs to happen in any schema files where it shows up

canonical xml 2.0

fjh: mentioned Pratik's editorial update in beginning of call

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0011.html

fjh: pratik, did you want to walk us through that?

action-550?

<trackbot> ACTION-550 -- Pratik Datta to implement editorial changes from scott and ed -- due 2010-04-20 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/550

action-554?

<trackbot> ACTION-554 -- Pratik Datta to review c14n comments from meiko, incorporate into doc, flagging with email any concerns for discussion -- due 2010-04-27 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/554

action-550 closed

<trackbot> ACTION-550 Implement editorial changes from scott and ed closed

action-554 closed

<trackbot> ACTION-554 Review c14n comments from meiko, incorporate into doc, flagging with email any concerns for discussion closed

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0008.html

ACTION-561 closed

<trackbot> ACTION-561 Review ISSUE-196 closed

tlr: see e-mail. Don't think it's worth conf call time.

RESOLUTION: XML/EXI URIs from ACTION-561 accepted

<esimon2> As per ACTION-559, I checked and XML Schema does NOT support entities like DTDs do. If you want to use entities as one did with DTDs, you have to use a DTD.

pratik: ignoreDTD parameter

action-559?

<trackbot> ACTION-559 -- Ed Simon to investigate schema vs. DTD -- due 2010-05-04 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/559

pdatta: ??

<fjh> Ed notes XML Schemas does not support entities like DTDs did, so if you want them you need DTDs

<fjh> discussion on ignoreDTD parameter and whether we need another name...

esimon2: may need to rename this. But need to be clearer what this parameter is about.
... is this about entity processing only?

scantor: right, because defaults come into play as well
... i.e., processing default attributes

<fjh> is parameter really about entities?

scantor: strongly in favor of leaving schema out of this discussion
... some discussion about merging these concepts, and that would be a mistake
... is this about ignoring the DTD, or just about entities
... parser settings that one can mix and match

<fjh> processEntities? processDTDEntities?

scantor: look at use cases, would be useful to know whether old c14n algs do anything with issue
... is DTD processing just implied now

issue-183?

<trackbot> ISSUE-183 -- Constrain 2.0 SignedInfo canonicalization choice for 2.0 model? -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/183

esimon: this might also apply to issue-183?

pdatta: c14n does process DTD

scantor: treat as ignoring DTD?

esimon: think I disagree about importance of processing schema
... security concern

scantor: was saying it isn't a good idea to merge schema processing behavior into DTD stuff
... leave this as DTD centric option

<fjh> tlr notes entities are defined in core XML spec

<fjh> tlr advocates c14n2 defined on infoset

<fjh> pratik notes parameter is included to address security concerns

scantor: original c14N talks about entity references

s/tlr notes they do not appear in infoset/tlr: do they even make an appearance in the infoset?/

<Zakim> fjh, you wanted to ask if we are talking about separate parameter for entity processing only

scantor: for simplicity reasons, would be happy to treat ignore DTD as just ignore DTD, don't go deeper
... reason for the feature are entities
... but defaults in DTDs cause problems similar to schema

correction: entities *do* show up in the infoset. I was wrong.

fjh: we want those parameters, but don't like admitting?

<fjh> pratik notes two parameters, ignoreDTD , expandEntities

<scantor> and c14n 1.x says "Character and parsed entity references are replaced", as Pratik was saying

pratik: default values, entity expansion. If only two parameters, it's fine to have two separate ones

http://www.w3.org/TR/xml-infoset/#intro.entities

<fjh> pratik agrees two parameters, one to ignore entities, one to ignore default values

<fjh> tlr says that if ignoring entities, then not validating so default values ignored

<fjh> others note assumptions are risky and confusing

<scribe> ACTION: scantor to create issue on DTDs, entities, defaulting, schema validation for C14N 2.0 [recorded in http://www.w3.org/2010/05/04-xmlsec-minutes.html#action09]

<trackbot> Created ACTION-573 - Create issue on DTDs, entities, defaulting, schema validation for C14N 2.0 [on Scott Cantor - due 2010-05-11].

<fjh> please include in issue summary of issue and proposed resolution

ACTION-573: review of XML parsing, XML Infoset, C14N 1.1 needed

<trackbot> ACTION-573 Create issue on DTDs, entities, defaulting, schema validation for C14N 2.0 notes added

pdatta: also, note ID attribute problems

edsimon: how does that affect c14?
... that sounds like validation aspect

scantor: affects signature, not c14n

esimon: schema validation in XML?

scantor: no such thing in core XML 1.0 + XML Namespaces + ...

esimon: But XML Schema defines validation
... but XML signature we use XML schema to define what an XML Signature looks like

scantor: yes. But schema validation isn't part of the processing model.

esimon: but the schema is normative part of the spec

scantor: only to define the grammar

esimon: umh

c14n2 xmlAncestors

fjh: back to Pratik's e-mail

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0011.html

<scantor> proposal on last call to combine the xml:* attribute options in c14n2

<scantor> fine with me

<fjh> http://www.w3.org/2010/04/27-xmlsec-minutes.html#item06

<esimon2> * Can Zakim distinguish between who is making noise and who is talking (where hopefully the two are not the same)? Anyway, the noise I'm hearing does not seem to originate from my office which is quite quiet.

tlr: so, this is about having one parameter for the *heritable* xml: ... parameters?

fjh: yes

scantor: issue that had been raising was use case for treating them differently

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0058.html

<fjh> from pratik email:

<fjh> . >> Would it be clean enough (and simpler) to collapse the the xmlXAncestors parameters into a single parameter and just apply "combine" to only xml:base? Is there a need to use different rules for different attributes?

<fjh> Seems like the various "modes" sort of go together given how the earlier algorithms work.

<fjh> How about a new parameter "xmlAncestors" whose values can be

<fjh> "inheritAll" : Simulate Canonical XML 1.0 behavior, which inherits all the attributes

<fjh> "inherit" : Simulate the Canonical XML 1.1 behavior, where you inherit the inheritable attributes and combine the xml:base

<fjh> "none" : Simulate Exc Canonical xML 1.0 behavior

tlr: realization during c14n 1.1 work was that xml:base is heritable, but more difficult than just copying what's in the serialization
... why is the 1.0 behavior useful?
... we know it's wrong

fjh: for backward compatibility

scantor: goal to rewrite all existing canonicalization into a version of 2.0

tlr: Eeeek!

pdatta: yes, that's the idea

scantor: idea to use 2.0 implementations for everything

<scantor> the intent of the full range of options was to enable a 2.0 impl to be given options that allow for output equivalent to before

tlr: I can see how the exclusive 1.0 behavior is sane. The inclusive 1.1 behavior is ok. The inclusive 1.0 behavior is broken. Now we're adding an option that must be supported and forces everybody to implement the inclusive 1.0 behavior?!

pdatta: convinced that we should remove inheritAll
... maybe something an implementation might do internally
... remove inheritAll

<fjh> suggest pratik summarize proposal in email

pdatta: qnames *noise*

C14n2 QNames in content

<fjh> scott plans to provide proposal

meiko: this is what we talked about in the context of the include/excludeXPath expressions

scantor: think there is a general solution to the harder problem
... problem with qnames in documents is mostly qname-valued nodes
... rare that they show up in the middle of text

Streaming and C14N2

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0071.html

<fjh> ACTION-562?

<trackbot> ACTION-562 -- Meiko Jensen to provide streaming-canonicalization proposal -- due 2010-05-04 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/562

action-562 closed

<trackbot> ACTION-562 Provide streaming-canonicalization proposal closed

meiko: named parameter sets; strawman; without deeper investigation of issues, it's not worth discussing in 10 minutes
... if somebody wants to review, that would be great; otherwise, suggest stream based parameter set be put in spec

fjh: so this is a proposal to pick and choose parameters for streaming

<Cynthia1> I haven't read it yet, but am interested in the specific applications for this

tlr: interested in Pratik's review of this proposal

pdatta: should propose trimTextNodes in streaming mode, too

meiko: pdatta suspects trimTextNodes true might be more work. Will follow up on list, since we're running out of time.

pdatta: +1

meiko: digest-based prefix rewriting -- base64 might contain '=', which isn't allowed for namespaces

<fjh> tlr notes could use a different encoding

meiko: you'd have to escape

tlr: ... or use different encoding -- base32 or so

scantor: would be nice to simplify digesting mechanism, including encoding
... would like to avoid having ton of steps that people might screw up
... I had proposed the hex-encoded digest
... probably with underscore to get around leading digits

<scribe> ACTION: scantor to send his proposal on prefix rewriting to the list [recorded in http://www.w3.org/2010/05/04-xmlsec-minutes.html#action10]

<trackbot> Created ACTION-574 - Send his proposal on prefix rewriting to the list [on Scott Cantor - due 2010-05-11].

-- adjourned --