XML Security Working Group Teleconference
07 Apr 2009

 

 

<trackbot> Date: 07 April 2009

Administrative

<fjh> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0019.html

<fjh> Scribe: Gerald Edgar

<fjh> Reminder, no meeting next week, 14 April

<fjh> next meeting, 21 April 2009, Kelvin Yiu is scheduled to scribe

<fjh> 21 April, John Wray is scheduled to scribe.

<fjh> 5 May, Bruce Rich is scheduled to scribe.

<fjh> Please complete F2F Registration (12-13 May) Questionnaire

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

<fjh> idget Signature published, please review in next two weeks.

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

Minutes approval

<fjh> Minutes from 31 March 2009, for approval:

<fjh> http://www.w3.org/2009/03/31-xmlsec-minutes.html

no objections were raised

RESOLUTION: Minutes approved for March 31

<fjh> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0019.html

Editorial update

<fjh> DER EncodedKeyValue proposal, ACTION-243 (Scott)

Scott: DER encoded status

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

It looked like all section refs were hard encoded.

scott: two note - ID Attrribute added to key value set

<tlr_> I thought we were not defining new Type URIs based on the notion that RetrievalMethod might be deprecated?

<fjh> correct base URL for new KeyInfo Type identifiers should be, so I left the value for DEREncodedKeyValue TBD.

FJH: We need to deprecate before dropping things.

Scott: is this related to the namespace URI

<tlr_> Yes, it was based on the namespace uri.

Scott: a need to "nail down" the URIs

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

Scott: in section 4.4 the name space URI was used - use the URI for the 1.1 schema

