See also: IRC log
<trackbot> Date: 01 November 2010
<brich> ScribeNick: brich
fjh: schedule tomorrow is for whole day, but may find can end early
... tomorrow will have perf, wrapping attacks
<fjh> Approve minutes from 26 October 2009
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/att-0041/minutes-2010-10-26.html
RESOLUTION: Minutes of 26 Oct approved
<fjh> http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
fjh: have to believe have satisfied tech requirements
... also satisfy dependencies from other groups
<fjh> xsl working, xml core
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-xpath/
fjh: I submitted some comments
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0056.html
<fjh> http://www.w3.org/TR/xpath/
<fjh> http://www.w3.org/TR/xpath/#location-paths
mjensen: suggests copying material from xpath 1.0 into new spec, rather than referring back to it, looking at what that would mean
... hard to see what's part of new spec and what's not
fjh: standalone doc to document what axes are supported? not a "diff" format
mjensen: ambiguities between grammar and constraints...
pdatta: should we limit it more?
... grammar is very hard to read, examples are more illustrative
fjh: does grammar feed a tool? why have it?
pdata: grammar yields precision
mjensen: predicate expressions are the most troublesome
pdatta: should clarify with additional examples
fjh: really dislike copying text over
... XPath spec is too monolithic, hard to derive things from it
... grammar for the subset as an appendix in the new spec
... going back to comments against profile...NodeType no longer exists (has right-hand side) but is used in other elements
pdatta: can clean up grammar, but perhaps need more explanation
... perhaps need section on what's allowed in a predicate expression
... also need section on what's allowed as a top-level expression
mjensen: will take some time, but is worth investment
fjh: do not understand section 3 any more...the "Other requirements"
pdatta: cannot end up with a generic nodeset
... perhaps should remove section
<fjh> ACTION: pdatta to add sections on top-level expressions and predicate to XPath profile [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-686 - Add sections on top-level expressions and predicate to XPath profile [on Pratik Datta - due 2010-11-08].
<fjh> ACTION: meiko to produce top level grammar for XPath profile [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-687 - Produce top level grammar for XPath profile [on Meiko Jensen - due 2010-11-08].
<pdatta> ACTION-687: Break up section 3 , move usecases to predicate section, and move c14n data model to top level
<trackbot> ACTION-687 Produce top level grammar for XPath profile notes added
<pdatta> ACTION-686: Break up section 3 , move usecases to predicate section, and move c14n data model to top level
<trackbot> ACTION-686 Add sections on top-level expressions and predicate to XPath profile notes added
fjh: hope is to go to last-call on our next WG call
pdatta: may have to remove ID completely, so resolving what to do with it is important
<pdatta> http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0049.html
pdatta: since we are a subset of XPath, we have to implement "id" function as XPath did
fjh: want to allow just the "id" function, no others
mjensen: allow "id" in predicates only
<fjh> disallow id function in predicates but allow at top level in simplest form
<fjh> tlr: allowing id in xpath would allow additional predicates
fjh: concerned that Sig 2.0 doesn't mandate this streaming profile
<fjh> would like to limit optionality etc
<fjh> ACTION: mjensen to add id function at XPath top level [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-688 - Add id function at XPath top level [on Meiko Jensen - due 2010-11-08].
<fjh> ACTION: pdatta to limit to xpath profile during xml signature 2.0 generation in 2.0 mode [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-689 - Limit to xpath profile during xml signature 2.0 generation in 2.0 mode [on Pratik Datta - due 2010-11-08].
reviewing Frederick's comments
http://lists.w3.org/Archives/Public/public-xmlsec/2010Oct/0056.html
<fjh> ACTION: mjensen to make explicit in grammar difference of included and excluded xpath, - ExcludedXpath can select attributes and element, whereas IncludedXPath can only select elements [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-690 - Make explicit in grammar difference of included and excluded xpath, - ExcludedXpath can select attributes and element, whereas IncludedXPath can only select elements [on Meiko Jensen - due 2010-11-08].
fjh: probably need to add a "Security Considerations" section to the xpath profile
<fjh> ACTION: pdatta to add security considerations section to xpath profile [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-691 - Add security considerations section to xpath profile [on Pratik Datta - due 2010-11-08].
<fjh> ScribeNick: brich
<fjh> will meet with XSLT group this afternoon at 2:30
<fjh> http://www.w3.org/2008/xmlsec/Drafts/c14n-20/
<fjh> ISSUE-215?
<trackbot> ISSUE-215 -- C14N2 conformance - optional parameters, profiles, etc -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/215
<fjh> ISSUE-204?
<trackbot> ISSUE-204 -- Integrated recognition of QName content -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/204
<fjh> ISSUE-206?
<trackbot> ISSUE-206 -- For c14n20 profile - clarify that conformance implies support, but also changes to xml or what must be explicitly specified -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/206
<fjh> ISSUE-198?
<trackbot> ISSUE-198 -- How to determine if arbitrary text content contains prefixes? Might need to do a lot of searching because text content can be large -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/198
pdatta: important to discuss degree of optionality
fjh: remove comments or not?
mjensen: comments count as nodes in XPath
fjh: two levels of optionality...support all the defaults (conformance) or allow some non-defaults....removing profile concept
<Gerald-E> in reviewing Meiko's examples
<Gerald-E> I found value in the profiles in addressing sets of defaults
<Gerald-E> rather than individual defaults
<mjensen> http://lists.w3.org/Archives/Public/public-xmlsec/2010Sep/0024.html
fjh: named profiles would just give you a shorthand for parameter sets, so not needed?
mjensen two or more values per parameter * the number of parameters makes for a very large interop matrix
<mjensen> if we make ALL options MANDATORY, we'll end up with an explosion of different configurations for interops.
<mjensen> on the other hand, if we just require the DEFAULTS for all options, we're facing the risk of nobody taking care of the new 2.0 features
<pdatta> An implementation that only support only the defaults is really only supporting C14N 1.1, so it is very simple implementation
<Gerald-E> I agree with Meiko
RESOLUTION: Remove sort-attributes parameter and make the default to "always-sort"
fjh: looking at "exclusive mode" and "xmlancestors=inherit"...
... and "Inclusive Namespace"
<fjh> we are not clear on the requirements other than that exclusive c14n compatibility is needed
<fjh> discussion of whether ExclusiveMode and XMLAncestors parameters really needed
<fjh> urge simplicity where possible
tlr: reducing complexity of the format, but not really of the implementation
<fjh> pdatta notes that QNames in context are now known by QNameAware
fjh: can someone being using Inclusive for a good reason, and now not be able to go to 2.0?
... discussion about context model vs document model and relevance of xmlancestors
<fjh> what is the adoption of xml:base and should we be concerned about it
fjh: could require people who want to use xmlbase to resolve it before calling signature?
conflicted over throwing out inclusive...really want to, but fear consequences
<fjh> ask norm and mohammed re non-inclusive
RESOLUTION: Remove the "ExclusiveMode" parameter, make the default to be exclusive
<fjh> ACTION: pdatta to add editorial note to c142 indicated only exclusive [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-692 - Add editorial note to c142 indicated only exclusive [on Pratik Datta - due 2010-11-08].
<fjh> pdatta will treat attributes in xml namespace not specially, but like any others
RESOLUTION: Remove the InclusiveNamespaces parameter and the "XMLAncestors" parameter
<fjh> tlr - some exi parameters enable a new c14n, some are unsuitable, could be separate c14n algorithm
<fjh> choice of c14n method should be in signature, e.g. algorithm, hence do not need Serialization parameter in C14N2
<fjh> tlr if seraiize as EXI need to choose EXI parameter set
RESOLUTION: Remove the "Serialization" parameter and default to normal XML serialization
<fjh> note that the reason includes concern about WG being able to test EXI serialization to bring to REC
<fjh> note may wish to allow for parameter extensibility in C14N
<fjh> ScribeNick: fjh
Pratik provided overview of XPath profile
Please see XQuery minutes item J7 at http://lists.w3.org/Archives/Member/w3c-xsl-query/2010Nov/0006.html for additional scribing of this session
xquery streamability - streamable patterns in xslt, can test node at any time versus pattern match vs 1-pass in xml security
comment raised - include and exclude xpath not mentioned in requirements document
suggestion, remove y example #8, since order of attributes is undefined, so type may not be first
issue with relying on syntax, since parens lost when parse tree created, hence might be hard to use existing XPath implementation and enforce constraints
should PIs be included (optionally) in canonicalization, parameter - probably not
disallowed #11, change comment, node() is not a function
but a "test"
what about self in predicate, self:: etc
possibly remove self from predicate
4a, remove '::" from '@' NameTest
question about including following axis..
is it hard to express grammatically semantic constraints
suggestion to clarify processing model in docuemnt
may not need to keep track of ancestors for processing model based on grammar
proposal, clarify that subset of XPath, not changing the meaning of any expressions
proposal, change title of document
suggestion, if anyone complains regarding schema profile, indicate it is not broad enough for xmlsec, maybe they could use the xmlsec version
meiko: potential issue to use //* to sign doc, select every node, take subtree and c14n
Interop wiki
http://www.w3.org/2008/xmlsec/wiki/Interop
Implementations wiki
http://www.w3.org/2008/xmlsec/wiki/Implementations
Yet to interop test: new 2.0, XML Encryption 1.1, Derived Keys, Generic Hybrid Ciphers
Signature Properties, most, OCSP, KeyInfoData, Keywrap
<pdatta> tlr: will we get an implementation of Generic Hybrid Ciphers
<scribe> ACTION: fjh to ask EMC/Aldrin about Generic Hybrid Cipher implementation at EMC [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-693 - Ask EMC/Aldrin about Generic Hybrid Cipher implementation at EMC [on Frederick Hirsch - due 2010-11-08].
<scribe> ACTION: fjh to ask Magnus/Microsoft about Generic Hybrid Cipher implementation/interop [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-694 - Ask Magnus/Microsoft about Generic Hybrid Cipher implementation/interop [on Frederick Hirsch - due 2010-11-08].
<scribe> ACTION: pdatta to update XPath profile from changes proposed during joint session with XSLT/XQuery [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action10]
<trackbot> Created ACTION-695 - Update XPath profile from changes proposed during joint session with XSLT/XQuery [on Pratik Datta - due 2010-11-08].
XML Encryption changes:
http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/explain.html
ECC, key derivation,
EXI markup
algorithms
RetrievalMethod
<pdatta> brich is doing an interop with PKBDF2 and ConcatKDF
<pdatta> but magnus's test vectors have some problems 1) IV missing,
<pdatta> 2) PKBDF2 default digest is SHA-1, but that is not what we are recommending, should be changed to SHA-2
<Cynthia> I would recommend SHA-256
<pdatta> 3) should not be using binary password as a best practice
<pdatta> PKCS5 spec explicitly says that one use should ASCII or UTF-8 password, not binary
<scribe> ACTION: magnus to update interop wiki with test cases for PBKDF2 and ConcatKDF, http://www.w3.org/2008/xmlsec/wiki/Interop [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action11]
<trackbot> Created ACTION-696 - Update interop wiki with test cases for PBKDF2 and ConcatKDF, http://www.w3.org/2008/xmlsec/wiki/Interop [on Magnus Nystrom - due 2010-11-08].
ACTION-696 closed
<trackbot> ACTION-696 Update interop wiki with test cases for PBKDF2 and ConcatKDF, http://www.w3.org/2008/xmlsec/wiki/Interop closed
<Cynthia> XML Encryption 1.1 Derived Keys
http://www.w3.org/2008/xmlsec/wiki/Interop#XML_Encryption_1.1_Derived_Keys
Example needs URI for SHA2
<scribe> ACTION: magnus to update ConcatKDF for SHA2 URI [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action12]
<trackbot> Created ACTION-697 - Update ConcatKDF for SHA2 URI [on Magnus Nystrom - due 2010-11-08].
<pdatta> key derivation examples are not related to Elliptic curves
<pdatta> tlr: we had key derivation before in DH
<pdatta> fjh: there is value in key derivation, without ecc
question, can we interop ECDH key agreement in xml encryption. Oracle intends to, is Microsoft implementing and interoping this.
ACTION-694: interop ECDH key agreement in xml encryption
<trackbot> ACTION-694 Ask Magnus/Microsoft about Generic Hybrid Cipher implementation/interop notes added
ACTION-695: interop ECDH key agreement in xml encryption
<trackbot> ACTION-695 Update XPath profile from changes proposed during joint session with XSLT/XQuery notes added
possibly mark ECKeyValue as at risk, unless we have 2 interops, need test cases
<scribe> ACTION: tlr to check with sean on ECKeyValue [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action13]
<trackbot> Created ACTION-698 - Check with sean on ECKeyValue [on Thomas Roessler - due 2010-11-08].
<tlr> action-698?
<trackbot> ACTION-698 -- Thomas Roessler to check with sean on ECKeyValue -- due 2010-11-08 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/698
<tlr> action-698?
<trackbot> ACTION-698 -- Frederick Hirsch to check with sean on ECKeyValue -- due 2010-11-08 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/698
<pdatta> NIST Suite B - needs ECDSA, ECDH and AES-GCM
<scribe> ACTION: pdatta to update interop wiki with suite B organization [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action14]
<trackbot> Created ACTION-699 - Update interop wiki with suite B organization [on Pratik Datta - due 2010-11-08].
<Cynthia> Agreed, do we have test cases for these, I thought we did, but I don't see them
Signature Properties
http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/Overview.html
<pdatta> fjh: widget does not implement all the signature properties
<scribe> ACTION: fjh to review xml signature properties interop status re widget signature [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action15]
<trackbot> Created ACTION-700 - Review xml signature properties interop status re widget signature [on Frederick Hirsch - due 2010-11-08].
<scribe> ACTION: fjh to check with sean on status of implementations wiki [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action16]
<trackbot> Created ACTION-701 - Check with sean on status of implementations wiki [on Frederick Hirsch - due 2010-11-08].
DEREncodedKeyValue, OCSP, KeyInfoData
<scribe> ACTION: fjh to check with scott re interop, in particulars DEREncodedKeyValue, OCSP, KeyInfoData [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action17]
<trackbot> Created ACTION-702 - Check with scott re interop, in particulars DEREncodedKeyValue, OCSP, KeyInfoData [on Frederick Hirsch - due 2010-11-08].
bruce checking on OCSP support
<Cynthia> Let's continue , of course it's only 12:16
http://www.w3.org/2008/xmlsec/Drafts/c14n-20/#sec-Conformance-Profiles
reaching earlier consensus, must support defaults for 2.0 parameters, not planning to support profiles?
<pdatta> fjh: too confusion to have three conformance profiles
<pdatta> RESOLUTION: remove the section 2.2.1 completely
<pdatta> mjensen: propose that TrimTextNodes default to true
offers new benefits, as part of the new approach
<pdatta> pdatta: do we need to preserve compatibility with Exc C14N 1.0
<pdatta> pdatta: if we do no want Exc C14N 1.0, then we can remove TrimTextNodes, i.e. have TrimTextNodes=true all the time
<Cynthia> why don't we ask the vendors and users of C14N if it's important
<pdatta> pdatta: If we need Exc C14N 1.0, then we need to add back InclusiveNamespace
<pdatta> tlr: is it required fo C14N 2.0 to be able to emulate all previous canonicalization algorithms?
discussion of breaking change, not backward compatible C14N2, still have other c14N algorithms
<pdatta> tlr: compatibility with previous c14n algorithm is a non-requirement
<pdatta> brich: are we ignoring xml:space when we get rid of XMLAncestors
<pdatta> pdatta: do we need both form of prefix rewriting
<pdatta> tlr: how much bigger does the hash prefixes make the document
size of hashed prefixes can be a problem for web services or large documents
<pdatta> RESOLUTION: remove digest based prefix rewriting pending agreement on list (Call for Consensus)
<scribe> ACTION: fjh to send cfc on resolutions [recorded in http://www.w3.org/2010/11/01-xmlsec-minutes.html#action18]
<trackbot> Created ACTION-703 - Send cfc on resolutions [on Frederick Hirsch - due 2010-11-08].