XML Security Working Group Teleconference

<trackbot> Date: 13 September 2011

Administrative

<fjh> ScribeNick: Hal

<fjh> New Version Notification for draft-eastlake-additional-xmlsec-uris-01.txt, http://lists.w3.org/Archives/Public/public-xmlsec/2011Sep/0041.html

<fjh> Additional editors tools, http://lists.w3.org/Archives/Member/member-xmlsec/2011Sep/0000.html

<fjh> ACTION: fjh to check documents for up to date IETF references [recorded in http://www.w3.org/2011/09/13-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-835 - Check documents for up to date IETF references [on Frederick Hirsch - due 2011-09-20].

<fjh> TPAC 2011 Plenary Day (wed) request for ideas, http://www.w3.org/wiki/TPAC2011/SessionIdeas

<fjh> TPAC registration reminder, fee goes up after 14 October - http://www.w3.org/2011/11/TPAC/#Registrati

<fjh> Note: XMLSec is *not* meeting during TPAC

Minutes Approval

<fjh> Approve minutes, 6 September 2011

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Sep/att-0023/minutes-2011-09-06.html

RESOLUTION: 6 September minutes approved

<fjh> proposed RESOLUTION: cancel teleconference on 25 Oct, 1 Nov, 22 Nov

RESOLUTION: cancel teleconference on 25 Oct, 1 Nov, 22 Nov

XML Encryption 1.1

<fjh> proposed algorithm change:

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Aug/0014.html (Frederick)

<fjh> ACTION-829, http://lists.w3.org/Archives/Public/public-xmlsec/2011Aug/0048.html (Scott)

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Aug/0083.html

<fjh> bal: pkcs 1.5 still used in industry, so suggest sticking with security consideration

<fjh> ...: no stronger proofs justifying switch in algorithms

<fjh> bal: RSA-KEM is promising approach going forward, but implementations might need time to catch up

bal: Concerned about time to adjust to new padding alg
... don't see compelling reason to abandon 1.5

<fjh> scantor: need to consider existing implementations and potential issue with use of algorithm

Scott: need to either change alg or document probs in detail

Brian: agree with you, when is paper coming out?

fjh: perhaps now we can reference the paper
... what is relationship between this and generic hybrid cypher?

<scantor> I also agree with Brian that introducing KEM as the MTI solution is not practical for software reasons

Brian: don't know
... KEM is general technique

<fjh> why not require RSA-KEM as transport alg in XML Encryption 1.1?

Brian: if we want to change long term, we need to study it carefully

<fjh> .. concern about mistakes in change of algs, impact of adoption

<fjh> is a 2.0 XML Encryption a reasonable thought for this WG - probably not in the charter time frame...

Brian: basically KEM makes it harder for dev to code vulnerable code

hal: can we just add security considerations for 1.1 and reconsider 2.0?

fjh: propose we do that if charter allows

Scott: need to make it clear you can use OAEP with 192 bit keys

fjh: I have been making other changes to current draft

tlr: owe respones to vendors and to paper authors
... proposal seems reasonable
... don't wwant people to default to 1.5, but no implementation would be worse

<fjh> need additional guidance in paper regarding pkcs 1.5

fjh: if 1.1 ends up waiting on PAG, we could do things in the meantime
... need resolution to not change algs
... need to draft security considerations

Scott: I could try a first draft

brich: in previous case, paper was published much later than expected by authors

<fjh> proposed RESOLUTION: No changes to XML Encryption 1.1 algorithm requirements

brich: most impls seem to support OAEP
... KEM has litle implementation support
... moving from 1.5 to OAEP will be difficult in field, although might be best from security point of view

scott: we already require OAEP

<fjh> correct

scott: 2 questions, depricate 1.5 apparently not

also require OAEP 192 bit support

<fjh> "Implementations must implement RSA-OAEP for the transport of 128 and 256 bit keys."

Brian: OAEP is independant of key length, weird we are not requiring 192 bit support

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.html#sec-RSA-OAEP

scott: support is linked to 3DES

<fjh> scott proposal, http://lists.w3.org/Archives/Public/public-xmlsec/2011Aug/0048.html

scott: typically base choice of alg on key type
... should require support for all key sizes

<fjh> proposed change

<fjh> "The transported key size is 192 bits for TRIPLEDES and 128, 192, or 256

<fjh> bits for AES. Implementations MUST implement RSA-OAEP for the transport of

<fjh> all key types and sizes that are mandatory to implement for symmetric

<fjh> encryption. They MAY implement RSA-OAEP for the transport of other keys."

what about the use of SHA-1 with OAEP as mentioned in Scott's msg

Scott: should require at least one other

Brian: need to discuss with Magnus

<fjh> proposed RESOLUTION: No changes to XML Encryption 1.1 algorithm requirements

RESOLUTION: No changes to deprecate pkcs 1.5 in to XML Encryption 1.1 algorithm requirements

<fjh> ACTION: bal to provide guidance text and to review SHA-1 with OAEP [recorded in http://www.w3.org/2011/09/13-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-837 - Provide guidance text and to review SHA-1 with OAEP [on Brian LaMacchia - due 2011-09-20].

XML Security 2.0

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Sep/0040.html

<fjh> LC-2488

RESOLUTION: Adopt proposal proposal to address LC-2488 in message http://lists.w3.org/Archives/Public/public-xmlsec/2011Sep/0040.html

Editorial updates

<fjh> Updated XSD schemas with copyright, ACTION- 831, http://lists.w3.org/Archives/Public/public-xmlsec/2011Sep/0025.html (Frederick)

Adjourn