W3C home > Mailing lists > Public > public-xmlsec@w3.org > August 2008

Meeting record: 2008-07-17

From: Thomas Roessler <tlr@w3.org>
Date: Tue, 12 Aug 2008 16:13:44 +0200
To: public-xmlsec@w3.org
Message-ID: <20080812141344.GA20099@iCoaster.does-not-exist.org>

Minutes from our meeting on 2008-07-17 were approved and are
available online here:

   http://www.w3.org/2008/07/17-xmlsec-minutes.html

A text version is included below the .signature.

-- 
Thomas Roessler, W3C  <tlr@w3.org>




   [1]W3C

                XML Security Working Group Face-To-Face Meeting
                                  17 Jul 2008

   See also: [2]IRC log

Attendees

   Present
          Bruce Rich, Subramanian Chidambaram, Brian LaMacchia, Hal
          Lockhart, Thomas Roessler, Frederick Hirsch, Konrad Lanz, Juan
          Carlos Cruellas, Chris Solc, Gerald Edgar, Sean Mullan, Rob
          Miller, Ed Simon, Magnus Nystrom, Pratik Datta, Anil Saldhana

   Regrets
   Chair
          Frederick Hirsch

   Scribe
          Bruce Rich, Chris Solc

Contents

     * [3]Topics
         1. [4]Review of Workshop Materials
         2. [5]XAdES
         3. [6]Widgets 1.0 Requirements review
         4. [7]Proposed Final Review of W3C TAG Finding "Passwords in the
            Clear"
         5. [8]XML 1.1 and XML Core update
         6. [9]Streaming
         7. [10]Profiles
         8. [11]Editing
         9. [12]compatibility
        10. [13]Closing the day
     __________________________________________________________________

