See also: IRC log
<trackbot> Date: 15 December 2009
<scribe> ScribeNick: jwray
<fjh> http://www.w3.org/2009/12/08-xmlsec-minutes.html
RESOLUTION: Approve minutes from 8 December 2009
<fjh> MgmtData
<fjh> additional proposed change
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0041.html
<fjh> The MgmtData element within KeyInfo is a string value used to convey in-band key distribution or agreement data. However, use of this element is NOT RECOMMENDED and SHOULD NOT be used. Section 4.5.8 describes new KeyInfo types for conveying key information.
RESOLUTION: Accept MgmtData change proposed by Sean Mullan, see http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0045.html
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-MgmtData
<fjh> change title of 4.5.8 to <xenc:EncryptedKey> and <xenc:Agreement>
<fjh> Updates for RNG schema 1.1, explanation documents
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0034.html
<fjh> ACTION: fjh to implement MgmtData change proposed by Sean, and to change title to 4.5.8 [recorded in http://www.w3.org/2009/12/15-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-464 - Implement MgmtData change proposed by Sean, and to change title to 4.5.8 [on Frederick Hirsch - due 2009-12-22].
<fjh> action-386?
<trackbot> ACTION-386 -- Hal Lockhart to look at WS-I BSP constraints on DSig -- due 2009-10-13 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/386
<fjh> hal notes could pull in some best practices from BSP, not affecting 1.1
<fjh> action-386 closed
<trackbot> ACTION-386 Look at WS-I BSP constraints on DSig closed
<fjh> issue-82?
<trackbot> ISSUE-82 -- Should 1.1 spec mandate support for range of RSA key sizes (and DSA)? -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/82
<fjh> action-442?
<trackbot> ACTION-442 -- Brian LaMacchia to propose text for RSA for Issue-82 (DSA already done) -- due 2009-11-14 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/442
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0051.html
<fjh> add the following text to the end of Section 6.2.6.2
<fjh> Security considerations regarding RSA key sizes
Should be make recmomendations about RSA keysizes (we already make recommendations for DSA)
<fjh> In Special Publication SP 800-57 Part 1 [SP800-57], NIST recommends using at least 2048-bit public keys for securing information beyond 2010 (and 3072-bit keys for securing information beyond 2030). This XML Signature 1.1 revision REQUIRES all conforming implementations to support RSA signature generation and verification with public keys at least 2048 bits in length. RSA public keys of 1024 bits or less SHOULD NOT be used for signatures that will be verified
scribe: beyond 2010
<fjh> hal notes potential concern of revising document by including details within it.
<fjh> referencing phb workshop paper
<fjh> bal notes the need for interop clarity
<Zakim> fjh, you wanted to note distinction for 2.0 vs 1.1
<fjh> scott suggests have separate conformance document
<fjh> scott for 2.0 not sure about 1.1
<fjh> concerns about schedule, 2.0 clearly point for changes
<fjh> ACTION: tlr to help with understanding if we can go to last call for 1.1 and then structure separate conformance clause document after last call? [recorded in http://www.w3.org/2009/12/15-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-465 - Help with understanding if we can go to last call for 1.1 and then structure separate conformance clause document after last call? [on Thomas Roessler - due 2009-12-22].
<fjh> two questions: agree on the text?, where to put it?
RESOLUTION: Adopt Brian's wording for RSA key-sizes, see http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0051.html.
<fjh> ACTION: fjh to incorporate RSA key size text into document [recorded in http://www.w3.org/2009/12/15-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-466 - Incorporate RSA key size text into document [on Frederick Hirsch - due 2009-12-22].
<fjh> action-404?
<trackbot> ACTION-404 -- Brian LaMacchia to draft language that codifies history why DERKeyValue is not child of KeyValue (for section 4.4 of xmldsig-core1) -- due 2009-10-20 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/404
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0053.html
<fjh> Regarding ACTION-404 ("Draft language that codifies history why DERKeyValue is not child of KeyValue (for section 4.4 of xmldsig-core1)"), I propose to add the following text to the end of Section 4.5.9:
<fjh> Historical note: The DEREncodedKeyValue element was added to XML Signature 1.1 in order to support certain interoperability scenarios where at least one of signer and/or verifier are not able to serialize keys in the XML formats described in Section 4.5.2 above. The KeyValue element is to be used for "bare" XML key representations (not XML wrappings around other binary encodings like ASN.1 DER); for this reason the DEREncodedKeyValue element is not a child of KeyValue
KeyValue intended for XML-encoded keys (as opposed to XML-wrapped binary)
<fjh> suggest replace "no further structure is included" with "KeyValue is intended for XML-encoded keys, as opposed to XML wrapped binary."
<fjh> strike, "since no further structure is include."
RESOLUTION: Adopt proposal for action-404, striking "since no further structure is include."
<fjh> ACTION: fjh to add action-404 proposal into editors draft [recorded in http://www.w3.org/2009/12/15-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-467 - Add action-404 proposal into editors draft [on Frederick Hirsch - due 2009-12-22].
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0028.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0037.html
<fjh> ACTION: tlr to remind frederick if we have to interop optional features with 2+ implementations [recorded in http://www.w3.org/2009/12/15-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-468 - Remind frederick if we have to interop optional features with 2+ implementations [on Thomas Roessler - due 2009-12-22].
<fjh> we may have two implementations, java and oracle library
<fjh> status of nsa requirements on aes-gcm not clear
<fjh> bal has asked about status
<fjh> issue-155?
<trackbot> ISSUE-155 -- Add AES-GCM to XML Encryption 1.1 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/155
<fjh> bal notes that this might not be needed for messaging protocols that separate signing from encryption
RESOLUTION: Add AES-GCM to XML Encryption, see http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0037.html
<fjh> ACTION: fjh to add aes-gcm to enc 1.1 [recorded in http://www.w3.org/2009/12/15-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-469 - Add aes-gcm to enc 1.1 [on Frederick Hirsch - due 2009-12-22].
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-SHA-1
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-SHA-1
<fjh> ACTION: fjh to change "see below" to link to section 6.2 in xml sig 1.1 [recorded in http://www.w3.org/2009/12/15-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-470 - Change "see below" to link to section 6.2 in xml sig 1.1 [on Frederick Hirsch - due 2009-12-22].
<brich> have a conflict, dropping from the call now
RESOLUTION: Repeat second sentence of 6.2 introduction in 6.2.1 (SHA-1 section)
<fjh> ACTION: fjh to add sentence to 6.2.1 and fix DSS reference in sig 1.1 [recorded in http://www.w3.org/2009/12/15-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-471 - Add sentence to 6.2.1 and fix DSS reference in sig 1.1 [on Frederick Hirsch - due 2009-12-22].
<fjh> might want to add warning to best practices regarding algorithm suitability
<fjh> ACTION-439?
<trackbot> ACTION-439 -- Thomas Roessler to draft text for xml encryption 1.1 for handing EXI -- due 2009-12-01 -- CLOSED
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/439
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0006.html
<fjh> defer to later on call with tlr
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0011.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0029.html
<fjh> need to support bit strings
<fjh> potential issue with Java not supporting bit strings
<fjh> bal notes that NIST standard and standards specify bit strings but some implementations use bytes
<esimon2> * back in 5
<fjh> add note that these are defined on bit strings, output not on byte boundary?
<fjh> bal - for greatest interoperability try to have byte aligned
<fjh> bal - while any bit string can be used, recommend to keep byte aligned for greatest interoperability.
RESOLUTION: Add interoperability note to ConcatKDF section, "while any bit string can be used, recommend to keep byte aligned for greatest interoperability".
<fjh> ACTION: fjh to add ConcatKDF note [recorded in http://www.w3.org/2009/12/15-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-472 - Add ConcatKDF note [on Frederick Hirsch - due 2009-12-22].
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0019.html
<fjh> not part of 1.1.
<fjh> bal notes defer since analysis not complete
RESOLUTION: MQQ will not be included in 1.1
Defer discussion for 2.0
<fjh> http://www.w3.org/2008/xmlsec/wiki/PublicationStatus
<fjh> pratik working on XPath for 2.0 and prototype
<fjh> scott working on selection text for 2.0
<fjh> talk about 2.0 conformance document/approach
<fjh> January 2010 last call for Signature 1.1, Signature Properties Updated WD for XML Security 1.1 Requirements, XML Security 2.0 Requirements, Best Practices
<fjh> February 2010 last call for Encryption 1.1, XML Security Generic Hybrid Ciphers Update WD for XML Security Algorithm Cross-Reference
<fjh> 2.0 Planning
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0030.html
<fjh> please review your actions and do them
<fjh> http://www.w3.org/2005/06/tracker/users/my
RESOLUTION: Cancel 22 December 2009 call.
http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0006.html
<fjh> bal notes concern that change would require EXI understanding, a new requirement on implementations
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0006.html
<fjh> scantor notes proposal needs to include type in model
<fjh> bal notes that non-EXI aware processor must remain conformant by processing without EXI knowledge
<fjh> tlr to refine language, including type parameter, and clarify of conformance without understanding EXI
<fjh> ACTION: tlr to update xml enc processing proposal with more detail and addressing wg concerns [recorded in http://www.w3.org/2009/12/15-xmlsec-minutes.html#action10]
<trackbot> Created ACTION-473 - Update xml enc processing proposal with more detail and addressing wg concerns [on Thomas Roessler - due 2009-12-22].