XML Security Working Group Teleconference
14 Jul 2009

 

 

<trackbot> Date: 14 July 2009

Administrivia

fjh: TPAC registration is open

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0022.html

<Cynthia> Approve

RESOLUTION: minutes from 7th July approved

KDF, KDF3

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0012.html

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0027.html

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0031.html

fjh: Review Magnus & Kelvin discussion on list

magnus: Kelvin has rasied point that KDF definition in some documents only refers to input string
... Input string components are defined as attributes, propose renaming our function KDF3 to make this clear
... but we are using SP800-56 standard format for the most part
... no strong preferences about name, except that it be somewhat short, and make it clear that is KDF from SP800-53
... algID component text updated in new version checked in this morning, some other components not specified at all yet, no way to do this interoperably, so provisional text added for these two components
... PartyU and PartyV info components
... more full definition probably still needed

fjh: would NIST doc help us with interop if referenced?

magnus: no, it doesn't define these components or how they are used

kyiu: NIST pushes this up to the application, may be fine to use standardized field in cert, maybe a hash of that component. No interop in NIST doc.

fjh: What about the name?

kyiu: KDF3 implies a more generic verison - this is very specific, prefer ConcatKDF or NISTKDF

magnus: KDF3 is actually defined in a number of documents, but maybe NISTKDF is fine if one can reference 800-56 to distinguish from other NIST KDFs

kyiu: ConcatKDF is used by other NIST people

