XML Security Working Group Teleconference
16 Jun 2009

 

 

<trackbot> Date: 16 June 2009

jh> Present=Frederick_Hirsch, Chris_Solc, Cynthia_Martin

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

<fjh> update to minutes here http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/0009.html

Administrative

<fjh> Teleconference 30 June cancelled.

<fjh> TPAC Overview: http://www.w3.org/2009/11/TPAC/overview.html

<fjh> Please register: http://www.w3.org/2002/09/wbs/35125/TPAC09/

Registration for TPAC is now open

<fjh> XML Security Thursday and Friday 5-6 November as originally planned.

<fjh> Note registration fee increases after 21 September 2009.

<scribe> SCRIBE: hlockhar

<fjh> NIST announces the adoption of FIPS 186-3, The Digital Signature Standard

NIST announces the adoption of FIPS 186-3, The Digital Signature Standard

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

<fjh> Randomized hashing reference

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

Minutes approval

<fjh> update to minutes here http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/0009.html

minutes reference Brian as Brain

<fjh> proposed resolution - approve minutes as distributed by Frederick with modification to change brain to brian

RESOLUTION: approve minutes as distributed by Frederick with modification to change brain to brian

<fjh> Scribe: Hal Lockhart

<scribe> SCRIBE: Hal Lockhart

<fjh> ScribeNick: hlockhar

<scribe> SCRIBENICK: hlockhar

Editorial update status

Editorial Updates

<fjh> see agenda for details

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

FIPS 186-3

<fjh> Proposed security consideration changes related to FIPS-186-3

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

bal: will have to change 3rd paragraph
... migght want to be stronger on 2048 for min
... should only verify 1024

<fjh> change last sentence to

<fjh> DSA with 1024-bit prime moduli SHOULD NOT be used for signatures that will be verified beyond 2010

RESOLUTION: Accept text with above change

Per FIPS 186-3 [DSS], the DSA security parameter L is defined to be 1024, 2048 or 3072 and the corresponding DSA q value is defined to be 160, 224/256 and 256 respectively. Special Publication SP 800-57 Part 1 [SP800-57], NIST recommends using at least at 2048-bit public keys for securing information beyond 2010 (and 3072-bit keys for securing information beyond 2030). Since XML Signature 1.0 required implementations to support DSA-based digita

Since XML Signature 1.0 required implementations to support DSA-based digital signatures, this XML Signature 1.1 revision REQUIRES signature verifiers to implement DSA in order to guarantee interoperability with XML Signature 1.0 generators. XML Signature 1.1 implementations MAY but are NOT REQUIRED to support DSA-based signature generation. DSA with 1024-bit prime moduli SHOULD NOT be used for signatures that will be verified beyond 2010. Longe

<fjh> proposed resolution - accept change proposed in http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0040.html with modification of last sentence to DSA with 1024-bit prime moduli SHOULD NOT be used for signatures that will be verified beyond 2010

bal: intention is to provide backward compat

<bal> so is the concern that because we don't say anything about mandatory-to-support dsa key sizes, the current text would require implementers to support all dsa key sizes in order to verify dsa-sha1 sigs

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-Algorithms

<mullan> yes

<bal> since the intent of the mandatory-to-implement for validation was to validate xmlsignature 1.0 signatures, which has keys at most 1024 bits

<bal> it seems to me it would be ok to say it's mandatory to support dsa-sha1 only for keys <= 1024 bits

<bal> and optional for keys >1024 bits.

<brich> or is it mandatory for <= 1024 bits through 2010 and optional afterwards?

<fjh> REQUIRES signature verifiers to implement DSA only for keys of 1024 bits, optional for larger keys,

<fjh> without optional for largers keys,

<fjh> proposed resolution - accept change proposed in http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0040.html with modification of last sentence to DSA with 1024-bit prime moduli SHOULD NOT be used for signatures that will be verified beyond 2010 , also changing REQUIRES signature verifiers to implement DSA only for keys of 1024 bits

