FIPS 186-3

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

<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> 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

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.