XML Security Working Group Teleconference
19 Aug 2008

 

 

<trackbot> Date: 19 August 2008

<fhirsch3> Chair: Frederick Hirsch

<scribe> ACTION: fjh to do something [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-33 - Do something [on Frederick Hirsch - due 2008-08-26].

trackbot, close ACTION-33

<trackbot> ACTION-33 Do something closed

<fhirsch3> Scribe: Pratik Datta

<fhirsch3> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0028.html

<fhirsch3> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0028.html

sure

<fhirsch3> registration for tpac - http://www.w3.org/2002/09/wbs/35125/TPAC2008/

<brich> brich is on another call, will call in in a few minutes, until then will participate via IRC, apologies

<scribe> ACTION: tlr to set up questionnaire for next meeting [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-34 - Set up questionnaire for next meeting [on Thomas Roessler - due 2008-08-26].

<fhirsch3> xades http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0003.html

<fhirsch3> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0028.html

<fhirsch3> XProc http://lists.w3.org/Archives/Member/member-xmlsec/2008Aug/0008.html

<scribe> ACTION: fjh to contact XML Processing WG [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-35 - Contact XML Processing WG [on Frederick Hirsch - due 2008-08-26].

<fhirsch3> Updated NIST drafts http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0027.html

<fhirsch3> Randomized Hashing for Digital Signatures

<pdatta> ACTION: bal to take a look at NIST document [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-36 - Take a look at NIST document [on Brian LaMacchia - due 2008-08-26].

<pdatta> TOPIC minutes approval

<fhirsch3> http://www.w3.org/2008/08/12-xmlsec-minutes.html

RESOLUTION: 12 August minutes approved

<fhirsch3> http://www.w3.org/2008/xmlsec/track/actions/pendingreview

Requirements

<pdatta> fjh: Principles will follow the same process as the Best Practices document

<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0005.html

<pdatta> bal: give more time for principles document

WS-Fed contact should be Mike McIntosh (IBM)

Segmenting requirements

Assumptions

<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0026.html

<pdatta> hal: alternative c14n suggestions also produce valid xml, but in a different format

see http://www.w3.org/2007/xmlsec/ws/papers/20-thompson/

(my point was made

<pdatta> hal: if you are transmitting the canonical form, then it needs to be valid xml

<pdatta> hal: we do need to document the assumptions for canonicalization

<pdatta> hal: make a strong distinction between assumptions and requirements - requirements dictate the environment

<pdatta> hal: simplesign also preserves namespaces, that is a requirement

<pdatta> .. but simplesign assumes that docment is not modified

<fhirsch3> hal: prefixes may be need to preserved for xquery and xpath

<fhirsch3> hal: identify rqmts for possibly changing, relaxing, specifically maybe namespace prefix preservation qnames in content

for the record, at least for xpath, it is an error for a QName to occur with a prefix that is not mapped to a namespace URI in context. see 2.3 in w3.org/TR/xpath

<fhirsch3> bal: cannot look at rquiremets in vacuum, abstractly. need to look at specific use cases. issue for first edition. need to look at classes of applciation.

<fhirsch3> bal: web services, document signing and long term storage

<fhirsch3> bal: credentials - token signing

<scribe> ACTION: scantor to write up scenario for simple sign [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-37 - Write up scenario for simple sign [on Scott Cantor - due 2008-08-26].

<scribe> ACTION: bal to enlist kelvin to write up scenarios he's interested in; split of classes [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-38 - Enlist kelvin to write up scenarios he's interested in; split of classes [on Brian LaMacchia - due 2008-08-26].

bal: document embedding scenarios are interested

<bal> and tokens embedded in documents

fjh: hal, how about starting to write some material about web service scenarios

hal: think there may be some materials available
... remember going through experience that exclusive worked great for SAML assertions, but it didn't work for web services

bal: the fact that tokens need to be self-contained and you don't want to inherit semantic changes -- what you just said is a prime example of that

<scribe> ACTION: hal to contribute web service related scenario [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action07]

<trackbot> Created ACTION-39 - Contribute web service related scenario [on Hal Lockhart - due 2008-08-26].

scantor: one of the big differences is need for compatibility
... in these use cases ...

<pdatta> I am still here

<fhirsch3> scott: different scenarios will have different needs for backward compatibility

<pdatta> fjh: timeline draft of requirements out next month

yes

<pdatta> bal, next week, start drilling down on certain scenarios

<bal> that was me actually

<esimon2> Got to go.

<pdatta> hal: analyse performance measurements

bal: will get ACTION-38 done no later than in two weeks

scantor: will get ACTION-37 done no later than next meeting

hal: time line for ACTION-39 is two weeks

csolc: happy to review what Brian does. Archival and work-flow are important. Also important to document long-time archival requirements.

<scribe> ACTION: csolc to solicit and contribute long-time archival requirements [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action08]

<trackbot> Created ACTION-40 - Solicit and contribute long-time archival requirements [on Chris Solc - due 2008-08-26].

<fhirsch3> csolc: workflow needs to be covered explicitly

hal: cover workflow; may or may not be same as WS
... There's probably a non-WS networking scenario that we need to deal with
... could see signed XML shipped over plain HTTP
... maybe a subset of WS

fjh: back to workflow -- chris?

<scribe> ACTION: csolc to solicit and contribute requirements and assumptions from workflow scenarios [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action09]

<trackbot> Created ACTION-41 - Solicit and contribute requirements and assumptions from workflow scenarios [on Chris Solc - due 2008-08-26].

<fhirsch3> fjh: hardware scenario?

Just so we don't forget it: One requirement currently is that we can canonicalize an arbitrary XML document.

<pdatta> tlr: there are no constraints on the input XML in the current c14n

<pdatta> tlr: a document can have relative URI references, which depend on the context.

<pdatta> .., if we don't need relative URI references, we don't need complicated xml:base processing

<scribe> ACTION: tlr to elaborate on "any document" requirement vs canonicalizing xml:base [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action10]

<trackbot> Created ACTION-42 - Elaborate on \"any document\" requirement vs canonicalizing xml:base [on Thomas Roessler - due 2008-08-26].

<bal> fyi, i'm going to have to go in about 10 min

<fhirsch3> possible scenario is signing web pages on web server

pdatta: support for arbitrary nodeset creates a lot of complexity
... xpath and moving around namespace nodes is painful

zakim

<pdatta> ACTION: pdatta write about constrained nodesets requirement [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action11]

<trackbot> Created ACTION-43 - Write about constrained nodesets requirement [on Pratik Datta - due 2008-08-26].

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

strawman minimal signature discussion

<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0024.html

<pdatta> scantor: xml namespace attributes make xsd invalid, there is no automatic way to deal with them

yep

<pdatta> scantor: xml: attributes are no different from any other attribute

(discussion about processing instructions)

bal: PI is kind of funny, not really data in the object model
... it's metadata that's somehow attached
... and if we'd left the schema a bit more open
... attributes would be a better way to do it
... but didn't leave it open

csolc: PI tells processor to do an operation in some way
... could get into situation where signatures might not verify

bal: off

<bal> bye all

<fhirsch3> tlr; xml 4th edition, pi not part of doc of character data, must be passed to application.

<fhirsch3> that is what I was trying to say before.

<fhirsch3> implementors agree that their implementations can handle pi's, but might ignore them

http://www.w3.org/TR/xml/#sec-pi

<fhirsch3> csolc: potential issue is that behaviour with pi might not match default behaviour without it, hence need to be clear on this

csolc: what the processing instruction indicates has to be what the signature grammar does

tlr: so what the PI says needs to be signed?

<fhirsch3> csolc: hence information in pi has to be redundant with information in signature

csolc: yes, and verify that the PI is correct

fjh: so we need to be careful how PIs are used
... issue with strawman?

csolc: I don't have one

fjh: so strawman might be in a good place

pdatta: discounting attributes -- but in many implementations, don't expect schema validity

<fhirsch3> pdatta: implementations do not expect to validate according to schema so could use attributes

scantor: can't write a spec that creates schema-invalid XML

<fhirsch3> we already have validation issue with enveloped signatures

pdatta: wsu:id can be anywhere in the document?

scantor: it could be anywhere in the schema
... that's the problem with it ...
... use proper extensibility points
... Signature schema would need to be much loser than it is
... could have evolved more comfortably if signature had been more loose

<fhirsch3> is schema validation a requirement?

scantor: need to be *very* clear that you can't expect schema validation of signed documents

<pdatta> scantor: if we go with approach, need to make it very clear that schema validation is not possible

scantor: lots of advantages to using them, if they get us around the problem

<pdatta> tlr: two discussions - one ability to extend the XML Signature schema

<fhirsch3> tlr: ability to expand xml signature schema, maybe can define schema with new extension points

<fhirsch3> ... will implementations break if new attribute extension point?

<pdatta> tlr: look at some implementations to see what extent they may break if there are new extension points

<fhirsch3> ... question2 - schema interaction, place to get this fixed could be in schema

<fhirsch3> +1

<fhirsch3> I aleady have this action to ask xml schema wg about this

scantor: heard people argue for layering things so you verify signatures, undo, then validate

<pdatta> fjh: xml schema could be extended so that it can do signatures and encryption in a special way

<pdatta> ACTION: fjh to send email on ordering and layering of xml signatures [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action12]

<trackbot> Created ACTION-44 - Send email on ordering and layering of xml signatures [on Frederick Hirsch - due 2008-08-26].

scantor: about changing that schema -- think long and hard about it, people have been hurt while trying

BEst practices

<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0000.html

<pdatta> talk about brad's changes next week

<fhirsch3> please review and send comments on list before next call

<fhirsch3> plan to approve those changes on that call

Simple sign

<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0021.html

scantor: suggest we wait till I complete my action item about the scenario

Issues list

<fhirsch3> action-2 open , donald eastlake is looking it it, still open

<pdatta> action-4 open,

<fhirsch3> action-4 refers to joint Cannes meetings

<pdatta> action-5 open, fjh need to figure out

<pdatta> ACTION-7: CLOSE Mike McInstosh identified

<trackbot> ACTION-7 Informally liase with WS-Fed notes added

action-7 closed

<trackbot> ACTION-7 Informally liase with WS-Fed closed

<fhirsch3> ACTIO7 close

<fhirsch3> ACTION-7 close

<fhirsch3> ACTION-7 closed

<trackbot> ACTION-7 Informally liase with WS-Fed closed

<pdatta> ACTION-13 open

<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0021.html?

<pdatta> ACTION-16 open

<pdatta> ACTION 16, 19, 22 24, 25, 25 open

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

ACTION-32: no progress by 2008-08-19; expect to do it along with ACTION-30

<trackbot> ACTION-32 Document requirements and assumptions in simple signing strawman notes added

aob?

fjh: adjourned