<scribe> ACTION: magnus to update name to ConcatKDF [recorded in http://www.w3.org/2009/07/14-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-334 - Update name to ConcatKDF [on Magnus Nyström - due 2009-07-21].

fjh: kelvin's concerns about optionality of other document...

kyiu: brian out of office

fjh: thinks bal's concerns are that it clearly be OPTIONAL

generic hybrid cipher

fjh: any concrens with generic hybrid cipher in seperate doc?

RESOLUTION: Generic hybrid ciphers will be published as a first public working draft

XML Enc editorial comments

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0034.html

RESOLUTION: Accept XMLEnc edits from Magnus in http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0034.html

<scribe> ACTION: Magnus to integrate http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0034.html into XMLEnc [recorded in http://www.w3.org/2009/07/14-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-335 - Integrate http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0034.html into XMLEnc [on Magnus Nyström - due 2009-07-21].

Editorial updates

<fjh> see agenda for details

<fjh> Please review the section references to RFC 3447

<fjh> magnus checked sections for RFC 3447 in both signature and encryption, both are ok now

<fjh> issue-137?

<trackbot> ISSUE-137 -- Normative reference to DRAFT-HOUSLEY-KW-PAD -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/137

<fjh> Update XML Encryption 1.1 with explicit URIs for DH choices

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0025.html

<fjh> cleanup xml encryption

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec-commits/2009Jul/0028.html

fjh: Thomas has updated derived keys doc to indicate core is supersceeded

<klanz> I'm only availiable on skype until I get my voip account recharged ... may take a few minutes longer

magnus: added reference to processing instructions for cases where key is derived from other key info, and to distinguish wrapped from derived keys

fjh: lots of minor editorial work, nearly ready to publish

Signature 1.1 references

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0029.html

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/att-0029/XML_sig_11_References_a.htm

RESOLUTION: Accept proposed reference changes to update XML Signature 1.1 working draft

fjh: any volunteers to edit doc for changed references?

<scribe> ACTION: tlr to update xml signature references and checkin new explain documents [recorded in http://www.w3.org/2009/07/14-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-336 - Update xml signature references and checkin new explain documents [on Thomas Roessler - due 2009-07-21].

<fjh> action-320?

<trackbot> ACTION-320 -- Brian LaMacchia to draft language for HMAC section, 6.3.1 -- due 2009-06-23 -- CLOSED

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/320

ACTION-320 HMAC language

RESOLUTION: HMAC language complete (ACTION 320)

Draft publication of 1.1 working drafts

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jul/0021.html

<jcruella> sorry if asking something that I should know, but these drafts may be exposed to public comments?

<Cynthia> I think sig is ready to publish

<jcruella> OK...

<fjh> wg agrees to publish xml signature 1.1, incorporating reference updates

RESOLUTION: publish WD of XML Signature 1.1, incorporating reference updates

RESOLUTION: Working group agrees to publish XML Signature 1.1 working draft, incorporating reference updates

RESOLUTION: Working group agrees to publish XML Encryption 1.1 working draft, incorporating ConcatKDF and DH explicit key changes and additional edits agreed on today's call

RESOLUTION: Working group agrees to publish security algorithms note

RESOLUTION: Working group agrees to publish best practices

RESOLUTION: Working group agrees to publish transform simplification as a working draft

RESOLUTION: Working group agrees to publish new version of derived keys document noting that content has moved into XML Encryption 1.1

<fjh> Publication planned for 23 July

<fjh> http://www.w3.org/TR/key-encapsulation/

<fjh> http://www.w3.org/TR/2009/WD-key-encapsulation-20090516/

<fjh> http://www.w3.org/2008/xmlsec/Drafts/key-encapsulation/key-encapsulation.html

<tlr> xmlsec-generic-hybrid

RESOLUTION: use xmlsec-generic-hybrid as shortname for the Generic Hybrid draft

<fjh> ACTION: fjh update explain documents with material from Cynthia [recorded in http://www.w3.org/2009/07/14-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-337 - Update explain documents with material from Cynthia [on Frederick Hirsch - due 2009-07-21].

<scribe> ACTION: fjh to check in explain documents with material from Cynthia [recorded in http://www.w3.org/2009/07/14-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-338 - Check in explain documents with material from Cynthia [on Frederick Hirsch - due 2009-07-21].

XML Security 2.0

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/Overview.html

<fjh> converted to xmlspec format

<fjh> only copied sections that are being changed

<fjh> unchanged only has headers, should match 1.1

pdatta: 2.0 is still compatible with 1.0, 1.1 only added as new transforms, but old transforms are not iin this document
... most 1.0 use cases can be expressed in 2.0 syntax, some cannot. some c14n features in 2.0 cannot be expressed in 1.0 syntax

<fjh> pratik notes now using subelements as previously discussed, example line s07, in 2.1

pratik: core validation updated to use best practices order of operation

<fjh> section 3.2.1 has note of what has changed

pratik: section 3.2.1 has changes to c14n for signedinfo element

<fjh> items for inclusion in document - byte range transforms for binary, note that c14n optional for binary

bhill: add byte range specifiers for binary parameters in 4.4.3.2

pdatta: model is general, c14n could be described for other data types, e.g. database columns

fjh: should compatibility be eliminated from this document, discussed in seperate document?

scantor: ++ have distinct document or subsection for compat

<Cynthia> I agree, backward compatability and interoperability issues should be in a different document

pdatta: 1.x has been around for a long time, will continue to be in use, may require 1.2 after 2.0

<fjh> suggest we focus on new material, then once that is stable and good focus on backward compatibility and possible additional material on that

<fjh> possible syntax translation document, discussion of need for old transforms or mapping them etc

<tlr> I think we need version e

pdatta: no section for extensibility yet
... requirements and reasoning - should that be in this document?

fjh: requirements doc is distinct, should refer to that

exclusive c14n errata

scantor: klanz should review latest msft updates, re: xpath

<fjh> ACTION: klanz to review proposed exclusive c14n errata E02, E07 [recorded in http://www.w3.org/2009/07/14-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-339 - Review proposed exclusive c14n errata E02, E07 [on Konrad Lanz - due 2009-07-21].

Action item review

<fjh> http://www.w3.org/2008/xmlsec/track/actions/open

<tlr> ACTION: thomas to fold upcoming signature erratum into 1.1 working draft [recorded in http://www.w3.org/2009/07/14-xmlsec-minutes.html#action07]

<trackbot> Created ACTION-340 - Fold upcoming signature erratum into 1.1 working draft [on Thomas Roessler - due 2009-07-21].

<klanz> eventually my voip credit arrived sorry for that, let me know if there is anything I can be helpful with today

<fjh> action-340 update explain as well

<tlr> action-340: update explanation document as well

<trackbot> ACTION-340 Fold upcoming signature erratum into 1.1 working draft notes added

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0075.html

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0076.html

<fjh> issue-110?

<trackbot> ISSUE-110 -- Need better definition for "visibly utilizes" in Exc-C14N -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/110

<fjh> Konrad notes E02 looks ok

<fjh> action-228?

<trackbot> ACTION-228 -- Gerald Edgar to send a message to the list of closed issues and how they were closed -- due 2009-03-10 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/228

<fjh> issue-130?

<trackbot> ISSUE-130 -- How does canonicalization deal with xsi:type -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/130

<fjh> issue-130 closed

<trackbot> ISSUE-130 How does canonicalization deal with xsi:type closed

<fjh> c14n 2.0 explicitly deals with this

<fjh> issue-129?

<trackbot> ISSUE-129 -- C14N should notice xml:space -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/129

<fjh> issue-129 closed

<trackbot> ISSUE-129 C14N should notice xml:space closed

<fjh> also dealt with in c14n 2.0

<fjh> issue-126?

<trackbot> ISSUE-126 -- Clarify XMLENC Section 5.8 (Message Authentication) -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/126

<klanz> that is also in E's attribute axis -> that is also in E's attribute axis

<klanz> that is more accurate

<fjh> An element E in a document subset visibly utilizes a namespace declaration,

<klanz> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0076.html

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0076.html

<klanz> http://www.w3.org/TR/xml-exc-c14n/

<tlr> I don't understand this well.

RESOLUTION: accept errata 02 and 07 for exclusive c14n

<tlr> ACTION: thomas to update exc-c14n errata [recorded in http://www.w3.org/2009/07/14-xmlsec-minutes.html#action08]

<trackbot> Created ACTION-341 - Update exc-c14n errata [on Thomas Roessler - due 2009-07-21].

<fjh> proposal post corrected copy of exclusive c14n schema in new public location, without changing namespace

<fjh> reason is that current one is unusable, does not validate

<fjh> this captures the E02 fix

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0075.html

<tlr> http://www.w3.org/TR/xml-exc-c14n/exc-c14n.xsd

<fjh> current definition

<fjh> idea is to post corrected schema and reference from errata, without changing currently posted definition

<fjh> alternative is to edit current version, since it was unusable

RESOLUTION: post corrected copy of exclusive c14n schema in new public location, without changing namespace

<tlr> ACTION: thomas to post updated exc-c14n schema [recorded in http://www.w3.org/2009/07/14-xmlsec-minutes.html#action09]

<trackbot> Created ACTION-342 - Post updated exc-c14n schema [on Thomas Roessler - due 2009-07-21].

<klanz> is there a dated URI available

<fjh> ACTION: tlr provide link to updated schema in exclusive c14n document [recorded in http://www.w3.org/2009/07/14-xmlsec-minutes.html#action10]

<trackbot> Created ACTION-343 - Provide link to updated schema in exclusive c14n document [on Thomas Roessler - due 2009-07-21].

<klanz> leave dated uri as is ... make new one ... and relink http://www.w3.org/TR/xml-exc-c14n/exc-c14n.xsd

<tlr> http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/exc-c14n.xsd

<klanz> that's what I'd advocate for

<fjh> work item is to update exclusive c14n to 2nd edition, incorporating schema fix

<jcruella> ok, bye...

<fjh> Scribe: Brad Hill