RESOLUTION: accept change proposed in http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0040.html with modification of last sentence to DSA with 1024-bit prime moduli SHOULD NOT be used for signatures that will be verified beyond 2010 , also changing REQUIRES signature verifiers to implement DSA only for keys of 1024 bits

<kyiu> FIPS 186-3 specifies DSA to be used only with SHA-224 and SHA-256

<kyiu> Check out FIPS 186-3, section 4.2, page 15

<kyiu> Sorry, SHA-1 is supported with 1024 bit

References

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/att-0044/xmlenc-ref.html

<Cynthia> I haven't looked at it yet

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

XML Encryption 1.1 and Derived Keys

fjh: should put derived keys text in XML encryption

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

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

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

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

<fjh> magnus notes ECIES is not the same mechanism as ECIES-KEM

magnus: ECIES is just key agreement
... ECIES-KEM is agreement and key wrap

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

<fjh> magnus discussed kelvin example rework

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

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

<fjh> s/mime action

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

magnus: checked with SMIME group - not really begun to address this
... suggest making key wrap optional

<fjh> proposed resolution - key encapsulation as OPTIONAL in 1.1

bal: there is both derivation and encapsulation

<fjh> discussion on key encapsulation at this point

pdatta: are we planning to do interop on encapsulation?

fjh: if it is in working draft we can get feedback
... Interop is a reasonable question

tlr: if encapsulation is in spec w/o interop will eventually have to remove it

<fjh> tlr suggests separate spec if we do not anticipate implementation by CR

fjh: any comments on implementation plans?

magnus: too new for most people to comment on implementation plans

<fjh> magnus asks if can even have optional features without interop

<fjh> tlr says 1 for optional features, 2 for mandatory features

magnus: for optional features the minumum is 1 implementation

bruce: have no current requirements for encapsulation or derivation
... have already implemented functionality defined in other specs: e.g. WS-*

pdatta: agree with making it a separate spec progressing it more slowly

magnus: think key derivation should become part of xml encryption

<fjh> one item is to put key derivation into xml encrytion spec and then make separate spec for key encapsulation

<fjh> magnus suggests one mandatory key derivation alg

kyiu: +1
... also need to update Diffie-Hellman section

<kyiu> I second Magnus' suggestion to create a new section for key derivation and have the KDF in SP800-56A be mandatory. In addition, we probably want to update the DH section to support the use of the SP800-56A KDF.

<fjh> brian proposal add KDF section to xml enc , reference from other sections

<magnus> Exactly my point

<fjh> brian some schema changes, from attribute to element

<fjh> bruce does not have feedback on this yet

<fjh> now discussing key derivation approach

brian: question to IBM is this new KDF ok when not used with ECC?

<fjh> proposed resolution - move key derivation material from key derivation specfication into XML encryption 1.1, with separate KDF section and mandatory SP800-56A KDF

<fjh> and update DH sections accordingly

RESOLUTION: move key derivation material from key derivation specfication into XML encryption 1.1, with separate KDF section and mandatory SP800-56A KDF and update DH sections accordingly

