XML Security Working Group Teleconference
09 Dec 2008

 

 

<trackbot> Date: 09 December 2008

Administrative

<hlockhar> Call next week

<hlockhar> no calls until Jan 6

<hlockhar> Scribe: hlockhar

Minutes Approval

Resolution: Minutes from Dec 2 Approved

Editorial Updates

All drafts updated last week

Best Practices

also 1.1 editors draft of signature

ran a diff against 2nd edition

Updated Requirements document

Updated Roadmap page on Web

Derived Keys

cannot be part of 1.1

magnus: will be added to future document

cannot extend same namespace

Resolution: Produce a separate document for 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.

fhirsch: need a proposal from magnus, can deal with packaging later
... decide later, 1.1 vs. 2.0, optional vs. necessary

brich: wanted to raise the concern

fhirsch: once we have a proposal we can decide how to deal with it

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

<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Dec/0008.html

<fhirsch3> sean follow up http://lists.w3.org/Archives/Public/public-xmlsec/2008Dec/0009.html

pdata: binary types only allow byte range selection, not general transforms
... added types defined in other specs, for example WS-attachements

<brich> ...also mentioned SWA - Soap With Attachments

pdata: define some actions as text properties

sean: said you are not proposing syntax, what is the proposal?

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

<tlr> ACTION: pratik to write up more detailed proposal in time for workshop [recorded in http://www.w3.org/2008/12/09-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-122 - Write up more detailed proposal in time for workshop [on Pratik Datta - due 2008-12-16].

<tlr> ACTION-122: s/workshop/January face-to-face/

<trackbot> ACTION-122 Write up more detailed proposal in time for workshop notes added

<bhill> where the relying application always gets the exact nodeset or binary octets that went in to the digester

<bhill> and doesn't have to know anything about the syntax and processing rules of XMLDSIG, regardless of whether they be procedural or declarative

fhirsch: would like discussion at F2F
... want to address Konrad's concerns also

Long Term Signatures

fhirsch: I think we should add Juan Carlos material on long term sigs to Requirements Document

Resolution: add Juan Carlos material on long term sigs to Requirements Document

<scribe> ACTION: fhirsch to add Juan Carlos material on long term sigs to Requirements Document [recorded in http://www.w3.org/2008/12/09-xmlsec-minutes.html#action02]

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

<tlr> ACTION: fhirsch to add Juan Carlos material on long term sigs to Requirements Document [recorded in http://www.w3.org/2008/12/09-xmlsec-minutes.html#action03]

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

<tlr> ACTION: frederick to add Juan Carlos material on long term sigs to Requirements Document [recorded in http://www.w3.org/2008/12/09-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-123 - Add Juan Carlos material on long term sigs to Requirements Document [on Frederick Hirsch - due 2008-12-16].

Issue 38 Requirement for non-XML canonicalization?

<tlr> ISSUE-38

<tlr> ISSUE-38?

<trackbot> ISSUE-38 -- Profile for signature processing for non-XML or for constrained XML requirements -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/38

brich: Pratik's proposal could cover this, perhaps current spec allows it as well

ISSUE-56

<tlr> ISSUE-56?

<trackbot> ISSUE-56 -- Add references related to timestamping -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/56

<tlr> ScribeNick: tlr

Hal: Question is whether or not ?? actually happened

hal, I suggest you take the chair for the moment

frederick: being chased away from hotel by police

Hal: issue-56, suggest we put this aside since critical parties aren't here
... who's editing?

frederick: myself, pratik, ...

hal: do you know what is to be put in? If you know, then I suggest action

frederick: double check
... need to check what actually needs to be done

<hlockhar> ACTION: fredrick to check with Juan Carlos on timestamp references [recorded in http://www.w3.org/2008/12/09-xmlsec-minutes.html#action05]

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

<scribe> ACTION: frederick to follow up with Juan Carlos on ISSUE-56 [recorded in http://www.w3.org/2008/12/09-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-124 - Follow up with Juan Carlos on ISSUE-56 [on Frederick Hirsch - due 2008-12-16].

close ACTION-94

<trackbot> ACTION-94 Provide draft note on new algorithms for 1.1 closed

close ACTION-111

<trackbot> ACTION-111 Add default attribute language to Best Practices doc closed

close ACTION-116

<trackbot> ACTION-116 Add approved certificate encoding text to drafts closed

close ACTION-118

<trackbot> ACTION-118 Add web services text from Hal to Requirements draft closed

close ACTION-119

<trackbot> ACTION-119 Add pointer to Transforms note to Requirements draft closed

close ACTION-120

<trackbot> ACTION-120 Review SP 800-57 for HMAC-SHA256 item closed

frederick: would like to get list down to manageable, small list before face-to-face. Please create material

hal: prefer material early!

+1

frederick: please review issues list as well
... suggest adjourning

Next meeting: next week