See also: IRC log
<trackbot> Date: 01 June 2010
No announcement
http://www.w3.org/2010/05/25-xmlsec-minutes.html
Proposed RESOLUTION: Minutes from 25 May 2010 approved
RESOLUTION: Minutes from 25 May 2010 approved
tlr: nothing new in the last week
<tlr> tlr: might be time for a ping
cynthia: also concerned
fjh: I am concerned a bit about the time so a ping seems appropriate
fjh: two comments on EXI in Enc 1.1
LC-2386
http://lists.w3.org/Archives/Public/public-xmlsec/2010Jun/0002.html
Where appropriate, such as in the case of encrypting an entire EXI stream, the Type attribute may be provided and the Mime type adjusted appropriately, as in the following EXI encryption example:
<?xml version='1.0'?> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2009/xmlenc11#EXI' MimeType='application/exi'> <CipherData> <CipherValue> A23B45C56</CipherValue> </CipherData> </EncryptedData>
(Add to end of section 2.1.4, http://www.w3.org/TR/2010/WD-xmlenc-core1-20100513/#sec-eg-Arbitrary-Data )
fjh: should verify MIME type
fjh: asking to accept last call change
RESOLUTION: accept change for LC-2386
<scribe> ACTION: fjh to update xml encryption with change for LC-2386 [recorded in http://www.w3.org/2010/06/01-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-584 - Update xml encryption with change for LC-2386 [on Frederick Hirsch - due 2010-06-08].
LC-2387
http://lists.w3.org/Archives/Public/public-xmlsec/2010Jun/0003.html
It is application dependent how to process data of various types, or to signal errors in the case of unknown types.
(end of section 4.2)
section 4.1 says
If XML Encryption is used with an EXI stream [EXI], then Encryptors and Decryptors process content as for XML element or XML content processing, but taking into account EXI serialization. In particular, the encryptor will replace the XML element or XML fragment in question with an appropriately constructed EncryptedData element. The Decryptor will conversely replace the EncryptedData element with its cleartext XML element or XML fragment. Note that the XML document in
which the EncryptedData element is embedded may be encoded using EXI and/or EXI may be used to encode the cleartext before encryption.
tlr: would like to review, because of conflicting signals from EXI WG
bal: was expressing concern about possible conflict with earlier section
ACTION: tlr to review proposal For LC-2387 [recorded in http://www.w3.org/2010/06/01-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-585 - Review proposal for LC-2387 [on Thomas Roessler - due 2010-06-08].
<tlr> ACTION-585: http://www.w3.org/2006/02/lc-comments-tracker/42458/WD-xmlenc-core1-20100513/
<trackbot> ACTION-585 Review proposal for LC-2387 notes added
Null references, any changes for XML Signature 2.0?
http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0037.html
mjensen: XPath expressions with an error wouldn't raise a fault, and would simply pass back an empty reference
... most apps unlikely to detect this well
... Proposal is : put a sentence to XML Signature 2.0 stating that a reference to an empty nodeset MUST be treated as a fault.
<Cynthia> I agree with the proposal, makes testing more straight forward
bal: not limited to XPath, any transform with a null output would do this
mjensen: was focusing on 2.0 only, where we only have the XPath selection
... this proposal should be limited to 2.0 mode behaviour in 2.0, not the backward compatible 1.1 behaviour
fjh: is this a case we'd want to allow intentionally?
bal: maybe with a form signing app and the thing you sign isn't present, but you want to sign either way
bal: same issue with references
... was technically legal
... yes, the example is sign a element if there or not, hence might be sometime null
scantor: not sure there is a use case for a signature over null, related to see what you sign
... even if you get something back from selection, it might not be right, hence singling out empty case might not be appropriate
tlr: app may key off an element if present, or have default behavior if not
... also might sign regardless, as Brian said
... in the moment you assume something was signed but don't ensure what was signed, you have a problem
... seems like a generic problem, though there's a question as to whether this is so nasty to be flagged specially
... seems to me that a warning is appropriate, but not mandating a fault
... lean toward not calling out in spec, but understands the point
... warning is an implementation and policy decision, though
mjensen: if not a fault, maybe an option to signal this inside the Reference?
... prefer explicit indication of intent, e.g. flag if it signed content might be missing
tlr: another example: somebody by accident excludes all of a node's text but not the node itself, so you get an empty element
... seems like a slippery slope to describe one error risk normatively, but not others
... as soon as we support excluding anything, this opens up attacks
tlr suggests WG enumerate what can go wrong, and note that they should be tested for, in best practices or warning note
<tlr> "don't enumerate badness"
<tlr> I'm fine enumerating classes of badness in the BPs, but not in the normative language.
pdatta: also thinking about flag idea, should we generalize it to be able to express the size of the signed data?
... tlr and I agree, not normative language, but in best practices
... in the 2.0 mode each reference could have a size of the canonicalized data,
tlr: if you use XPath, and you can't process only the signed result, maybe you need to build in a "sanity" checking XPath to apply to the reference
<scantor> my position is to avoid sending a message that apps can avoid the step of examining what was signed
ACTION: mjensen to draft text about XPath risks for BP document [recorded in http://www.w3.org/2010/06/01-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-586 - Draft text about XPath risks for BP document [on Meiko Jensen - due 2010-06-08].
RESOLUTION: will not add normative language about XPath risks into Signature 2.0
http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0034.html
<scantor> I was just expressing opinions about the various methods proposed
meiko notes #4 is more complicated, involves expressing QNames twice etc
meiko prefers #1
can we mandate as in #3, prohibit QNames in XPath
scott notes could recommend or give guidelines
full list
http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0027.html
<mjensen> prefer #3, but we'll need fallback if #3 is not applicable
fjh: should discuss more on list
http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0067.html
for ISSUE-43
ACTION-543?
<trackbot> ACTION-543 -- Scott Cantor to make proposals for the last two points noted in ISSUE-43 comments -- due 2010-06-01 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/543
<scantor> proposing a pair of changes, one to prohibit mixed content in extension points for 2.0, the other to help people validate X509IssuerSerial
bal: sounds reasonable, should check back with our people
proposed RESOLUTION: accept X509IssuerSerial proposal from Scott Cantor
<scantor> I suggest that re: SerialNumber, we either agree to just fix it, or publish a non-normative copy with the fix so people have a version to use
proposed RESOLUTION: update 2.0 schema to change data type of the X509SerialNumber child element from "integer" to "string"
RESOLUTION: accept X509IssuerSerial proposal from Scott Cantor
RESOLUTION: update 2.0 schema to change data type of the X509SerialNumber child element from "integer" to "string"
pratik, are you able to put in the X509IssuerSerial text as proposed?
<scribe> ACTION: pdatta to add X509IssuerSerial text as proposed by Scott, http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0067.html [recorded in http://www.w3.org/2010/06/01-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-587 - Add X509IssuerSerial text as proposed by Scott, http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0067.html [on Pratik Datta - due 2010-06-08].
tlr explains how redirect from namespace URI to dated document works, explains that the redirect would eventually change to point to a new version, but the old versions linked via XML Signature 1.x would remain.
<tlr> http://www.w3.org/2000/09/xmldsig#
<tlr> redirects to: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd
<scribe> ACTION: pdatta to create 2.0 schema with X509IssuerSerial change [recorded in http://www.w3.org/2010/06/01-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-589 - Create 2.0 schema with X509IssuerSerial change [on Pratik Datta - due 2010-06-08].
http://www.w3.org/2008/xmlsec/wiki/Roadmap
CR Fall 2010, Signature 1.1,Signature Properties, Encryption 1.1, Generic Hybrid Ciphers
Last Call, Fall 2010, Canonical XML 2.0, XML Signature 2.0
tlr: going to CR can happen when LC is done
... getting out of CR is the problem
<tlr> ... and we need test suites during CR ...
<tlr> you don't need to worry *YET*
<tlr> :)
tlr: would be good to make sure any issues people have in mind are in the tracker
<scantor> I think the substantive issues are well tracked
mjensen: asking about relationship of XPath subset doc to 2.0 docs
tlr: has to be done "no later than" 2.0 docs
fjh: when we do the draft, we may get other groups coming to us asking for things
... getting ours out early would be good
... should add to the Roadmap, think pdatta has action to create it during next round of edits
<scribe> ACTION: pdatta to create separate XPath profile document (from XML Signature 2.0) [recorded in http://www.w3.org/2010/06/01-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-590 - Create separate XPath profile document (from XML Signature 2.0) [on Pratik Datta - due 2010-06-08].
<scribe> ACTION: fjh to add XPath profile document to roadmap [recorded in http://www.w3.org/2010/06/01-xmlsec-minutes.html#action10]
<trackbot> Created ACTION-591 - Add XPath profile document to roadmap [on Frederick Hirsch - due 2010-06-08].
fjh: Please indicate if you have any suggestions about the roadmap, approaches toward progressing interop or other concerns
[NEW] ACTION:
fjh to add XPath profile document to roadmap [recorded in
http://www.w3.org/2010/06/01-xmlsec-minutes.html#action10]
[NEW] ACTION: fjh to update xml
encryption with change for LC-2386 [recorded in http://www.w3.org/2010/06/01-xmlsec-minutes.html#action01]
[NEW] ACTION: mjensen to draft
text about XPath risks for BP document [recorded in http://www.w3.org/2010/06/01-xmlsec-minutes.html#action04]
[NEW] ACTION: pdatta to add
X509IssuerSerial text as proposed by Scott,
http://lists.w3.org/Archives/Public/public-xmlsec/2010May/0067.html
[recorded in http://www.w3.org/2010/06/01-xmlsec-minutes.html#action06]
[NEW] ACTION: pdatta to create
2.0 schema with X509IssuerSerial change [recorded in http://www.w3.org/2010/06/01-xmlsec-minutes.html#action08]
[NEW] ACTION: pdatta to create
separate XPath profile document (from XML Signature 2.0)
[recorded in http://www.w3.org/2010/06/01-xmlsec-minutes.html#action09]
[NEW] ACTION: tlr to review
proposal for LC-2387 [recorded in http://www.w3.org/2010/06/01-xmlsec-minutes.html#action02]
[End of minutes]