- From: Thomas Roessler <tlr@w3.org>
- Date: Tue, 12 Aug 2008 16:13:44 +0200
- To: public-xmlsec@w3.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 UTC