Review of workshop materials

   Frederick going through some of things covered in workshop

   <fjh> [14]http://www.w3.org/2007/xmlsec/ws/slides/06-zhang-ximpleware/

   Essence is "Think bottom-up, rather than top-down"

   klanz: staying close to current spec language forced applications to be
   overly complex

   fjh: is it a tree model issue?

   bal: perhaps use case analysis would show a better way

   klanz: xpath accomodation is what makes c14n so expensive

   fjh: pre-xpath model might be what we look at

   bal: new c14n with not full compatibility with current might be
   strawman

   <fjh> might want to consider looking at original canonicalization
   before infoset version

   <klanz2> distibuting namespace declarations across the data model (i.e.
   the xpath data model)

   <klanz2> .. is the expensive part

   <fjh> klanz: XPath data model makes it expensive

   <fjh> klanz: one issue is spec language that forces more complexity of
   implementation

   <fjh> csolc: expensive to create copy of input data set

   fjh: EXI may need to enter discussion

   <fjh> issue - is there requirement to canonicalize/sign exi
   representation

   <fjh> issue - can exi be used by xmlsec wg as part of solution

   <fjh> issue - can spec be written to not rely on XPath data model and
   achieve same functionality

   <fjh> e.g. maintain context information for tree nodes using stacks

   looking at Ed Simon's position paper now

   perhaps should wait and see if Ed will join call later

   bal/klanz: family of c14n levels, select what is needed

   bal: could do at least a simple one and a more complicated one

   klanz: need to consider schema and non-schema aware as well

   fjh: does "infoset" introduce unnecessary complexity

   tlr: or is it only a vocabulary to talk about things

   bal: xpath selections were perceived as important
   ... xpath2 introduced more complexity?
   ... subsetting selection potential may help

   <fjh> issue: can we limit the generality of subsetting to reduce
   complexity, e.g. XPath 2.0

   <trackbot> Created ISSUE-3 - Can we limit the generality of subsetting
   to reduce complexity, e.g. XPath 2.0 ; please complete additional
   details at [15]http://www.w3.org/2008/xmlsec/track/issues/3/edit .

   klanz: c14n will still be slow if still accomodating full xpath2

   <fjh> asking about infoset generality, shorthand for need to create
   full model representing xml in memory and for processing

   hal: do some benchmarks with representative sample documents?

   <hal> specifically hotspot various implementations to see what is not
   worth optimizing

   <fjh> issue: need to allow transforms to go between octets and nodeset

   <trackbot> Created ISSUE-4 - Need to allow transforms to go between
   octets and nodeset ; please complete additional details at
   [16]http://www.w3.org/2008/xmlsec/track/issues/4/edit .

   <fjh> issue: which selections from subtree are required

   <trackbot> Created ISSUE-5 - Which selections from subtree are required
   ; please complete additional details at
   [17]http://www.w3.org/2008/xmlsec/track/issues/5/edit .

   fjh: postpone streamable nodeset discussion until afternoon

   bal, fjh, tlr: minimal c14n from early dsig work...old working draft?

   sean: some perf issues are really best practices issues

   fjh: ...discussion of xpath2 filter additions?
   ... ...propose a guest gives us more background on this?

   <klanz2> Minimal Canoniclaization:
   [18]http://tools.ietf.org/html/rfc3075#section-6.5.1

   <klanz2> Old XMLDSIG Drafts:
   [19]http://tools.ietf.org/html/draft-ietf-xmldsig-core-11

   <scribe> ACTION: fjh to ask for XPath 2.0 presentation to group
   [recorded in
   [20]http://www.w3.org/2008/07/17-xmlsec-minutes.html#action01]

   <trackbot> Created ACTION-11 - Ask for XPath 2.0 presentation to group
   [on Frederick Hirsch - due 2008-07-24].

   <bal> this is the first WD on C14N I could find:
   [21]http://www.w3.org/1999/07/WD-xml-c14n-19990729.html

   ISSUE: is there requirement to canonicalize/sign exi representation

   <trackbot> Created ISSUE-6 - Is there requirement to canonicalize/sign
   exi representation ; please complete additional details at
   [22]http://www.w3.org/2008/xmlsec/track/issues/6/edit .

   ISSUE: can exi be used by xmlsec wg as part of solution

   <trackbot> Created ISSUE-7 - Can exi be used by xmlsec wg as part of
   solution ; please complete additional details at
   [23]http://www.w3.org/2008/xmlsec/track/issues/7/edit .

   ISSUE: can spec be written to not rely on XPath data model and achieve
   same functionality

   <trackbot> Created ISSUE-8 - Can spec be written to not rely on XPath
   data model and achieve same functionality ; please complete additional
   details at [24]http://www.w3.org/2008/xmlsec/track/issues/8/edit .

   <fjh> konrad: what context is there besides namespaces

XAdES

   jcc: ...look at XAdES for best practices ideas

   <fjh> jcc: please do not redefine existing work

   bal: may be asked to do timestamps, should do like XAdES did

   <bal> XAdES defines some particular signed attributes that can be added
   to an XMLDSIG signature, along with a standard mechanism for adding
   signed & unsigned attributes

   jcc: presenting some XAdEs slides now in workgroup

   <bal> if we want to include a timestamp attribute, for example, might
   make sense to do it in an XAdES-compatible way

   jcc: XAdES defines containers for timestamps, not timestamps themselves
   ... no rqmts out of XAdES on DSig at this point

   <scribe> ACTION: jcc review archive from maint. group to revisit type
   issue [recorded in
   [25]http://www.w3.org/2008/07/17-xmlsec-minutes.html#action02]

   <trackbot> Created ACTION-12 - Review archive from maint. group to
   revisit type issue [on Juan Carlos Cruellas - due 2008-07-24].

   fjh: look at what BSP says about DSig

   ISSUE: Review WS-I BSP constraints on DSig

   <trackbot> Created ISSUE-9 - Review WS-I BSP constraints on DSig ;
   please complete additional details at
   [26]http://www.w3.org/2008/xmlsec/track/issues/9/edit .

   ISSUE: Perform c14n with a tree-walk rather than a nodeset

   <trackbot> Created ISSUE-10 - Perform c14n with a tree-walk rather than
   a nodeset ; please complete additional details at
   [27]http://www.w3.org/2008/xmlsec/track/issues/10/edit .

   <fjh> issue what would it take for XML Signature to be usable for Mail

   <fjh> issue: what would it take for XML Signature to be usable for Mail

   <trackbot> Created ISSUE-12 - What would it take for XML Signature to
   be usable for Mail ; please complete additional details at
   [28]http://www.w3.org/2008/xmlsec/track/issues/12/edit .

   <fjh> issue: what would it take to use XML Signature for structured
   non-XML content

   <trackbot> Created ISSUE-13 - What would it take to use XML Signature
   for structured non-XML content ; please complete additional details at
   [29]http://www.w3.org/2008/xmlsec/track/issues/13/edit .

   <scribe> ACTION: klanz2 Review streaming using 2nd edition Signature
   [recorded in
   [30]http://www.w3.org/2008/07/17-xmlsec-minutes.html#action03]

   <trackbot> Created ACTION-13 - Review streaming using 2nd edition
   Signature [on Konrad Lanz - due 2008-07-24].

   <tlr> ACTION-1 (new WG) closed

   <fjh> schema appears ok with existing interop tests

   <tlr> tlr: one of the test cases turns out to have an illegitimate
   xml:space value

   <tlr> ACTION-3 (new WG) closed

   <tlr> tlr: we heard back from the OOXML folks, and they don't like the
   style of the schema

   <tlr>
   [31]http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/0020.html

   <klanz2> I recalled there was an Issue around SignedInfo not having a
   chain of transforms it cannot be made robust against indention, besides
   using a custom canonicalization

   <tlr> trackbot, close ACTION-169

   <trackbot> ACTION-169 Produce updated cheat sheet closed

   <tlr> trackbot, close ACTION-8

   <trackbot> ACTION-8 Read this action's number closed

Widgets 1.0 Requirements review

   <fjh>
   [32]http://lists.w3.org/Archives/Public/public-xmlsec/2008Jun/0004.html

   fjh: working group members are welcome to review and comment

Proposed Final Review of W3C TAG Finding "Passwords in the Clear"

   <fjh>
   [33]http://lists.w3.org/Archives/Public/public-xmlsec/2008Jun/0002.html

XML 1.1 and XML Core update

   <fjh> tlr: XML 1.0 5th edition AC review has closed

   <fjh> klanz: implication, support for character sets for element and
   attribute names

   <tlr> status update:
   [34]http://lists.w3.org/Archives/Member/w3c-ac-members/2008AprJun/0065.
   html

   <fjh> tlr: XML 1.1 changes may be provided to XML 1.0

   <fjh> tlr: namespace undeclarations will have an impact - XML Core

   <fjh> issue: need to understand plans and impact of namespace
   undeclarations

   <trackbot> Created ISSUE-14 - Need to understand plans and impact of
   namespace undeclarations ; please complete additional details at
   [35]http://www.w3.org/2008/xmlsec/track/issues/14/edit .

   <fjh> need to know plan, timing for xml namespaces to effect 1.1

   <fjh> what will happen to namespaces going forward

   <fjh> ACTION: frederick to ask about namespaces/undeclarations in xml
   coordination group [recorded in
   [36]http://www.w3.org/2008/07/17-xmlsec-minutes.html#action04]

   <trackbot> Created ACTION-14 - Ask about namespaces/undeclarations in
   xml coordination group [on Frederick Hirsch - due 2008-07-24].

   <rdmiller> I just hung up and will not be participating this afternoon
   because of a prior commitment

   <csolc> Scribe: Chris Solc

   RESOLUTION: Thanks to Juan Carlos for hosting, providing excellent
   meals and logistics help.

Streaming

   fjh: use issues to track requirements for now

   <fjh> Created ISSUE-15 - Minimal caching to support streaming ; please
   complete additional details at
   [37]http://www.w3.org/2008/xmlsec/track/issues/15/edit .

   <fjh> Created ISSUE-16 - Backward reference for streaming - don't know
   what is referenced, algs ; please complete additional details at
   [38]http://www.w3.org/2008/xmlsec/track/issues/16/edit .

   <fjh> Created ISSUE-17 - Placement of KeyInfo relative to SIgnedInfo ;
   please complete additional details at
   [39]http://www.w3.org/2008/xmlsec/track/issues/17/edit .

   <fjh> Created ISSUE-18 - Data between algorithm info and digest? ;
   please complete additional details at
   [40]http://www.w3.org/2008/xmlsec/track/issues/18/edit .

   <fjh> Created ISSUE-19 - Placement of signature relative to signing or
   verification, different placement? ; please complete additional details
   at [41]http://www.w3.org/2008/xmlsec/track/issues/19/edit .

   <fjh> Created ISSUE-20 - Transform model should support streaming,
   filtering model ; please complete additional details at
   [42]http://www.w3.org/2008/xmlsec/track/issues/20/edit .

   <fjh> Created ISSUE-21 - Arbitrary selection from nodeset vs XPath
   expressions without backward references, traversal and navigation;
   please complete additional details at
   [43]http://www.w3.org/2008/xmlsec/track/issues/21/edit .

   <fjh> Created ISSUE-22 - Requirement to validate xml before application
   processing, signature processing, thus need to read entire document
   before processing, thus not true streaming ; please complete additional
   details at [44]http://www.w3.org/2008/xmlsec/track/issues/22/edit .

   pratik: ok to have whole doc in memory as byte array, enable
   validation. but avoid building DOM

   <EdS> Actually, I think it may be possible to create a streaming hash
   function (where one does NOT have to validate an entire document to
   have confidence in a portion of it) if one treats the document as an
   authenticated dictionary. This could be quite an intersting area for
   XML Signature. More on authenticated dictionaries here:
   [45]http://citeseer.ist.psu.edu/anagnostopoulos01persistent.html

   pratik: can verify document until the whole doc is streamed

   klanz: may need a streaming hash function.

   pratik: hard to-do nodesets without an XML DOM
   ... streaming doesn't provide much benefit for small docs
   ... can use two passes with streaming to collect data then verify.

   klanz: what is the advantage of two pass over using a dom

   <fjh> Created ISSUE-24 - Requirement for NodeSets ; please complete
   additional details at
   [46]http://www.w3.org/2008/xmlsec/track/issues/24/edit .

   <fjh> Created ISSUE-25 - Web services profile ; please complete
   additional details at
   [47]http://www.w3.org/2008/xmlsec/track/issues/25/edit .

   <fjh> pratik streaming presentation
   [48]http://www.w3.org/2007/xmlsec/ws/slides/12-mishra-oracle/Overview.p
   df

   pratik: nodesets imply dom, difficulty

   pratik: could an event stream be used instead
   ... example would be beginElement(...),,, text(..) endElement(...)
   ... problem1. some nodesets can't be represented by xml streams

   fjh: why are these problems: why do do we need these type of nodesets

   bal: XML Encryption WG had discussion - decided it did not make sense
   to encrypt attributes

   klanz: could require well formed XML between transforms

   <fjh> Created ISSUE-26 - Require well formed XML between transforms ;
   please complete additional details at
   [49]http://www.w3.org/2008/xmlsec/track/issues/26/edit .

   sean: this is related to compatibility

   <fjh> Created ISSUE-27 - Profile XML Signature spec to disallow removal
   of used namespace nodes from nodesets ; please complete additional
   details at [50]http://www.w3.org/2008/xmlsec/track/issues/27/edit .

   klanz: does this imply exclusive canonicalization?

   <fjh> Created ISSUE-28 - QNames? ; please complete additional details
   at [51]http://www.w3.org/2008/xmlsec/track/issues/28/edit .

   pratik: exclusive c14n doesnt solve anything, can get namespace
   declarations multiple times

   pratik: shouldn't allow removal of used namespace nodes

   <fjh> knowing it is used requires more work and look-ahead

   klanz: how nan you tell if a namespace is used if you are streaming,
   you need to look ahead

   pratik: would have to restrict xpath filtering to only look self and
   ancestors

   <klanz> I'm wondering whether we want a joint work on this with others
   doing XPath

   <fjh> xpath filter 2.0 easier to write since starting from root but
   need constraints and possible conversion

   sean: could define 3.0

   klanz: would others be interested to simplify xpath to work only on the
   current node instead of the whole doc.

   klanz: may need separate rec to gain visibility/adoption

   <fjh> Created ISSUE-29 - Able to run transforms in parallel (in general
   parallelism related to pipelining) ; please complete additional details
   at [52]http://www.w3.org/2008/xmlsec/track/issues/29/edit .

   <fjh> hard to anticipate use reason for multiple transforms, e.g. like
   unix pipes

   <fjh> Created ISSUE-30 - Limit XPath Filter transform to be first
   transform or to not use parent axis ; please complete additional
   details at [53]http://www.w3.org/2008/xmlsec/track/issues/30/edit .

   pratik: summary: can we get away without an dom?

   pratik: goal, not require DOM, hence with constraints/profile and
   events

   need an identifier to allow streaming

   <fjh> Created ISSUE-31 - Role for XML processing instruction, if any ;
   please complete additional details at
   [54]http://www.w3.org/2008/xmlsec/track/issues/31/edit .

Profiles

   <fjh> Created ISSUE-32 - How to identify profile, when, where. Not in
   signature but earlier? ; please complete additional details at
   [55]http://www.w3.org/2008/xmlsec/track/issues/32/edit .

   pratik: profile based on current assumptions for streaming
   implementations?

   <EdS> profile identifier would have to be signed, right?

   bal: may only support streaming for enveloping signatures

   <fjh> Created ISSUE-33 - Schema not validating when enveloped signature
   added and not included in original doc schema ; please complete
   additional details at
   [56]http://www.w3.org/2008/xmlsec/track/issues/33/edit .

   tlr: put some information early in the document -- maybe some XML tags

   bal: generic hint attributes in a Signature namespace?

   fjh: is this idea to have an additional atttribute in document start?

   klanz: processing instruction?

   bal: not a first class object

   klanz: well, maybe.......

   bal: want to look closely

   klanz: then various hack!

   sean: don't need an identifier for streaming if you use a two pass
   method

   <fjh> if element has attribute in xmlsec namespace to indicate that it
   needs to be included in signature

   <fjh> could be in xml namespace or xmlsec namespace (see xmlink)

   <fjh> ACTION: brian to provide proposal on xmlsec namespace approach to
   identify elements to be processed [recorded in
   [57]http://www.w3.org/2008/07/17-xmlsec-minutes.html#action05]

   <fjh> ACTION: bal to provide proposal on xmlsec namespace approach to
   identify elements to be processed [recorded in
   [58]http://www.w3.org/2008/07/17-xmlsec-minutes.html#action06]

   <tlr> ACTION: frederick to make bal to provide proposal on xmlsec
   namespace approach to identify elements to be processed [recorded in
   [59]http://www.w3.org/2008/07/17-xmlsec-minutes.html#action07]

   <trackbot> Created ACTION-15 - Make bal to provide proposal on xmlsec
   namespace approach to identify elements to be processed [on Frederick
   Hirsch - due 2008-07-24].

   klanz: processing instructions have the advantage of not invalidating
   schema's

   <tlr> ick, we don't have an extension point for adding attributes to
   ds:Signature

Editing

   fjh: need to contact thomas to get access to cvs

   jfh: could have Editorial teams
   ... members of that team don't have edit every doc

   each member of that team get credit even if some one on that team
   didn't work on a specific doc

   scribe: editor teams would have their own meetings.
   ... may want to have two versions of each doc. draft/working and WG
   approved
   ... wiki is an option for the working/draft doc

   klanz: could use inline editing

   tlr: rather not, and certainly not using "per-person tags"

   fjh: can make use of the mailing list to exchange text proposals if we
   make use of clear product and section indicators

   fjh: Please think about products that you want to define.

   [60]http://www.w3.org/2008/xmlsec/Group/Overview.html

   fjh: re editing, hope to maintain process so we get a proper issues
   list that's atctually tied to what editors do.

compatibility

   <tlr> ScribeNick: tlr

   fjh: "The Working Group is asked to consider the benefits of
   compatibility with the existing specification environment. If the
   Working Group decides to make breaking changes to one of the XML
   Security specifications, it will communicate such a decision broadly
   and early."

   klanz: progress vs maintenance -- breaking chagnes or not?
   ... charter says "please communicate changes early" ...
   ... think about criticism that there is need to rethink overall
   approach ...
   ... Peter Gutmann ...

   bal: Any breaking change is going to impact a large set of spec
   ... some of these consumers won't adopt a breaking change ...

   cruellas: there is a perception that Signature is more open, that leads
   to complexity ...
   ... profiling? ...

   <scribe> ... "new great thing" may not fly ...

   UNKNOWN_SPEAKER: compatibility is critical ...

   klanz: sell a basic profile as a profile, as a subset?

   bal: "Take your implementation, take these things out, and it's more
   lightweight" -- using extension points
   ... there's probably a bunch of features for which this works ...
   ... or a more radical break ...
   ... might have the more radical new version, or a variant that we rip
   some options out from ...

   klanz: synchronize into one document, not call it a profile

   bal: don't care

   klanz: when we constrain xpath, xslt... -- say "this enables us to do
   safer signatures"
   ...

   tlr: let's talk about the substance firrst, the perception then

   csolc: need benefit for adopters

   fhirsch: Feed-back at the workshop that people want simplification
   ... there's also no question that algorithm stuff is important ...

   bal: can do either a profile or a minor revision that doesn't breka
   back-compat
   ... straight forward ...

   csolc: referencing model without breaking backward compatibility?

   bal: That won't be all
   ... bundling question -- how to deliver certain features?
   ... smaller change, or bundle new features

   tlr: I suspect changes to the reference model will be breaking changes

   csolc: adoption by corporation
   ... couple new algorithms might not be enough ...

   klanz: inline data in certain places?

   klanz: xinclude use etc

   bal: Don't include dependencies on xml stack?

   klanz: also taking advantage of web archicture?

   bal: not everything in it!
   ... as few dependencies as possible ...

   tlr: XML Signature processors do not need to be xinclude aware at this
   point

   fjh: anything else useful that this leads us to?

   cruellas: what's the general leaning in terms of compatibility?

   fjh: what precisely does it mean?
   ... not sure we're there quite yet to understand that ...
   ... generation vs verification ...
   ... not sure we need to change schema?

   sean: Change namespace anyway?

   <fhirsch> Created ISSUE-34 - Review namespace versioning policy, define
   going forward ; please complete additional details at
   [61]http://www.w3.org/2008/xmlsec/track/issues/34/edit .

   tlr: I think ds:Reference is most brittle in terms of extensions; I
   think we need to look at that first in order to understand whether we
   have a breaking change on our hands.

   klanz: @@

   cruellas: don't chagne the namespace every time you need a new schema
   ... we're doing that in XADES ...

   klanz: new elements in new namespace?
   ... maintain some elements in old namespace?
   ... e.g. keyInfo ...

   <fhirsch> jcc: what is granularity of namespacing, can use old elements
   in old namespace

   klanz: avoid duplication of implementation code ...

   sean: That's radically different schema. Redesigning Java API is not
   going to happen.

   fhirsch: Move things around?

   sean: that might be ok
   ... add another method to return that element ...

   fhirsch: Change order of elements?

   <klanz> sean: would we have a new namespace for streaming nodesets?

   sean: the schema comes out in the API quite a bit

   fhirsch: API change?

   klanz: @sean: I think the namespace could remain the same as long as we
   can deal with only being able to dereference Nodesetdata/Octetstream
   data only.

   <fhirsch> tlr: to repeat what sean said, changes that are not exposed
   at api might be acceptable, but if apps that use API it might be an
   issue

   sean: Really change structure of Signature -- APIs would be a problem

   tlr: So change of namespace ok, if API addition is modular?

   sean: yeah keyInfo2 would be ok

   fhirsch: What if one couldn't use certain arguments?

   brian: Implementation approach would be to have flag associated with it
   "generate in constrained mode"
   ... so newer code could take advantage of constraints ...
   ... default might be getting the old, unprofiled version ...
   ... agree with sentiment that we're in relatively good place if we can
   do things without breaking API ...
   ... suspect that between the implementations here, we're very
   constrained in what we can do without breaking at least one of us ...

   klanz: I think the APIs are pretty similar
   ... JSR 105 rules ...

   brian: [we may not be able to make changes without breaking at least
   one implementation]

   klanz: ds2:Reference?
   ... just as a thought experiment ...
   ... anybody got a feeling?

   tlr: so you're talking about a change to the content model for
   ds:Signature that would not match the existing schema?

   fhirsch: I think I hear that most people in the room don't want to go
   more extreme
   ... I also wonder whether the nodeset stuff wouldn't be breaking APIs?
   ... this doesn't seem to actually be consistent

   brian: well, yeah

   bruce: I want to have cake and eat it too.

   fhirsch: Can we do that? /TR/REC-cake, /TR/REC-eating?

   brian: We might end up there, with two things
   ... Look at the algorithm issue ...
   ... there are plenty of folks there who are content (not happy) with
   dsig today
   ... except for algorithm ...
   ... they want things sooner than later ...
   ... existing implementations can rev with minor, non-breaking fixes
   relatively easily, ...
   ... hit marketplace ...
   ... if we go for new schema or new namespace, we're back to square one
   in terms of interop and work ...
   ... longer time, and you still have the existing stuff ...
   ... I saw that with TLS, and with S/MIME ...
   ... push for suite B -- demand was, just get the algos in there ...
   ... TLS went through baby step process ...
   ... guess what, we hardcoded MD5/SHA1 into pre-master secret ...
   ... we can't get rid of that ...
   ... suite B in 1.0, rev-ed 1.1, got rid of 1.2 which is breaking ...
   ... 1.0 and 1.1 out, everybody goes out to work on 1.2
   ... immediate need is on algorithms ...
   ... we might have to bite that bullet

   fhirsch: Risk is good enough to stop with first one?
   ... a lot of people wanted the maint WG do this

   klanz: Useful to formulate this into strategy?
   ... 1.1 and 1.2?

   <EdS> or 1.1 and 2.0

   fhirsch: If strategy is "just go for big thing" it might end up not
   getting deployed

   klanz: if there is a 1.1, 1.2 -- and a 2.0 where people will ask about
   compatibility
   ... why call it xml dsig 2.0 instead of foobar

   fhirsch: looking at milestones...

   brian: Keep going on requirements and identify what can be done in 1.1
   and what in 2.0

   fhirsch: So we can go through streaming and see where that can go

   cruellas: Feeling about market?
   ... or is this an implementors' issue ...

   fhirsch: Lots of input that sig is too expensive
   ... e.g. simpleSign ...

   cruellas: profiling?

   fhirsch, sean: their own thing

   cruellas: Try to determine what to target?

   brian: Look at what is addressible.
   ... we got a bunch of input, will get more ...
   ... some things will be easy ...

   klanz: If we want to do new XMLDSig it should have a new name be
   disruptive a proper substitution and quickly implemented.

   <klanz> Maybe have a processing instruction <?startdigest
   someAlgostuff?>

   <klanz> ... xml goes here

   fhirsch: Performance, canonicalization, algorithms, keyInfo

   <klanz> as a child of the same parent as of the starting PI:
   <?stopdigest disgestvalue .... ?>

   <fhirsch> looks like we should review requirements, note which could be
   implemented in 1.1 versus 2.0 change, public review of what is not in
   1.1, get feedback

   <fhirsch> maybe note that we can decide next step based on feedback

   <fhirsch> tlr: open content model allows updates to KeyInfo, also
   Transform model can use existing extension points to enforce properties

   <fhirsch> tlr: e.g. assertion transform (fails if assertion not true)

   <fhirsch> fjh: algs, performance/c14n, keyinfo clarity/usable

   fhirsch: Get rid of a bunch of junk, transforms, c14n -- that's one
   story
   ... c14n is actually a separate one ...

   subu: security -- DOS
   ... you get transformations that run out of control

   fhirsch: This relates to complexity and simplification

   tlr: Wrapping attacks? Sounds like References.

   fhirsch: Workaround from Mike? Transform assertions?

   bruce: You pay a price in complexity.

   fhirsch: Use profile for that?
   ... might also want a SOAP signature profile
   ... could include that point in this profile
   ... some stuff in minimalist profile

   <subu> WS - BSP was mentioned by Hal

   fhirsch: Evolving environment?

   tlr: maybe part of the success story there is keeping part of the
   environment from evolving

Closing the day

   fjh: next meeting in two weeks
   ... thanks for attending the face-to-face ...
   ... thanks to Juan Carlos for excellent hosting ...

   tlr: I think strawman proposals would be useful

   klanz: I'll be happy to write up an idea about reference
   ... URI is optional!
   ... pass stuff as parameter to a transform
   ... could do some enveloping signature

   brian: well that's not what it's meant for
   ... my object model would have a hard time with that ...
   ... need to be able to extract that ...

   <fhirsch> ACTION: klanz to write up proposal regarding use of transform
   that has parameter for passing xml model [recorded in
   [62]http://www.w3.org/2008/07/17-xmlsec-minutes.html#action08]

   <trackbot> Created ACTION-16 - Write up proposal regarding use of
   transform that has parameter for passing xml model [on Konrad Lanz -
   due 2008-07-24].

   fhirsch: Help with requirements would also be helpful

   adjourned

   <EdS> Thanks everyone.

   <anil> good evening all

   <anil> RRSAgent: miutes
     __________________________________________________________________

References

   1. http://www.w3.org/
   2. http://www.w3.org/2008/07/17-xmlsec-irc
   3. http://www.w3.org/2008/07/17-xmlsec-minutes.html#agenda
   4. http://www.w3.org/2008/07/17-xmlsec-minutes.html#item01
   5. http://www.w3.org/2008/07/17-xmlsec-minutes.html#item02
   6. http://www.w3.org/2008/07/17-xmlsec-minutes.html#item03
   7. http://www.w3.org/2008/07/17-xmlsec-minutes.html#item04
   8. http://www.w3.org/2008/07/17-xmlsec-minutes.html#item05
   9. http://www.w3.org/2008/07/17-xmlsec-minutes.html#item06
  10. http://www.w3.org/2008/07/17-xmlsec-minutes.html#item07
  11. http://www.w3.org/2008/07/17-xmlsec-minutes.html#item08
  12. http://www.w3.org/2008/07/17-xmlsec-minutes.html#item09
  13. http://www.w3.org/2008/07/17-xmlsec-minutes.html#item10
  14. http://www.w3.org/2007/xmlsec/ws/slides/06-zhang-ximpleware/
  15. http://www.w3.org/2008/xmlsec/track/issues/3/edit
  16. http://www.w3.org/2008/xmlsec/track/issues/4/edit
  17. http://www.w3.org/2008/xmlsec/track/issues/5/edit
  18. http://tools.ietf.org/html/rfc3075#section-6.5.1
  19. http://tools.ietf.org/html/draft-ietf-xmldsig-core-11
  20. http://www.w3.org/2008/07/17-xmlsec-minutes.html#action01
  21. http://www.w3.org/1999/07/WD-xml-c14n-19990729.html
  22. http://www.w3.org/2008/xmlsec/track/issues/6/edit
  23. http://www.w3.org/2008/xmlsec/track/issues/7/edit
  24. http://www.w3.org/2008/xmlsec/track/issues/8/edit
  25. http://www.w3.org/2008/07/17-xmlsec-minutes.html#action02
  26. http://www.w3.org/2008/xmlsec/track/issues/9/edit
  27. http://www.w3.org/2008/xmlsec/track/issues/10/edit
  28. http://www.w3.org/2008/xmlsec/track/issues/12/edit
  29. http://www.w3.org/2008/xmlsec/track/issues/13/edit
  30. http://www.w3.org/2008/07/17-xmlsec-minutes.html#action03
  31. http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/0020.html
  32. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jun/0004.html
  33. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jun/0002.html
  34. http://lists.w3.org/Archives/Member/w3c-ac-members/2008AprJun/0065.html
  35. http://www.w3.org/2008/xmlsec/track/issues/14/edit
  36. http://www.w3.org/2008/07/17-xmlsec-minutes.html#action04
  37. http://www.w3.org/2008/xmlsec/track/issues/15/edit
  38. http://www.w3.org/2008/xmlsec/track/issues/16/edit
  39. http://www.w3.org/2008/xmlsec/track/issues/17/edit
  40. http://www.w3.org/2008/xmlsec/track/issues/18/edit
  41. http://www.w3.org/2008/xmlsec/track/issues/19/edit
  42. http://www.w3.org/2008/xmlsec/track/issues/20/edit
  43. http://www.w3.org/2008/xmlsec/track/issues/21/edit
  44. http://www.w3.org/2008/xmlsec/track/issues/22/edit
  45. http://citeseer.ist.psu.edu/anagnostopoulos01persistent.html
  46. http://www.w3.org/2008/xmlsec/track/issues/24/edit
  47. http://www.w3.org/2008/xmlsec/track/issues/25/edit
  48. http://www.w3.org/2007/xmlsec/ws/slides/12-mishra-oracle/Overview.pdf
  49. http://www.w3.org/2008/xmlsec/track/issues/26/edit
  50. http://www.w3.org/2008/xmlsec/track/issues/27/edit
  51. http://www.w3.org/2008/xmlsec/track/issues/28/edit
  52. http://www.w3.org/2008/xmlsec/track/issues/29/edit
  53. http://www.w3.org/2008/xmlsec/track/issues/30/edit
  54. http://www.w3.org/2008/xmlsec/track/issues/31/edit
  55. http://www.w3.org/2008/xmlsec/track/issues/32/edit
  56. http://www.w3.org/2008/xmlsec/track/issues/33/edit
  57. http://www.w3.org/2008/07/17-xmlsec-minutes.html#action05
  58. http://www.w3.org/2008/07/17-xmlsec-minutes.html#action06
  59. http://www.w3.org/2008/07/17-xmlsec-minutes.html#action07
  60. http://www.w3.org/2008/xmlsec/Group/Overview.html
  61. http://www.w3.org/2008/xmlsec/track/issues/34/edit
  62. http://www.w3.org/2008/07/17-xmlsec-minutes.html#action08

-- 
Thomas Roessler, W3C  <tlr@w3.org>
Received on Tuesday, 12 August 2008 14:14:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:54 GMT