<magnus> ACTION: magnus to move derived key spec into XML Enc 11 and create separate KDF section with mandatory 800-56 [recorded in http://www.w3.org/2009/06/16-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-317 - Move derived key spec into XML Enc 11 and create separate KDF section with mandatory 800-56 [on Magnus Nyström - due 2009-06-23].

<magnus> ACTION: magnus to create new draft recommendation spec on Key Encapsulation; use proposal on list as basis [recorded in http://www.w3.org/2009/06/16-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-318 - Create new draft recommendation spec on Key Encapsulation; use proposal on list as basis [on Magnus Nyström - due 2009-06-23].

<bal> ACTION: kelvin and brian to update DH & ECDH sections to take advantage of new KDF section [recorded in http://www.w3.org/2009/06/16-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-319 - And brian to update DH & ECDH sections to take advantage of new KDF section [on Kelvin Yiu - due 2009-06-23].

ACTION-298 resolution

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/0001.html

<tlr> it is unrelated

<klanz> http://www.w3.org/2008/xmlsec/track/actions/298

<tlr> we can do this now, yes

<klanz> http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/0002.html

<klanz> Verifying applications MAY successfully verify HMAC signatures if their

<klanz> actual SignatureValue is 1 to 7 bits shorter than the HMACOutputLength.

<tlr> shorter?!

<tlr> longer

<klanz> birthday bound is at length/2

<klanz> so every bit more than this does not add to security

<klanz> do other implementers have a problem with this

<klanz> with the caveat of being longer than length/2

tlr: only thing not completely specified is sender's padding
... only change needed is to pad with zeros

<fjh> second paragraph of proposal may be needed to indicate padding of zeros

<fjh> tlr notes third paragraph may not help, first reiterates default

<fjh> hal notes base64 requires byte input

<klanz> e.g OutputLength = 92 and teh signaturevalue encodes only 88bits in bas64

<tlr> I need to leave now, for the record, I'm -1 to that MAY

<fjh> can we consider the three parts of konrad proposal. I think we all agree on item 2.

<fjh> sounds like we agree on item 1, as not harmful, even if not strictly necessary

<fjh> item 3 is not clear

<fjh> hal notes not clear how signature MAY verify if not exactly the same

<fjh> hal verify can declare own truncation length

<fjh> konrad desire is to enable wider verification success

<fjh> hal notes that tlr asked whether the third case exists and whether it is confusing to add third point

<fjh> scantor mistake to add complexity to verifier to address bugs in signer

<fjh> bal +1 to scott

<fjh> bal why not require an octet truncation length?

<fjh> bal not add complexity for such a minor case..

<fjh> bal which applications have such a case?

<fjh> konrad notes not clear

<klanz> Note:

<klanz> > HMACOutputLength is defined on the leftmost bits, the base64 encoding

<klanz> > however works on octets, it is hence RECOMMENDED to use a length

<klanz> > divisible by 8 for maximum interoperability.

<fjh> proposal - change 'takes the truncation length in bits as a parameter' to 'takes the truncation length in bits as a parameter that falls on a byte boundary'

<tlr> urgh

<fjh> take this onto the list

<fjh> action bal to draft language for HMAC section, 6.3.1

<trackbot> Created ACTION-320 - Draft language for HMAC section, 6.3.1 [on Brian LaMacchia - due 2009-06-23].

<klanz> http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/0002.html

ISSUE-134: Camellia algorithm

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

<klanz> I will have to leave in a minute ... anything else today?

<fjh> Satoru Kanno from NTT Softwar

<klanz> what about the algorithms rfc

<klanz> http://www.w3.org/2008/xmlsec/Drafts/algorithms-rfc/

<fjh> suggest adding to cross reference doc

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

<klanz> http://www.w3.org/2008/xmlsec/Drafts/algorithms-rfc/draft.html

<fjh> hal notes we might not have implemention for optional for xenc

<klanz> no just giving it the same name in all the worl

bal: are we opening the door to everyone's favorite algorithm

<fjh> bal notes need for interop and also limit to what is added to spec

<klanz> I dont think so

<klanz> I think otherwise people will make up their own identifiers

<klanz> which is worse

<klanz> http://www.w3.org/2008/xmlsec/Drafts/algorithms-rfc/draft.html

RESOLUTION: Add Camellia identifiers to algorithm cross reference

Interop

<klanz> bye

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

<fjh> this link - http://www.w3.org/2008/xmlsec/wiki/Interop

<fjh> pratik notes next step may be interop with ECKeyValue

<fjh> the newer ECDSA key value?

pdatta: need Microsoft to interop on newer ECDSA Key value

magnus has action to create test values

<fjh> derived key interop would progress with elliptic curve

<fjh> pratik - plan for ocsp response

pdatta: Sean was planning to do something with OCSP response

<fjh> sean encoded keys on the list

RetrievalMethod and Reference in v2

<fjh> please review links from thomas and scott for follow-up

<fjh> scott - adding new children with additional id attribute might be confusing if they duplicate old ones

Action items

fjh: will close pending AA's