XML Security Working Group Teleconference
07 Jul 2009

 

 

<trackbot> Date: 07 July 2009

/invite Zakim #xmlsec

<Cynthia> Meeting: XML Security WG Teleconference

Date: 07 July 2009

<Cynthia> Chair: Frederick Hirsch

<Cynthia> Scribe: Cynthia Martin

<Cynthia> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0006.html

<Cynthia> ScribeNick: Cynthia

Administrivia

<fjh> http://www.w3.org/News/2009#item113

<fjh> Candidate Recommendation of Widgets 1.0: Digital Signatures.

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0006.html

Fredrick: Meeting next week, Brad will scribe next week

<fjh> TPAC registration open

<fjh> Please register: http://www.w3.org/2002/09/wbs/35125/TPAC09/

<fjh> XML Security Thursday and Friday 5-6 November as originally planned.

Liaisons

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0074.html

Fredrick: RNG Schema, we need to identify some people to review/help with work on the Widgets 1.0 conformance testing- do we need to do this or only demonstrate interoperability?

<fjh> Candidate Recommendation of Widgets 1.0: Digital Signatures

<fjh> http://www.w3.org/News/2009#item113

Fredrick: Can we help them if they need it?

Announcements

<fjh> NIST "Transitions" presentation

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

http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0071.html

APPROVE minutes

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/att-0015/23-xmlsec-minutes.html

RESOLUTION: 23 June 2009 minutes approved

Editorial Status

<fjh> ACTION-142?

<trackbot> ACTION-142 -- Brian LaMacchia to come up with identifiers and add to the algs doc for the new DSA algorithms -- due 2009-01-20 -- PENDINGREVIEW

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

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

<fjh> noted not defining 224

Brian: One additional identifier, with explanatory text, optional to implement
... No key length for RSA or DSA in the identifiers

Fredrick: ID in the Interoperability file name for testing instead

Thomas: Comment- Update to algorithm

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0013.html

Brian: ... 3b) XML Signature 1.1, Section 6.3.1 to resolve ACTION-320, Brian

ACTION-320

<fjh> ACTION-320?

<trackbot> ACTION-320 -- Brian LaMacchia to draft language for HMAC section, 6.3.1 -- due 2009-06-23 -- PENDINGREVIEW

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

<klanz> Is this a constraint on verifiers as well

<klanz> what is the escalation

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

Konrad: Clarify the language on the constraints

<fjh> Brian notes were undefined in 1.1

<fjh> Brian hence it does not impact conformance

Brian: We didn't specify what conformance would be in that case (in 1.1)

Thomas: Is this a problem where the fix is worse than the problem?

<klanz> That was my language: http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/0002.html

<klanz> In the spirit of RFC2104 [HMAC]

<klanz> http://tools.ietf.org/html/rfc2104#section-5 :

<klanz> > Applications

<klanz> > of HMAC can choose to truncate the output of HMAC by outputting the t

<klanz> > leftmost bits of the HMAC computation for some parameter t (namely,

<klanz> > the computation is carried in the normal way as defined in section 2

<klanz> > above but the end result is truncated to t bits).

Brian: If you zero pad, is the padding at the beginning or the end?

<klanz> http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/0002.html

Konrad: Deal with differentiation.

<klanz> <klanz> Issue 105 and action 297 are actually now on Brian to follow up on http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/0002.html

Fredrick: Information not found in minutes, Brian did what WG wanted

<klanz> http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/att-0015/23-xmlsec-minutes.html

Fredrick: May need to consolidate some of the actions

Konrad: Would have preferred that it be in increments of 8

Brian: Under the old specification, we did not have this defined

<fjh> Brian notes original spec was not interoperable because padding was not clearly defined

Brian: You cannot ignore a partial byte, need to verify the bits in the truncation

Konrad: No strong opinion on this

Fredrick: Let's not spend additional time, send it on the list if it is important
... If there is serious objection, it must be on the list

