Derived Keys

bruce: where are we going with
this, will it be optional?
... seems to make life more complicated rather than less
... getting pushback about why we are doing it?

<brich> why push forward on a
separate spec for derived keys? where are we going with
this?

magnus: there is a need for more
general capabilities
... available outside of WS-*

brich: our users satisfied with
WS-* solution

<brich> it seems like it
would be separate so it can be used in a number of places, but
what might they be?

<brich> if this is only going
to be a 2.0 item, then why separate it out?

magnus: The motivation and use
cases for this work, and the reasons for why reliance on WS-*
derived key methods is not recommended, was presented in July
and September and in a posting to this list in September. It
was not questioned on those occasions.

magnus: don't want to work on it
if we are not going to do it
... would be ok with it being optional in 1.1

<tlr> tlr: a separate spec
would lead to RF Commitments that an optional feature in the
base spec wouldn't

possible approach would be optional in 1.1 and
mandatory in 2.0

DSA with SHA1

Brian was to provide text on DSA with SHA1

<bal> i have an action on me
to draft some text for this

<bal> my sense of the call
from the last meeting was that we should make DSAwithSHA1

HMAC SHA1

<bal> optional for signature
generation, recommended for signature verification, and add
implementation notes saying something to the effect of "if you
expect to interop with xmldsig 1.0 and 1.0 2nd ed you should
support dsawithsha1 for verification for interop"

Kelvin: we don't have to require
HMAC SHA256

Close issue 74 can be closed with no
action

Requirements

fhirsch: do we have streaming
reqs complete?

pdata: need to add more, want to
look at it again

fhirsch: everybody please
comment
... is text on Transforms correct?

pdata: reqs section and design
section
... reqs are ok, want to flesh out design portion more
... since we are making a breaking change, can make a bigger
change
... can do without Transforms entirely
... can get a nonsensical set of Transforms
... have a proposal for a more constrained approach

fhirsch: I know Konrad has
concerns, but I understand your idea

pdata: one problem with transform
chain is hard to determine what is signed
... signature occurs in the middle of the chain
... need to declar what is being signed
... also want to identify the type of data being signed

pdata: actually this is a limited
form of XPath filter 2
... current approach is procedural
... need declarative approach
... suggesting a syntax that does not have transforms

<bhill> bhill is on the
queue

<esimon2> +1 to pdatta

fhirsch: like approach, nore
controlled

bhill: like the declarative
approach
... concerned about ability to handle different data
types
... harder and harder as more types are defined
... can avoid this by constraining processor to emit text to be
hashed

<bhill> the multiple parser
problem is fundamental

<bhill> to say "what is
signed" requires the application to recapitulate the logic of
the signature processor

<bhill> this is difficult to
guarantee fidelity even for very simple cases, and becomes more
and more so as additional types are added

<bhill> I would suggest that
rather than implying "what is signed" the approach of having
the signature processor provide a cached retrieval of the exact
material used to calculate the digest

<bhill> and constrain those
outputs to either XML nodes or binary

<bhill> is the preferred
one

mullen: is there is large benefit
to making the change if there are transforms that are
equivalent

bhill: can declare a type that
uses a known style sheet
... does application try to determine what was signed?

<bhill> clarification:

<bhill> my issue is with the
description as "what is signed"

<bhill> this invites the
relying application to attempt to make this determination
itself

<bhill> re-doing the logic
the signature processor has just done, possibly
inaccurately

Action to Pratik to write up more detailed
proposal

<trackbot> Sorry, couldn't
find user - to

<bhill> I think the preferred
pattern should always look like "cached reference retrieval" in
the draft best practices