See also: IRC log
<trackbot> Date: 09 December 2008
Administrative<hlockhar> Call next week
<hlockhar> no calls until Jan 6
<hlockhar> Scribe: hlockhar
Resolution: Minutes from Dec 2 Approved
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
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
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
<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
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
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].
<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
<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