ACTION-319?

<trackbot> ACTION-319 -- Kelvin Yiu to and Brian to update DH & ECDH sections to take advantage of new KDF section -- due 2009-06-23 -- PENDINGREVIEW

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

<fjh> action-319?

<trackbot> ACTION-319 -- Kelvin Yiu to and Brian to update DH & ECDH sections to take advantage of new KDF section -- due 2009-06-23 -- PENDINGREVIEW

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

Brian: Sent information on list, but it was later in the day

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

Brian: Refactor the section to handle KDF

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm#sec-DHKeyAgreementNewKDF

Brian:This is updated in revision 1.30: DH key agreement section now split into new and legacy KDF sections.
... Absence or presence of KA-Nonce is the trigger between the two options.
... Require this for interoperability to support new and legacy KDF

Fredrick: Is there no way to do this without a nonce?

Brian: That is correct
... Should be looking at the XML Encryption Schema

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm#sec-Alg-KeyAgreement

Brian: The nonce and digest method were under the any
... You have to know the key agreement algorithm before you know anything else
... I had back conversations with Kelvin, came up with this to distinguish between new and legacy

Fredrick: What about using an attribute?

Brian: No, we don't want to mess with the schema

<fjh> Scott: could use two different algorithm URIs

Kelvin: If you define a new URI (DH with mode), it would benefit this

Fredrick: Rather to be more specific

<scantor> don't feel strongly. but I think a second URI is slightly cleaner

Fredrick: If we create a new URI, we are splitting it and maintain the old one for backward compatibility

Kelvin: Benefit of new URI, better for new applications

Brian: Could be restructured, the old ID must use the legacy KDF and the new would not
... This would not be a huge change, it would be ok

Fredrick:We don't have to find the nonce

Brian: Would still have to support both (any)
... Happy to make that change, and define new KDF for that

<fjh>Continued discussion to use new URI for new KDF dh so that not rely on presence of nonce to determine approach

<fjh> benefit that old implementation won't break on new form when nonce is not present, yet URI the same

<fjh> I believe it is better to be explicit where we can

