XMLSig 1.1

<jcruella> fjh: any thought
about this? my own one is that we could do some work on this.
Should we recommend other algorithms at different security
levels?. And what about hash algorithms? should we add some
more?

<jcruella> bal: I would defer
this...was a little confuse by Magnus message...I think that we
have this solved in the draft: section 6 list of required and
recommended.

<jcruella> brian: I thought
that people could say what the concerns are

<fjh> working group now can
express their concerns leading to cannot - live with. A round
to see what the concerns are?

<fjh> other concerns as well,
also non-technical vs technical

<jcruella> fjh: start with
people that say they can not leave with.

<jcruella> tlr: brian, Chris,
Robert, Ken

<gedgar> +q

<jcruella> chris:

<jcruella> ...we have third
parties soft, they are not willing to add certain algorithms...
required, we may roll out in the implementations...

<kgraf> +q

<jcruella> fjh: mention that
this is what we want in the first public draft, not necessarily
in the final document. Maybe should distinguish concerns on
what should be in the first draft from what is in the final
doc....

<jcruella> GeraldEdgar:
concern on robustness security level ....

<tlr> fjh: different
algorithm available?

<gedgar> yes..thanks
thomas

<tlr> gerald: if it has same
level of security, yes. But need to support Suite B.

<fjh> gerald notes that
simpler to ask suppliers to support Suite B and get level of
security

<fjh> gerald notes also helps
with international issues

<jcruella> ken:

<fjh> ken also have 3rd party
products built into products so don't want to requre them to
build in ecc

<jcruella> ken: do not
violently opose to this...I could be convinced to live with
this.

<jcruella> bal: question:
want understand what is third partie issue?

<jcruella> ...ken says that
there are third parties in their products...

<jcruella> ...but in chris'
it is a matter of other soft to plug in...

<jcruella> bal: I am not sure
that requiring support is the same as requiring generation. It
is requiring verification

<fjh> bal notes but requires
validation

<jcruella> chris: but their
implementations would not be able to manage

<fjh> bal notes need two
mandatory algs in spec in case one is no longer usable

<fjh> bal notes spec might be
around a long time

<fjh> bal concerned about ws*
and other profiles which will only go with what is mandatory to
implement

<fjh> bal also notes some
customers are asking for suite B

<fjh> bal notes suite b is a
major feature of 1.1

<Zakim> Thomas, you wanted to
ask whether we need to bring some of these third parties into
the discussion

<fjh> tlr asks can we get
those 3rd party implementers to participate in this WG?

<fjh> tlr asks is it a public
procurement issue?

<fjh> tlr notes with 1st
edition RSA got profiled even though not mandatory

<jcruella>tlr asks where is
the critical difference between required and recommended,
Brian?

<fjh> hal notes that draft
requires alg for both signing and verification

<fjh> hal asks about
compliance requirements

<jcruella> hal notices that
another point is that this will drive for major vendors.

<fjh> hal notes that argument
for alternate alg is weaker since all depend on SHA
hashing

<fjh> hal notes that it may
not be appropriate to require a new algorithm that has not been
in use for a while

<jcruella> fjh: w* not
profile soon...

<jcruella> ...another point:
did not understand the question on the eprocurement..

<jcruella> tlr: think it was
not critical...

<fjh> bal notes only RSA-SHA1
is supported in WS* so they will probably need an update

<fjh> bal notes RSA was
widely deployed at time of 1st edition

<jcruella> bal: RSA widely
deployed, DSA was there because of basic requirements. Here we
have the case that none of the algorithms in 1.0 are actually
mandatory. Do not think the situation is the same as in 2000.
do not think requiring long keys is worth.

<fjh> bal notes it is
essential to be able to be agile if crypto alg is not
useable

<jcruella> fjh: brian, we
have two responses to the " can not live with this requirement"
if there are products from other parties....

<kgraf> +q

<jcruella> Bal: my concern is
that we would prefer to see recommended algs, and see more than
one, before seeing required algorithms.

<fjh> kgraf notes that
alternative is to have recommended algs and require two or more
to be implemented. Some small environments with only one
algorithm, and if fails, then change to another.... as
oppposite to have several algorithms in the implementation

<fjh> impact on interop?

<jcruella> ......

<fjh> bal notes that with new
1.1 standard, 3rd party will have to update anyway to be
compliant with 1.1. Still have 1.0

<fjh> tlr asks if objection
about specific second alg but against having two mandatory
algs

<fjh> ken is against
requiring any algorithm

<jcruella> brian: objection
to require any algorithm... not objection against one specific
algorithm , but to require any algorithm

<jcruella> fjh: two different
things: objections to ec, objections to require
algorithms...

<fjh> hal notes we need one
mandatory to implement to get interoperability

<fjh> +1

<jcruella> hal: strongly
against not mandatory idea.

<jcruella> hal: new hash
algorithm....the advance in theory could conceivably discover
new algorithms invalidating sha family...since this is first
public draft, put it as it is and get feedback from outside

<fjh> hal required is likely
to get more feedback in first public working draft

<jcruella> Ken: I would agree
in making this draft public, with the idea of getting feedback
from outside.

<jcruella> tlr: would be
useful to have an editorial note summarizing this discussion
today

<gedgar> +1 on making this
required for this working draft and see what response we
receive.

<esimon2> Didn't we at one
point, given algorithm lifespans, consider keeping XML
Signature and XML Encryption algorithm-neutral and then
supporting plug-in profiles of algorithm suites?
(Interoperability would then be on an algorithm suite
basis.)

<tlr> PROPOSED: To use ECC as
REQUIRED algorithms in xmlenc 1.1 and xmldsig 1.1 FPWDs, with
an editor's note that highlights issues concerning recommended
vs required algorithms and solicits further feed-back.

<jcruella> fjh: how to
proceed with the note?...will you propose some text, circulate
it, people would agree and then close the document?

<jcruella> tlr: taking into
account that publication will likely take place next week, we
could have discussion on the list...

<jcruella> fjh: if there are
not major issues raised in the email we may proceed to
publish