<scribe> ACTION: scott add retrieval method type URI for DER encoded keyvalue [recorded in http://www.w3.org/2009/04/07-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-255 - Add retreival method type URI for DER encoded keyvalue [on Scott Cantor - due 2009-04-14].

<fjh> scott note add to list at top of 4.4 as well, to also include new items

Change Explaination Draft

<fjh> Please review, provide text for changes subsequent to FPWD if possible

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

<tlr_> ACTION: Thomas to update xref note with addtl type Uris [recorded in http://www.w3.org/2009/04/07-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-256 - Update xref note with addtl type Uris [on Thomas Roessler - due 2009-04-14].

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

tlr: Review the signature work

<fjh> Please update the explain document in the signature 1.1 directory for any changes made since FPWD, the explain.html, not explain-fpwd

1.1 interop

tlr: nothing new - no discussion

1.1 Randomized hashing

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0033.html

fjh: adding a seed element

Brian: reviewing 2 NIST documents
... randomized hashing - it would be straight tforward to add, it could be added as an option

fjh: this was discussed at the workshop, it would make sense to add as an option, but there is little feedback

<fjh> konrad notes that randomized hashing is somewhat different than the proposal he made at workshop for signature with RSA-PSS

<fjh> konrad notes both would be useful

konrad: he is waiting for feedback

<fjh> konrad is asking whether such a hash can be reused, waiting for feedback

<tlr_> Design principle: if you can make things statistically independent, do so.

<fjh> konrad has had a few request

konrad: a random value for each ds:Reference and for ds:SignatureMethod
... a difference in the IBM proposal. a need to draft concrete markup

<fjh> tlr notes important to make items statistically independent, so need to use different random values in reference and signature method

tlr: he would like to set a default, a coupling between two parameters can cause problems

fjh: this is am implementation issue, how much work is conrad willing to do to put this in place?

<fjh> konrad notes define one for each reference and one for signature, note defaults, note random number for each independently

<fjh> this will require some important security considerations

<fjh> konrad notes he is seeking information on whether this is cryptographically secure

konrad: work need to be done to make sure this is cryptographicly secure

<scribe> ACTION: Konrad follow up and provide unified proposal for changes to support randomized hashing and signing [recorded in http://www.w3.org/2009/04/07-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-257 - Follow up and provide unified proposal for changes to support randomized hashing and signing [on Konrad Lanz - due 2009-04-14].

<klanz2> http://www.w3.org/2007/xmlsec/ws/papers/08-lanz-iaik/

1.1 Algorithms

<klanz2> http://www.w3.org/2007/xmlsec/ws/papers/11-mcintosh-ibm

fjh: web applications working group input- they did not want elliptic curve, [because of the] IP and implementation issues

<klanz2> ds:Reference level (Randomized Hashing): http://www.w3.org/2007/xmlsec/ws/papers/11-mcintosh-ibm

<klanz2> ds:SignatureMethod level (RSA-PSS): http://www.w3.org/2007/xmlsec/ws/papers/08-lanz-iaik/

<klanz2> my action is to unify the two proposals

fjh: an issue about what is mandatory

Geralde: I, as Boeing, am interested in having elliptic curve
... there are resources for scripting languages and EC (openSSL)

<klanz2> a second step would be to push back on checking wheather the salt in the various places may be substituted by using only one salt in all the places, as the main advantage of the salt is to move from an off-line attack to an on-line attack

<klanz2> I'll type this stuff into tracker as well

<fjh> gerald notes scripting languages, python has ability to use elliptic curve

Brian: OPenSSL has had support for a while

<fjh> bal notes useful to get feedback from web apps, they profile, so they could not require elliptic curve, even though sig does

Brian: web apps have a profile, they could state that all signatures use "X" in order to narrow the format of signatures
... there is no other candidate [than elliptic curve GWE] the rest of the US govt is not pushing it

<fjh> brian notes dsawithsha256 may not have much adoption

fjh:We should point to "Suite B"

<fjh> ACTION: fjh share with web apps pointer to suite b docs [recorded in http://www.w3.org/2009/04/07-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-258 - Share with web apps pointer to suite b docs [on Frederick Hirsch - due 2009-04-14].

Brian: the signatures have to be acceptable to the government
... point to the government (NSA) documents

tlr: a question, we are framing this as ECDSA as mandatory, but does this change if we constrain the curves

<fjh> tlr framing question as with prime curve as mandatory with other curves as optional

brian: what thomas says is important, we are only asking for 3 NIST prime curves

<fjh> bal only p256 is mandatory

brian: we are n ot asking for all elliptic cures, only p256 is mandatitory, this is imporant -

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

brian: at the end of 6.4.3 - in an editor's note - specifying which curves

RFC4051

<klanz2> http://tools.ietf.org/html/rfc4051

fjh: he was talking with Thomas - create a new RFC

tlr: to keep a cross reference as a crossreference - a seperate document

<fjh> tlr taken action to produce new document, rfc, for new material that is not in current RFC

tlr: see what we need to specify

konrad: what will be the action outcome?

brian: 4051 is a stds track doc

<klanz2> http://tools.ietf.org/html/rfc4051

<fjh> bal notes cannot supersede with informational rfc, but tlr notes can augment it

fjh: get the tecnical content to add what we want to say

tlr: defer this until we have a draft

brian: there is not a working group

<fjh> klanz asks how this will change from proposed standard to standard, if no working group

<fjh> tlr notes it was a personal working draft

<fjh> klanz asks that we need to clarify process

<fjh> klanz asks if additions can be made when it makes transition

tlr: the stardards (RFCs) are very loose
... not to worry about this just now
... the standards track is rarely used for RFCs he proposes a draft that augments 4051

2.0 C14N

fjh: 4 things to focus on

<klanz2> btw. to the second last topic ... PKIX SHA-2 with DSA/ECDSA

fjh: concrete goal of improve performance, simplify , algorithms,and referencing model
... work on simplification is needed for c14n
... put c14n on top of our priority, XRI went through c14n, they made a list of features that can be turned on and off, this can be a starting point.
... how to address c14n in an effective way is needed.
... to walk though the spec to see where we can improve it is an option

<fjh> konrad notes that exi material is highly schema dependent, may not wish to go to schema canonicalization

<fjh> konrad notes that we have to decide how far to go with canonicalization

konrad: how far do we want to go? can we paramerize it to make it more efficient? when we go to the level

of schema or not?

<fjh> Konrad notes we need to decide what needs to be normalized, based on what is shared

konrad: we have a range of options

<fjh> pdatta [Pratik] note performance is not too much of a concern, same as xslt transform to convert dom to sequence of byte

pdatta: if you are converting XML to bytes to perserve contents without C14N, serializing the DOM

<fjh> pdatta notes that baseline is serialization of dom without any canonicalization

pdatta: thereperformance impact of c14n is about the same as serialization
... nodeset expansion is a problem

Brian: there are perf and memory requirement complaints for C14N - there is a high overhead for a simple function

<fjh> bal notes current c14n does not address use case where bytes are transferred without requiring c14n

<klanz2> Minimal Canonicalization

<klanz2> http://tools.ietf.org/html/rfc4051#section-2.4

<klanz2> ;-)

brian: there is value in the different options. Semantic equvalents in a simple bytestream

brain: if you took 2 xml docs with the same semantics

<klanz2> http://lists.xml.org/archives/xml-dev/200403/msg00305.html the XML Author ;-)

<fjh> bal notes that current c14n not really canonicalizing, since prefixes are not handled

brian: is it a goal of feeding 2 semantically equvalent XML objects into this, will you get the same output?

<fjh> bal asks what is the goal of c14n, can tell semantically equivalent

<klanz2> The Trade-off in a table: http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#page=64

<fjh> ed notes should make two docs be equivalent if semantically equivalent

ed: a way to do this with namespaces - you will not go all the way with c14N

<fjh> scott notes whether true or not, hard to implement

Scott: people think it is hard to implement
... the implementations are impossible to figure out

konrad: the worst thing is that the bevaviour concerning the name space is a problem, a simple spec for each architecture

<fjh> klanz notes simple for simple case, as in appendix, but gets very complicated for edge cases

<fjh> klanz issue is whether namespace is in nodeset or not, makes it hard

<klanz2> http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#page=107

scott: we need to address what makes it hard, are the use cases for these important.

<klanz2> Namespace Nodes - A namespace node N is ignored if the nearest ancestor element of

<klanz2> the nodes parent element [O] that is in the node-set and has a namespace node in the

<klanz2> node-set with the same local name and value as N. Otherwise, process the namespace [. . . ]

<klanz2> That is the problem: "has a namespace node in the node-set"

pratik: a subtreecase would be simpler

<fjh> pratik notes it might be useful to provide an alternative text when dealing with complete subtree, much simpler to implement

<klanz2> Applications not using xml:base or simple inheritable attribute like xml:lang and xml:space or working with connected node-sets and having no QNames in

<klanz2> content will not experience any problems. Subsection 4.3.1 will discuss this in more detail.

<fjh> konrad reminds us bal mentioned levels, versus detailed algorithms, versus complete schema aware canonicalization

konrad: schema centric to minimal c14n, what should be optional?
... c14n and the datamodel, and the backround chapter on c14n

<tlr> ah, "minimal" canonicalization here means the 4051 minimal c14n

<fjh> p50 in thesis,re range of complexiyt

<tlr> *ever* canonicalization loses some content

<fjh> pratik notes subtree c14n could be same cheapness as serialization

pratik: c14n of a subtree could be as expensive as serialization - to do a simpler algorithm
... exclusions and inclusions makes it more complicated

<fjh> can we decide on items to rule out, obtain 80-20 rule? can we stick to On cases?

<fjh> konrad notes compatibility with XPath issue, namespace nodes available, but requires it also to be in nodeset, creating an issue

<tlr> I'd really like to see some spec text and code on these ideas

fjh: we need to put these thoughts out on the list.

tlr: we need a strawman implementation
... this is very abstract

fjh: we want to get results, but not to rush, to consider all our options. to address what Brian said about layering.
... not to get performance by simply not doing some things.

scott: not to limit ourselves to the simple case, and that interop is limited to the simple case

<scantor> what I really was saying is that the

<scantor> profiling approach of simplifying things makes interop a problem at times

<tlr> too complex for my taste

scott: thanks scott..

<fjh> bal notes that layering relates to how much interop is needed for 2.0 spec.

<fjh> konrad gave example of layering be switches in EXI C14N, features ranging from schema centric canonicalization to minimal

brian: to address the complexity isues and the interop - to turn things off selectively is one way, and what people are goring to implement is the other way.

<fjh> scott notes that we can remove more complicated material if it is not going to get implemented anway

fjh: we need to get concrete, but not to do something unnecessary

<fjh> pratik notes that c14n input matters depends on transform chain

fjh: can we ruthlessly siumplify c14n?

<klanz2> DOMSubTreeData

konrad: we can not get simplicity in all cases

<fjh> konrad notes error in assumption about input, that namespace is selected or not

<klanz2> http://www.w3.org/TR/xml-exc-c14n/#sec-Implementation

<fjh> pratik notes that c14n complexity depends on input and assumption

pratik: namespace node is associated with the xpath filter.

<fjh> pratik notes XPath filter can generate inputs that are complex

konrad: the chain of transforms is complicated

<fjh> scott notes XML namespace nodes are part of serialization of xml, but not need to be signed in own right , hence not select them

<fjh> scott select nodes wanted, then c14n should declare namespaces as needed

fjh: how to we turn this into what we can use?

<esimon2> Scott has inspired me with an idea that maybe we could simplify c14n by NOT requiring that the output of c14n be XML :-)

scott: we need to define use cases and determine what we can not do

<tlr> esimon2, that goes back to the 2007 workshop and HT's proposal there

<klanz2> remove the words "has a namespace node in the node-set"

scott: the c14n code ought to enable the sematics to get across

pratik: just removing this is not an option

<fjh> pdatta notes nodeset is issue

<fjh> chair asks that this conversation be on the list.

<fjh> pratik notes sample code would help

Scott: there is a need to explain why this is not an option

klanz2: send an email to the list about his propoal for the C14N spec change

<klanz2> same as http://www.w3.org/2008/xmlsec/track/actions/175

<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0012.html

<scribe> ACTION: klanz2 send an email to the list about his propoal for the C14N spec chang [recorded in http://www.w3.org/2009/04/07-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-259 - Send an email to the list about his propoal for the C14N spec chang [on Konrad Lanz - due 2009-04-14].

<scribe> ACTION: pdatta to respond to the proposed change [recorded in http://www.w3.org/2009/04/07-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-260 - Respond to the proposed change [on Pratik Datta - due 2009-04-14].

<klanz2> Can we close then Action-175 and substitute it with 259

Reference model

<fjh> chair requests for concrete proposals to deal with wrapping attacks, for example providing full path information in ds:Reference

<klanz2> http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#page=107

issue review

fjh: the group needs to review the issues to close

<fjh> please review items in agenda, if no comment on list will proceed on next call to close

fjh: unless there is feedback we will close these issues