<Cynthia> ACTION: Brian to update ACTION 319 for explicit URI [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-326 - Update ACTION 319 for explicit URI [on Brian LaMacchia - due 2009-07-14].

ACTION-283?

<trackbot> ACTION-283 -- Thomas Roessler to update algorithm xref draft to note new status of sha-1 -- due 2009-05-19 -- OPEN

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

<fjh> action-283?

<trackbot> ACTION-283 -- Thomas Roessler to update algorithm xref draft to note new status of sha-1 -- due 2009-05-19 -- OPEN

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

<fjh> action-283 closed

<trackbot> ACTION-283 Update algorithm xref draft to note new status of sha-1 closed

<fjh> notes on using XMLSpec tool

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/0013.html

<klanz> did you add it to the members page?

<klanz> the xmlspec intro

DSS security consideration changes

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0005.html

Fredrick: Brian updated the DSS security warning, Cynthia sent out comments

<fjh> Add "bits" in two places in "defined to be 1024, 2048 or 3072 and

<fjh> the corresponding DSA q value is defined to be 160, 224/256 and 256

<fjh> respectively" yielding "defined to be 1024, 2048 or 3072 bits, and the

<fjh> corresponding DSA q value is defined to be 160, 224/256 and 256 bits

<fjh> respectively

<fjh> in 2nd paragraph change "required" to "requires"

RESOLUTION: Accept changes for Action 283

<Cynthia> ACTION: Update Action 283 [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action02]

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

ACTION-325?

<trackbot> ACTION-325 -- Cynthia Martin to propose changes to Signature references -- due 2009-06-30 -- OPEN

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

Cynthia: Yes, I am still working on it, I hope it will be done today

<fjh> ACTION: bal to update DSS security warning [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-327 - Update DSS security warning [on Brian LaMacchia - due 2009-07-14].

ACTION-324?

<trackbot> ACTION-324 -- Cynthia Martin to review http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/att-0044/xmlenc-ref.html for normative and informative -- due 2009-06-30 -- CLOSED

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

<fjh> update references in XML Encryption 1.1

Fredrick: Cynthia sent out comments to the list

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/att-0044/xmlenc-ref.html

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0014.html

<fjh> move RIPEMD-160 reference to normative section , used in 5.8.5

<fjh> Move MIME reference to normative section, used for MimeType value definitions

Fredrick: Accept this and put it in draft

Cynthia: Comments are mostly related to RFC and link changes, no problems

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0047.html

RESOLUTION: Accept updates and recommended changes to XML Encryption 1.1 references

<fjh> ACTION: fjh to update xml signature references [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-328 - Update xml signature references [on Frederick Hirsch - due 2009-07-14].

Fredrick: Would like to publish at next call

Cynthia: Will have it done this week

Review and update XML Signature and XML Encryption explain documents

Fredrick: started to update the explanation documents, need to work

Cynthia: I can look at reviewing this and help you out

<fjh> ACTION: fjh review and update explain documents for xml signature and encryption [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-329 - Review and update explain documents for xml signature and encryption [on Frederick Hirsch - due 2009-07-14].

Ready to publish 1.1?

<fjh> ACTION: tlr to update algorithms doc per http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0013.html [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-330 - Update algorithms doc per http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0013.html [on Thomas Roessler - due 2009-07-14].

<klanz> Re ACTION-320: http://lists.w3.org/Archives/Member/member-xmlsec/2009Jul/0001.html

Updated since last published: XML Signature 1.1, XML Encryption 1.1,XML Security Algorithms Note, XML Security Generic Hybrid Ciphers (FPWD), Best Practices,XML Signature Transform Simplification: Requirements and Design

Fredrick: Where are we with the Security Generic Hybrid Ciphers (FPWD)
... Want to get this out of the way, finish it up

Brian: Put a second working draft out, should not be a final doc

Fredrick: This is dated, need to be clear on the public page

<fjh> http://www.w3.org/2008/xmlsec/Drafts/key-encapsulation/key-encapsulation.html

Fredrick: Need to look at roadmap to check publication dates
... Still open issues with this- may have to defer it and wait for comments
... agree to publish this next week, get it out for comments

Cynthia: Yes, sounds reasonable

C14 2.0 Draft

<fjh> http://www.w3.org/2008/xmlsec/Drafts/c14n-20/Overview.html

Fredrick: Sent comments to the list

Pratik: Review of draft, Canonical XML Version 2.0 is a major rewrite of Canonical XML Version 1.1 to address issues around performance, streaming, hardware implementation, robustness, minimizing attack surface, determining what is signed and more. It also folds the 2.0 version of Exclusive Canonicalization into same document

<fjh> I had a few questions and comments: http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0011.html

Pratik:Discussion on section 1.4.1 Performance

<fjh> comment - might want to mention qnames in context explicitly in requirements section

Pratik:Discussion on section 2.1 Data Model

<scantor> comment - I would add Simplicity to the title of the bullet on Robustness

Pratik:Discussion on section 2.2 Parameters
Instead of separate algorithms for each variant of canonicalization, this specification goes with the approach of a single algorithm, which does slightly different things depending on the parameters.

<fjh> Pratik notes that trimwhitespace could list nodes to trim, but now is simply true false

Pratik:Discussion on section 2.2 Parameters: prefixRewrite- how to assign values to prefix
... 2.2 Parameters: expandEntities- globabally define entities
... 2.2 Parameters: next four parameters- how to deal with special attributes

<Zakim> Thomas, you wanted to note that xml:id must not be inherited

Thomas: Emulate existing spec as a requirement

<klanz> how do you assure subtree and list of exclusion elements and attributes are so disjoint that there aren't any re-inclusions

Discussion on xml:id requirement- drop or not to drop

<tlr> +1 to the meta comment

Fredrick: prefer to drop it

Konrad: may not want to re-sign large data

Fredrick: don't want to have to re-calculate/re-sign

<fjh> proposal to drop xmlIdAncestors parameter

<fjh> Scott notes prefixRewrite could be dropped

<fjh> or asks why it was needed

<fjh> Pratik notes utility for java object conversions

Brian: Have to go through normalization of prefixes, not required

<fjh> Issue: is normalization of prefixes a goal for 2.0 c14n

<trackbot> Created ISSUE-136 - Is normalization of prefixes a goal for 2.0 c14n ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/136/edit .

Brian: Robustness issues- simplicity/interoperability

Fredrick: Profile this down, is that correct?

Pratik: yes

<fjh> Scott proposes simplification here

<fjh> +1 from tlr

Thomas: Worried if we have a large number of options/features, it may be a headache later

<fjh> Scott also notes more to test, try to reduce it all

Thomas: If we can ID parameters that are likely to be used in practice, make choice on parameters

<fjh> +1 to simplification

<fjh> klanz notes options needed for implementations that want certain features

Fredrick: Go through all possibilities on list and try to get things simpler

<fjh> Pratik notes qnames in content use case for full inclusive

Pratik: Full inclusive canonicalization, way of avoiding the problem, inclusive- don't have to think about it

<Gerald-e> WS-i Basic security profile specification uses "Exclusive C14N without comments for canonicalization"

Fredrick: Go on now

<fjh> Scott notes xsiTypeAware can be orthogonal to prefix rewriting

<fjh>Discussion on section 2.3.5

Pratik: 2.3.5 Other ideas considered
... 2.3.5- Have another parameter listing other element / attribute names that can have qnames, besides xsi:type. Or simply search all text content for qname.
... 2.3.5- Significant white space: Have a parameters listing elements in which whitespace is significant. Instead of listing individual element names, and entire target namespace URI can be specified, e.g. in many elements in xhtml namespace whitespace is significant

<klanz> I say: .... is say a prefix ?

Fredrick: Scanning for :

Pratik: This is difficult, may be prefix or data/text

<fjh> Hal notes could be URI

Konrad: There is a paper regarding this issue, can be solved, but not easily

Cynthia: Can we get a link/reference to this paper?

Thomas: A major rework of XML is complex and would take a long time.

<klanz> http://www.w3.org/2001/tag/doc/qnameids

Pratik: Finished with parameters, make a list of supported parameters

<klanz> sure, but if one does not complain there is never a change

<tlr> s/a long time/a very, very, very long time/

Fredrick: Do we need backward compatability to v1.0? Is it acceptable to break this?

Brian: Goal is functional parity not backward compatibility?

Fredrick: Will it be handled the same way- handle different cases differently

Pratik: Not difficult to support v1.0, may just ignore it (additional items)
... 2.3 Processing Model for DOM- string parser

<fjh> Pratik considering adding section for streaming but do not have standard for streaming to base on

Pratik:Discussion on section 2.3 Processing Model- The basic canonicalization process consist of traversing the tree and outputting octets for each node. The algorithm here is presented in pseudo code using a recursive function to traverse the tree.

<fjh> q_

<klanz> how do you assure subtree and list of exclusion elements and attributes are so disjoint that there aren't any re-inclusions ?

Pratik: Go through the processing models at a high level
... Section 3.1, 3.2
... Section 2.3.3- Added information, DOM concept
... Section 2.3.3 Namespace context- Hash table
... 2.3.4 Output rules

Fredrick: 2 questions- streaming use case, difficult to add to document as there is no standard to base it on

Pratik: Not sure how to put it in

Fredrick:Is this a problem or straightforward, it is an important use case

<klanz> what about SAX/Stax events agnostic of push pull

Pratik: Not a problem

Fredrick: Original spec was written in a straight forward model (procedures), are people ok with pseudo-code?

Scott: In favor of it but people will complain if it doesn't work

<scantor> that was scantor, not Brian, sorry

Frederick: Need to be clear on behavior

Fredrick: Using the xpath model, ,makes it somewhat more confusing

Thomas: Worried that if we only have pseudo-code, mixing implementation behavior with specification

Scott: Not against the idea, but may have issues, hard to find the text around the pseudo-code

Pratik: Most of the code will have reference, the information will remain exactly the same

Fredrick: When we have an example of an algorithm, you want wording (warning) to show intent not exact implementation
... next step- signature example

Brian: Is this a stand alone document? May be an issue

<klanz> If you read the bottom of http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0041.html you can see that declarative can be horrible as well

Konrad: In favor of pseudo-code approach, in the past there were few examples there the text was contradicting itself

<fjh> i think pseudo-code can be very useful for being clear as long as not taken as implementation

<fjh> klanz +1 to pseudo-code

<fjh> klanz need to decide what is normative

Cynthia: We need to add the warning text up front

<tlr> +1 to that structuring

Fredrick: Get down what we want now, look at the choices, then determine what we want

<fjh> let us take this work forward with what we have, look at pieces, then review normative language approach

Proposed New E07 for ISSUE110, "visibly utilizes"

Fredrick: When can this be worked?

Pratik: Next week

<klanz> how do you assure subtree and list of exclusion elements and attributes are so disjoint that there aren't any re-inclusions ?

Konrad: One comment on proposal, nodes of sub-trees, exclusion of attributes- sub-tree handling

Pratik: Have a solution (2.3.3.)

<fjh> request to Pratik to clarify constraints and behavior on inappropriate subtree inclusion

Exclusive Canonicalization Errata

<fjh> E02

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0075.html

<fjh> E07

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0076.html

Scott: Someone needs to look at the language[

<fjh> ACTION: Konrad to review E07 and E02 for Exclusive C14n [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action07]

<trackbot> Created ACTION-331 - Review E07 and E02 for Exclusive C14n [on Konrad Lanz - due 2009-07-14].

<Cynthia> ACTION: Konrad review wording http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0075.html [recorded in http://www.w3.org/2009/07/07-xmlsec-minutes.html#action08]

<trackbot> Created ACTION-332 - Review wording http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0075.html [on Konrad Lanz - due 2009-07-14].

<fjh> issue-7?

<trackbot> ISSUE-7 -- Can exi be used by xmlsec wg as part of solution -- OPEN

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

Issue discussions

<fjh> issue-9?

<trackbot> ISSUE-9 -- Review WS-I BSP constraints on DSig -- OPEN

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

<fjh> issue-7 closed

<trackbot> ISSUE-7 Can exi be used by xmlsec wg as part of solution closed

<fjh> addressed in C14n 2.0 draft parameter

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

<fjh> Scott notes work around for backward compatibility by providing library to map old APIs to new APIs

Actions

<fjh> http://www.w3.org/2008/xmlsec/track/actions/open

Scribe; Cynthia

<Cynthia> Scribe: Cynthia

<klanz> ran out of voip credit ... will stay on the chat

<klanz> do you want me to dial in again

Cynthia: Correct

Fredrick: Thomas: XML Security library?
... Believe we covered almost everything

Issues

<fjh> http://www.w3.org/2008/xmlsec/track/issues/open

Fredrick: did we forget anything?

<fjh> issue-134?

<trackbot> ISSUE-134 -- Camellia algorithm for section of 5.2 Block Encryption Algorithm and 5.6 Symmetric Key Wrap -- OPEN

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

Cynthia: Correct, it should be closed

<fjh> issue-134 closed

<trackbot> ISSUE-134 Camellia algorithm for section of 5.2 Block Encryption Algorithm and 5.6 Symmetric Key Wrap closed

<fjh> added to algorithms document

Fredrick: Time to stop call