See also: IRC log
fhirsch3:Welcome all
<fhirsch3> http://www.w3.org/2008/10/07-xmlsec-minutes
RESOLUTION: 10/07 minutes are approved
brich: want to confirm that it will be published as first working draft
bal: does publishing it start any w3c clock
tlr: no clock will be started
<klanz2> okay, with me
RESOLUTION: Group agrees to publish the Best Practices doc as First Public Working Draft.
<tlr> ACTION: Thomas to prepare Best Practices for publication [recorded in http://www.w3.org/2008/10/20-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-83 - Prepare best practices for publication [on Thomas Roessler - due 2008-10-27].
rdmiller: does he wait to send Best Practices to NSA
fhirsch3: wait to send doc until tlr has doc published
ACTION-73, Title, contents update (Magnus)
http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0029.html
bal: do we need a section on
assumptions?
... proposals to add a section between 4 and 5 for operational
environment assumptions
RESOLUTION: accept the change http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0029.html with the addition of the operational environment assumptions
Proposal for principles section
http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0074.html,
<fhirsch3> remove Specialized approaches optimized for specific use cases should be
<fhirsch3> avoided
<fhirsch3> change "security layer independent of a security layer" to "security layer independent of application layer"
fhirsch3: what are first class objects
<klanz2> With what respect is that important to us, maybe add a this means sentence ...
fhirsch3: XML Signature -> XML
Security
... first class object should be defined in the original
security doc
<tlr> http://www.w3.org/2008/xmlsec/Drafts/xmlsec-reqs/
<tlr> I think that Frederick was actually looking for this one: http://www.w3.org/TR/xmldsig-requirements
fhirsch3: would like to accept the proposal then edit it after.
RESOLUTION: Accept proposed principles section with the above edits
fhirsch3: may need to ensure we define requirements before we look a v.next
<scribe> ACTION: fhirsch3 edit proposed principles section [recorded in http://www.w3.org/2008/10/20-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-84 - Edit proposed principles section [on Frederick Hirsch - due 2008-10-27].
<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0011.html
<fhirsch3> csolc: sign byte ranges of binary document since some might change others not
<klanz2> like LZW
<fhirsch3> pratik: binary can be more complicated, depending on encoding
<fhirsch3> kelvin: preallocate p7 fill in for binary signing
<klanz2> @Juan Carlos, are there requirements from XAdES in PDF for ByteRanges?
<klanz2> .
<klanz2> fhirsch3: add why it's ByteRange and not BitRange ...
<klanz2> csolc, pleas add to your proposal ...
<klanz2> ACTION: csolc to update the proposal on a ByteRange Transform [recorded in http://www.w3.org/2008/10/20-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-85 - Update the proposal on a ByteRange Transform [on Chris Solc - due 2008-10-27].
<scribe> ScribeNick:csolc
chris will note why we are using byte ranges instead of bit ranges
<fhirsch3> tlr: add to requirement clarity on possible attacks with byte ranges
<fhirsch3> fhirsch3: please include in proposal note on not bit stream, possible limit
<Zakim> tlr, you wanted to note that Transforms are defined in terms of octet-streams, not bitstreams
<tlr> that's precisely my question
<fhirsch3> klanz: how are gaps handled, leave out or fill with 0s?
<tlr> fill with zeroes, fill with something that's given in the transform, produce output that's byte ranges encapsulated in ASN.1, ...
<fhirsch3> csolc: need to consider
<tlr> (just joking, re ASN.1)
<fhirsch3> klanz: pls add to proposal
<fhirsch3> jcreullas: filling with 0s is modifying document, is it not
<fhirsch3> csolc: transform defined, whether to 0 or compress etc
klanz2: suggests that we ensure proper defaults are defined
tlr: is there a use case for concat
<fhirsch3> tls notes signing excerpts vs concatenation
<fhirsch3> bal: concat effectively via multiple references
bal: terminal transforms?
Simple Signing Strawman requirements
http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0032.html
bal: lower level os stuff wants
the minimal set of dependency
... so if simple sign needs XPath, the more libraries you will
need
<fhirsch3> kelvin notes want to leverage platform, offer support at low level without pulling in xml libraries, no XPath etc
brich: you may require to set a
policy instead of a max length
... on the amount of data that is signed.
<fhirsch3> kelvin notes policy can be in doc rather than apps, since apps could differ
kelvin: the application tells the library the max amount of data that is allowed to be processed.
<fhirsch3> kelvin notes shred, DSObject can have unsigned items added at higher layer, can break signed items already existent
pdatta: asked about text nodes
<fhirsch3> item - policy in signature
<klanz2> Off Topic: Can someone taking care of our main page, take an action to update http://www.w3.org/2008/xmlsec/#lists and add "public-xmlsec-comments@w3.org" http://lists.w3.org/Archives/Public/public-xmlsec-comments/ , the need to do this is indicated by the following comment: http://lists.w3.org/Archives/Public/public-xmlsec-comments/2008Oct/0000.html
<klanz2> Off Topic continued, maybe also mention the old lists:
<klanz2> public-xmlsec-discuss@w3.org
<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-discuss/
<klanz2> w3c-ietf-xmldsig@w3.org
<klanz2> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/
bal: need to keep in mind about older libraries, how can the new format be supported by older processors
fhirsch3: this does duplicate a
number of the xades reqs
... declarative policy as part of the sig?
<klanz2> @tlr: shall http://lists.w3.org/Archives/Public/public-xmlsec-comments/2008Oct/0000.html be forwarded to
<klanz2> www-xml-canonicalization-comments@w3.org
<klanz2> http://lists.w3.org/Archives/Public/www-xml-canonicalization-comments/
<tlr> bal: Putting policy languages into these requirements is a can of worm.
<tlr> All: yes, and in the following way
<tlr> ACTION: Kelvin to clean up proposal http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0032.html [recorded in http://www.w3.org/2008/10/20-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-86 - Clean up proposal http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0032.html [on Kelvin Yiu - due 2008-10-27].
<tlr> fhirsch3: need to clarify policy-related requirement and why we don't want to do this
bal: may need to declare what are the capabilities of the application.
<fhirsch3> bal: will need to declare capabilities, relevant for simple low level, or higher level apps
<fhirsch3> bal: at sig generation time declare as part of sig, that sig adheres to part of std
<fhirsch3> bal: verifiers can declare portions they understand
<fhirsch3> jcc: etsi defined language for signature policy
<klanz2> @jcc do you have a link or reference ...
bal: would like to see levels for the profiles
<fhirsch3> bal: policy limited to statement adhere to level 0 profile, level 1 profile etc
klanz: public mailing lists are not easy access
<tlr> ACTION: thomas to add link to comment list to public page [recorded in http://www.w3.org/2008/10/20-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-87 - Add link to comment list to public page [on Thomas Roessler - due 2008-10-27].
<klanz2> Can you type, when you reconvene please ...
Joint Meeting with XForms (11:00 - 12:30)
John Boyer presentation
<fhirsch3> XForms security presentation in PDF at http://www.w3.org/2008/xmlsec/f2f-2008-10-20/xforms/XMLSignatures.TPAC2008.pdf
<Steeeven> "But what if I want to work offline"
<fhirsch3> johnboyer: odf two types, single standalone file or zip file with many resources
<fhirsch3> odf of presentation at http://www.w3.org/2008/xmlsec/f2f-2008-10-20/xforms/XMLSignatures.TPAC2008.odp
<fhirsch3> tlr notes zip issue related to widget signing spec
<fhirsch3> raman notes xml packaging a generic issue in w3c
<fhirsch3> john notes content.xml is main xml in document, enveloped signature
<fhirsch3> raman asks if xml base can be used
<Geald_Edgar> It sounds as though a detached signature has the potential of signing an information source that no longer exists
<klanz2> What is the URI scheme for Zip Files, is there one?
<fhirsch3> detached can only sign as binary opaque reference
<Geald_Edgar> So XML is detached as a separate unit within the ODF package, but it is included in the same information resource?
<klanz2> consider http://java.sun.com/javase/6/docs/api/java/net/JarURLConnection.html for referencing inside zip ... also
<Geald_Edgar> perhaps the XML signature itself is created as a detached signature, but it is attached withing the ODF file.
<fhirsch3> john boyer: reference refers to instance document not entire xforms environment
<fhirsch3> john boyer: using reference with no uri
john wants to sign the odf doc, and since the xml signature is part of the instance data if uri="" is used it refers to the data not the odf doc
see slides for details
<fhirsch3> john boyer notes at run time separate dom for recording instance data, separate document
<fhirsch3> tlr- what is base uri for instance document
<fhirsch3> john boyer - expect same doc reference, signature in instance document
<fhirsch3> john boyer notes after run time might be serialized back with intial larger document
john - there are 3 layers, Instance data, the Model and the instance form.
john - there is a difference between the runtime of the model and the serialized version.
john - since the signatures are being generated at runtime - the references are relative to the containing data dom.
<fhirsch3> john - separate dom for instance at run time, not serialized or incorporated until commit, ie. temporary data until accepted
raman - all information except state information is stored in the xforms model.
roman - custom functions must also be signed.
roman - there are custom libraries that can be loaded into xforms.
<fhirsch3> extensions functions are full XPath
<fhirsch3> john boyer application can define context for uri
john b - a reference without a uri points to the outer most document.
<fhirsch3> raman at save time, save original doc plus instance data, to enable restore
<fhirsch3> john boyer - eg save template and instance data
- instance data can be inline in the doc, fetched once at startup then stored inline, or saved in a remote source
<fhirsch3> ) defined in terms of original document, not data document...
<fhirsch3> here was defined...
<klanz2> maybe XProc would be good way to explain what is going on here ... ;-)
john b - issue with repeating content.
john b - section 4.4.3.3.4 xmlsig doc
scribe: input to the first
transform should be output of the referencing
... 4.4.3.3.1 confusion on the output of a non same document
reference. does it have to be an octet stream
<Steeeven> +46 is Sweden
<fhirsch3> john boyer - support for uri-less reference required, possible errata.
<fhirsch3> konrad - can you submit test cases?
<fhirsch3> bal - cannot mandate application specific feature, but should require it to be allowed
<klanz2> 4.3.3.4 ... The input to the first Transform is the result of dereferencing the URI attribute of the Reference element. ... 4.3.3.1 ... If the URI attribute is omitted altogether, the receiving application is expected to know the identity of the object. For example, a lightweight data protocol might omit this attribute given the identity of the object is part of the application context. This attribute may be omitted from at most one Reference in any particular SignedInfo, or Manifest. ...
<fhirsch3> bal - what is the interoperability point
bal - could add an implementation note
<fhirsch3> klanz your are asking that null can be passed to url resolver
<fhirsch3> klanz - should define own uri scheme in these cases, can then separate from work-arounds
fhirsch3 - may need a uri identifier for instance data
raman - could define odf:here()
<fhirsch3> avoid confusion of whether in instance data context or in committed merged document, need to be explicit with explicit URI
klanz: maybe should use xslt functions
john b - xslt is like poison. too complicated
john b - xslt is also an optional component to xml sigs
klanz - can xinclude be used to resolve the multiple doc issue
<fhirsch3> is it possible to simplify this
<fhirsch3> raman notes reflection of interactivity
<fhirsch3> john notes even with zip still want node set, still have here issue, even if not here function
<fhirsch3> concern with complexity, want to make security simpler, sounds complicated to have separate instance and documents, then merge and lose context.
<fhirsch3> john notes interactive document case works
fhirsch3 - is it possible for xforms not to use xpath in the signatures
<klanz2> is it XPath 1.0?
<klanz2> I'd presume so ..
<fhirsch3> john offers to summarize use case in terms of instance documents and original, serialization into single document, what is process, issues
<fhirsch3> also to summarize lessons from implementation and needs regarding here etc.
Thanks to the XForms WG
<jcruella> sorry, had problems with my laptop
Breaking for 1 hour lunch
<rdmiller> scribenick: rdmiller
bal: We need to clarify the application specific behavior og references that are lacking URIs
fhirsch3: We need to confirm that
signature verification requires a running XForms
application
... John from XForms to clarify the processing model and what
he needs from XMLSEC to support his implementation.
... Concern that the complexity of the XForms processing model
and goals seem to run counter to those of the XMLSEC WG.
<csolc> http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0033.html
bal: Reviewed 2 documents from NIST regarding Randomized Hashing and approved hash algorithms.
NIST SP800-106 Randomized Hashing
bal: We could use the randomization of content for references only.
<esimon2> Which schema? XML Signature's or XML schemas in general?
<fhirsch3> randomized hashing - modification of any hash alg to add randomization, NIST defines only for sig hash, could do for Dsig hashing
<fhirsch3> of input to content
<fhirsch3> bal - xml signature schema
<fhirsch3> currently define hash alg and any, could define element for salt
<fhirsch3> optional
bal: We would need to update ds:SignatureMethod.
<fhirsch3> group notes oaep only defined for encryption
RESOLUTION: Work on randomized hashing is a lower priority for the XMLSEC WG and will be deferred until there is a pressing need.
fhirsch3: At lunch there was a discussion about releasing a 3rd addition to address edition of algorithms.
tlr: If it affects conformance then it will need to at least be a minor edition.
<fhirsch3> Xu Guibao joined as observer
<fhirsch3> bal notes may want to deprecate sha1 in 1.1, or not but simply introduce new algs in 1.1
<fhirsch3> bal notes goal not to change namespace in 1.1
bal: We may want to recommend in v.next that old algorithms are not used and then deprecate them in a following version.
<fhirsch3> tlr if a future version, requires versioning, then need a new namespace is a reading of this
<klanz2> http://tools.ietf.org/html/rfc4051
<klanz2> http://www.w3.org/2001/04/xmldsig-more#
<klanz2> http://www.w3.org/2000/09/xmldsig#
bal: If something changes that breaks backward compatibility then it would require a new namespace.
tlr: Prepare a working draft for version 1.1 where we add algorithms and clarify the versioning policy.
<fhirsch3> clarify versioning in wd and see if that is acceptable to constituents, including possibly sha-1 deprecation
<bal> konrad, so is your point that additional algorithms have already been defined without revving the namespace?
<fhirsch3> jcc notes one doc of sig semantics and one for algorithms
<fhirsch3> jcc this avoids need to constantly change entire for algs
<fhirsch3> jcc, can you hear?
<esimon2> not well; I'm quite dependent on the IRC
<fhirsch3> exi has looked at xml security in more detail
<klanz2> Re, Algorithm Identifiers (Last Topic) :http://www.w3.org/2007/xmlsec/Group/track/actions/150
<fhirsch3> some future work is c14n work - use exi to improve performance
<fhirsch3> reduce what needs to be preserved for verification, e.g. leverage typed values
<fhirsch3> EXI has parameters , e.g. preserve comments, similar to c14n
To improve performance canonicalization with EXI could require the use of some parameters.
<fhirsch3> EXI encoding for encryption - need to specify that encrypted content is exi encoded, encoding attribute
URIs for canonicalization algs when using EXI.
<fhirsch3> possibly using exe for c1n
EXI could provide "type aware" canonicalization to improve performance.
<fhirsch3> tom - test cases should be considered
<fhirsch3> tom wanting to integrate xml security testing into exi testing, thinking about what is involved
<fhirsch3> tom effort involves university development
<tlr> university development?!
<tlr> don: do signatures survive EXI round-tripping?
<tlr> tlr: we do have signatures and signed documents that you could run through your tests.
<fhirsch3> bal - do two semntically equivalent xml docs do they serialize into two exi serializations?
<fhirsch3> steven, yes, when considering parameters
<brutzman> recap/summary: we have an exi test suite with a corpus of several thousand documents. will be looking to ensure we have sufficient set of encrypted and/or signed documents to properly test round-trip success and interoperability by various EXI processors.
<fhirsch3> steven, have option to preserve namespace info
tlr: XML Signature is dependent on which EXI parameters are used.
<tlr> ha! Excellent news!
<tlr> (I hadn't realized that EXI had done this piece of work.)
EXI is set to work with canonicalization and is documented in a best practices document.
<brutzman> EXI Best Practices relevant to security: http://www.w3.org/XML/Group/EXI/docs/best/exi-best-practices.html#security
<tlr> john: EXI has designed things to be compatible with existing canonicalizations, and there are sets of parameters which will not break XML Security.
<brutzman> EXI Impacts relevant to security: http://www.w3.org/XML/Group/EXI/docs/impacts/exi-impacts.html#xml-security
<tlr> ... we're now talking about forward-looking work that would permit use of EXI with Signature.
<fhirsch3> http://www.w3.org/TR/exi-best-practices/#security
Ed Simon looked at the EXI document and not the EXI Best Practices
fhirsch3: We should review EXI Best Practices.
jcruella: EXI is not caninocalization, but serialization of canonicalization.
<fhirsch3> best practice, how to use exi with existing c14n algs, using preserve parameters
<fhirsch3> john exi could be used as c14n alg in future, topic for joint discussion
<fhirsch3> john, preserving more in exi makes it larger
<fhirsch3> john, eg no need to preserve lexical values, gaining efficiency
<fhirsch3> jcc should signature cover tables
<fhirsch3> john, tables are implicit
<fhirsch3> john, part of stream
<brutzman> EXI Format 1.0, 6.3 Fidelity Options http://www.w3.org/TR/exi/#fidelityOptions lists Preserve.comments Preserve.pis Preserve.dtd Preserve.prefixes Preserve.lexicalValues
fhirsch3: What is the performance hit of using EXI for canonicalization because of having to use the EXI parser?
<klanz2> Is there something like in memory EXI as well that expands to APIs like DOM or XPATH on the fly?
<fhirsch3> question is whether the startup and shutdown time for EXI is too expensive when only performing single sign or verify...
<fhirsch3> answer is that schema load can take time, but exi is also able to save internal compiled form
john: Performance would be based on initial load and number of schemas used.
<fhirsch3> bal asks about memory footprint
<fhirsch3> john, string tables but can be limited
<fhirsch3> john, serialize xml doc or set of xml fragments, which are individual elements + attributes
<fhirsch3> bal cannot replace c14n with it directly due to input requirement, not a nodeset as input
<klanz2> Ordered NodeSet ....
<fhirsch3> bal possible issue if unparented nodeset allowed, would need to be considered
<esimon2> http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0005.html
<fhirsch3> ed asks re importance of native formatted signatures
<fhirsch3> ed, e.g. sign exi format without converting to xml for signing
<G_Edgar> I am wondering what might be the impact of "pluggable codecs" on this? I wonder since "pluggable codecs are negotiated."
<brutzmanXBC was predecessor of EXI group. XML Binary Characterization Use Cases http://www.w3.org/TR/xbc-use-cases
<fhirsch3> pratik - does exi preserve ordering
<fhirsch3> john, always preserves ordering of elements, not attributes
<scribe> ACTION: esimon2 to look at the EXI use cases [recorded in http://www.w3.org/2008/10/20-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-88 - Lookk at the EXI use cases [on Ed Simon - due 2008-10-27].
<fhirsch3> john, attribute order can be preserved as part of serializion, might need switch in EXI for writing out attribute order
<G_Edgar> Are attribute orders part of any Codec?
<fhirsch3> action 88 is on test cases
<fhirsch3> john, also keep track of encoding options
<fhirsch3> pratik canonicalization often last step to digest, hence space benefits may not be valuable
<brutzman> upon decompressing an EXI document, element order is preserved but attribute order is not (as specified in XML Infoset). nevertheless it is possible to reapply canonicalization upon recreation of the XML document from EXI. perhaps EXI should add a switch to preserve canonicalization upon decompression. this would seem to be necessary in order to preserve signature.
<fhirsch3> john, can serialize direct from model to exi, not necessarily via xml
<fhirsch3> ... hence faster
<fhirsch3> exi implementation can offer different modes, e.g. from DOM, SAX etc. open source exisits
john: EXI is not designed to be an in memory represenation but specific parts of the EXI strream can be referenced using self contained sub-trees.
<fhirsch3> john, exi is interchange format, can have self-contained subtrees, meetin requirements for random access
john: If not preserving namespace declarations EXI stores the qualified names direclty which is the full identity of the URI.
<fhirsch3> disallow plugabble codecs
<klanz2> Could we have some pointers to implemtations/Implementation Reports for EXI
<klanz2> I'd be interested finding one that offers a DOM API
<klanz2> http://lists.w3.org/Archives/Public/public-exi/2008Sep/0001.html
<jkangash> XBC use cases: http://www.w3.org/TR/xbc-use-cases/
john: Usecases are XBC and usecases are on the EXI webpage as part of the testing framework.
<csolc> note: for xmlsec to use EXI as a canonicalization alg, EXI would have to add as part of the spec a rule on what order attributes are written out.
fhirsch3: We may want to think
about using EXI for canonicalization and how it may improve XML
Signature performance.
... Case number 1 is increase XMLSec for instances that are not
aware of EXI.
... Case number 2 is to improve XMLSec within EXI.
<esimon2> Ideally, want to EXI doc before encrypting.
<klanz2> Re Previous Discussaion: There might be similarites between "transform primitives" and what EXI calls the things you do not care about ... http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0000.html
john: XML Enc may not be able to take advantage of the performance increase of EXI without significant pain.
<klanz2> [s1] <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
<klanz2> Type='http://www.w3.org/2001/04/xmlenc#Element'/>
<klanz2> [s2] <EncryptionMethod
<klanz2> Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc'/>
<klanz2> [s3] <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
<klanz2> [s4] <ds:KeyName>John Smith</ds:KeyName>
<klanz2> [s5] </ds:KeyInfo>
<klanz2> [s6] <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData>
<klanz2> [s7] </EncryptedData>
<klanz2> Maybe use another Algorithm Identifier
<klanz2> http://www.w3.org/2008/10/exi/xmlenc#tripledes-cbc
<klanz2> or similar
<fhirsch3> consideration of using mimetype attribute
<klanz2> http://www.w3.org/TR/xmlenc-core/#sec-EncryptedType
<fhirsch3> note two areas, 1st use of exi to improve xml security, here for c14n in signature worth consideration
<fhirsch3> second, integration with exi tighter
<fhirsch3> main pain point in exi is encryption due to size of cipherdata, from xml, here exi first then encryption would help
<fhirsch3> mimetype
john: EXI could possibly be used
with XML Enc as it is with a minor tweak to identify the
encrypted data as EXI.
... Mapping from XML for XML encryption to EXI is relatively
straight forward.
... the work to allow EXI as a canonicalization method should
benefit both the XMLSEC and EXI WGs.
bal: Supporting XML Enc within EXI will require a change to XML Enc, ref section 4.2.
fhirsch3: We understand how to
support EXI for XML Enc, but need to be mindful of
interoperability.
... We also need to work the W3C Rec process.
john: No current pressing need for EXI from the XMLSEC WG.
pdatta: We cannot use a MIME type directly.
fhirsch3: We were discussing using a new type element.
<pdatta> bal: EXI could define a new types EXIelement
<klanz2> http://www.w3.org/TR/xmlenc-core/#sec-EncryptedType
<pdatta> bal: this can be done outside XML Encryption spec
<klanz2> <attribute name='Type' type='anyURI' use='optional'/>
<klanz2> <attribute name='MimeType' type='string' use='optional'/>
<klanz2> <attribute name='Encoding' type='anyURI' use='optional'/>
<fhirsch3> discussion, use type attribute, uri defined by EXI team and processing rules
<pdatta> jakko: does EXI need both EXIelment and EXIContent, probably not because EXI does not propobably support mixed content , so only EXIElment is ok
fhirsch3: EXI should define the URI and processing rules for XML Enc support.
<brutzman> wondering, where is the test/examples corpus for XMLSEC mentioned earlier today?
<klanz2> Process decrypted data if Type is unspecified or is not 'element' or element 'content'.
<klanz2> 1. The cleartext octet sequence obtained in Step 3 MUST be returned to the application for further processing along with the Type, MimeType, and Encoding attribute values when specified. MimeType and Encoding are advisory. The Type value is normative as it may contain information necessary for the processing or interpration of the data by the application.
<klanz2> 2. Note, this step includes processing data decrypted from an EncryptedKey. The cleartext octet sequence represents a key value and is used by the application in decrypting other EncryptedType element(s).
<fhirsch3> in this case EXI) to interpret
<fhirsch3> if not element or elementcontent then exi can interpret
<fhirsch3> bal exi takes care of decryption, into dom then exi
<pdatta> bal: XML encryption spec says that if type is not element or content, then hand it back to application, is EXI the application ?
fhirsch3: Using EXI for canonicalization will require further work outside of this meeting.
<pdatta> john: three things a) using EXI for canonicalization, b) define new algorithm URI for EXI canoncailzation, c) new type for Encryption EXIelement
fhirsch3: Performance measurements regarding the use of EXI for canoniclaization would be helpful.
EXI does have a test framework for measuring compression and decompression that is a Java based framework.
It can measure both Java and C++
<tlr> ACTION: thomas to update homepage with information test suites [recorded in http://www.w3.org/2008/10/20-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-89 - Update homepage with information test suites [on Thomas Roessler - due 2008-10-27].
<brutzman> The EXI test corpus is online at http://www.movesinstitute.org/exi
<brutzman> The EXI test corpus is hosted at Naval Postgraduate School in Monterey
fhirsch3: It may make sense to have a joint EXI XMLSEC session at the next XMLSEC F2F (13-14 January 2009).
<brutzman> The EXI test corpus is based on Japex https://japex.dev.java.net - "Japex is a simple yet powerful tool to write Java-based micro-benchmarks."
<pdatta> john: In the case where the fidelity is not important - e.g. in web services an EXI bases canonicalization will be advantageous
fhirsch3: What is the benefit of EXI users to use EXI canonicalization?
<pdatta> bal: in web services fidelty is important - shred and reconstruct use cases
john: We have some information based on a customer experiment that was done in 2006.
fhirsch3: Do the benefits of using EXI for canonicalization outweigh the costs for adding everything needed to process EXI?
<pdatta> fhirsch3: Using EXI for canoncalization adds more dependent libraries - need to evaluate this
<brutzman> bye
<klanz2> Please find answer to Sue Hoylen's Question: http://lists.w3.org/Archives/Member/member-xmlsec/2008Oct/0011.html
<klanz2> http://lists.w3.org/Archives/Member/member-xmlsec/2008Oct/0012.html
<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-comments/2008Oct/0000.html
fhirsch3: The response looks reasonable.
RESOLUTION:
Konrad's response to Sue Hoylen is fine and Konrad will send
it.
... Add Hal's Web Services info into the requirements
doc.
<scribe> ACTION: kyiu to provide a draft for the requirements document of the simple signing requirements. [recorded in http://www.w3.org/2008/10/20-xmlsec-minutes.html#action10]
<trackbot> Created ACTION-90 - Provide a draft for the requirements document of the simple signing requirements. [on Kelvin Yiu - due 2008-10-27].
<scribe> ACTION: jcruella to provide a draft for the requirements document for long term signatures. [recorded in http://www.w3.org/2008/10/20-xmlsec-minutes.html#action11]
<trackbot> Created ACTION-91 - Provide a draft for the requirements document for long term signatures. [on Juan Carlos Cruellas - due 2008-10-27].
<tlr> http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0076.html
tlr: WebApps is writing a profile
of XML Signature for signing widgets.
... WebApps want to know what set of algorithms should be
mandatory?
<klanz2> http://tools.ietf.org/html/rfc4051
<klanz2> http://tools.ietf.org/html/rfc4051#section-2.1.2
<klanz2> http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#sha256
<klanz2> RSA-SHA256
<klanz2> http://tools.ietf.org/html/rfc4051#section-2.3.2
<klanz2> http://tools.ietf.org/html/rfc4051#section-2.3.6
<klanz2> ECDSA
<klanz2> RFC 4051 is PROPOSED STANDARD in http://tools.ietf.org/html/rfc4051 ...
<fhirsch3> http://www.w3.org/2008/xmlsec/track/issues/59
<scribe> ACTION: kyiu to make a proposal for Issue 59. [recorded in http://www.w3.org/2008/10/20-xmlsec-minutes.html#action12]
<trackbot> Created ACTION-92 - Make a proposal for Issue 59. [on Kelvin Yiu - due 2008-10-27].
<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-discuss/2008Mar/0000.html
<magnus> For HMAC, there are also some identifiers in RFC 4231
<klanz2> http://tools.ietf.org/html/draft-eastlake-additional-xmlsec-uris-00
<klanz2> that is the expired draft ...
<tlr> I propose seeking review by the IETF security directorate.
<klanz2> We MUST not forget about this one that was added to the expired draft ...
<klanz2> http://www.w3.org/2007/05/xmldsig-more#ecdsa-ripemd160
<klanz2> http://tools.ietf.org/html/draft-eastlake-additional-xmlsec-uris-00#section-2.3.6
pdatta: I recommend adding a table for recommendations regarding bit strength.
bal: I recommend not doing that and pointing to the relevant NIST doc.
<klanz2> can we make sure all the URIs and references we have here in the minutes, are revisited by the person taking the action of collecting this stuff
4051 covers all of the algorithms that are not covered elswhere, but does not point to the ones that are covered.
<fhirsch3> summary, can answer widgets re alg identifiers using sha256 uri from encryption for reference hashing and rsa-sha256 from 4051
bal: Who will implement the checks for WebApps?
fhirsch3: All actions items can be closed.
<klanz2> bye everyone ...
<magnus> q
Recessing until tomorrow morning.
<esimon2> bye
<jcruella> bye have a nice dinner !!
<klanz2> bye every one
<fhirsch3> recess until tomorrow, thank you
<fhirsch3> observers included Bede, Youenn, Herve, Xu