OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Minutes for F2F, Morning Wednesday 11 June 2003

Plan to update with attendance after close of F2F.
Minutes for WSSTC F2F, Morning Wednesday 11 June 2003
Dial in info: 1-425-703-7700  Passcode: 4545/4546/4545
Minutes taken by Steve Anderson


    - Minutes from 3 June 2003 meeting accepted (unanimous)
  New (General) Action Items:
    - Editors to add common interop pitfalls to spec
    - Editors to update table in core spec that indicates when to 
      use wsu:id vs id defined by other schemas
    - Editors to look into SHOULD vs. MUST for order of encrypted 
    - Editors to update spec to require Zulu time
    - Hal will update interop spreadsheet based on emails sent
    - Chris to post MS contact name for further interop testing

  Issues List Action Items & Status Updates:
    - 25: resolved to not support
        - marked PENDING
    - 62: Editors to add text for QName versioning solution
        - marked PENDING
    - 67: Hal to begin editing a Usage Label document, which may
      transition into a profile
        - marked PENDING
    - 70: Editors to reflect mustUnderstand resolution in docs
        - resolved that mustUnderstand on Security header simply
          means you are aware of the WS-Sec spec, and there are
          no implied semantics
        - marked PENDING
    - 71: marked CLOSED, with pointer to related issue 84
    - 72: separated into discussions on Timestamp trace and Expires
        - Timestamp trace: resolved to remove this from core and
          possibly put into another doc
        - Expires:
            - Editors to 1) change lines 1263-1264 of core-13 from
              "it is STRONGLY RECOMMENDED that recipients ..." to
              "Recipients MUST ..."; 2) change introductory paragraph
              around lines 1234-..., clarifying the expiration for
              security purposes rather than application purposes, 
              and clarifying the consideration of clock skew
            - Editors to make Timestamp header a child of Security
      		  header, and to remove the ability of Expires to stand
      		  alone (section 10.2.2 moves to child of section 10.3)
      		- Editors to clarify lines 1243-1244 of core-13
        - marked PENDING
                             Raw Notes

> Agenda:
> 1. Roll call

- Attendance attached to bottom of these minutes
- Quorum achieved

> 2. Review minutes from previous meeting (6/3/2003)
>    < http://lists.oasis-open.org/archives/wss/
>      200306/msg00025.html >

- [VOTE] unanimous consent, accepted

> 3.  Interop test findings and discussion

- Kelvin: spreadsheet divided into 3 scenarios
- each participating company listed
- Prateek: what was final version of interop draft?
- Hal: 6, and there were corrections to that
- it may make sense to update after interop
- Kelvin: on right side of spreadsheet are comments taken at end of
  day yesterday
- encouraging to note that it's not a long list
- will go around room and give people a chance to share experience
  from interop
- Merlin: none of the issues were WSS issues, were mainly 
  interpretation issues
- Prateek: what other specs created confusion?
- XML-Encryption was a big one
- Phill: reason VeriSign's implementation didn't do scenarios 1 & 2 is
  that it is an actual product, and the product doesn't support such
- Eric: surprised that we didn't have too many signature problems
- Kelvin: and we did a straw poll of whether people were using same
  signature implementations or their own, and it was mostly unique
- Jan: we should do this again after spec is published
- Peter Dapkus: spreadsheet is missing some client results from BEA
- Martijn: would like to see a different interpretation of the list
- if there isn't an X, it may not have been tested
- in particular, Cyclone's machine died midday, preventing further
- Peter Dapkus: can spreadsheet reflect failures vs. not tested?
- Kelvin: can gather that info offline
- Martijn: would like to post this spreadsheet in Kavi, and update
  as people do private tests
- Hal: uncomfortable with that, with possibility of journalists making
  something out of it
- Kelvin: could post to private area of Kavi and allow updates there
- Henry: there was an issue of UTF-8 and Byte Order Masking (BOM)
- if not implemented correctly, will fail
- also, didn't see any negative testing
- Hal: did anyone try bad passwords?
- Peter Rostin: did try it, but not sure if others did
- Henry: need interoperable behavior for failures
- Hal: observed that security properties are very subtle
- in some cases, had to research XML-Encryption, then FIPS, then CBC
- what appear to be minor changes can have big impact
- Kelvin: Hal did a great job on the interop spec
- Kelvin: other general comments included that future test should 
  include company identifier in the ping message
- Kelvin: on spreadsheet, we're scrolling to the right
- on left side, summary of what we found, and on right side, a
  categorization of whether it is a spec issue or not, etc
    - namespace issue had been addressed, but not caught in people's
    - open issue already with key identifier
    - had a number of SOAP, WSDL, etc issues
    - Chris: we learned alot about how to make future interops more
    - Hal: part of the problem is that SOAP 1.1 & SOAP 1.2 take very
      different attitudes towards HTTP SOAPAction header
    - Hal: one of the things I tried to do was to not restate what
      was clearly stated in other specs
    - if other specs gave a choice, interop spec gave a specific 
    - Merlin: could write an appendix on interop issues
    - [ACTION] Editors to add common interop pitfalls to spec
    - Hal: concerned with this direction
    - Chris: good idea to remind the reader of this passage that they
      still need to do due diligence and read those other specs, and
      not simply take these comments alone
    - Kelvin: concerning multiple signatures, we learned that we 
      need to be more crisp
    - Merlin: for instance, had a very specific state machine written
      strictly for the interop scenarios
    - Kelvin: on to line 13
    - Hal: thinks people misinterpreted the scenario
    - Chris: flagged this as needs more research to see if there is
      more that needs to be added to spec
    - 14 & 17 related, and worded wrong
    - Hal: XML-Encryption specifies that a count should be at end
      and pad out to the end
    - there is explicit directive on padding algorithm, and many miss
    - Kelvin: line 16 is just basic XML Schema
    - line 18 was an implementation issue, not a spec issue
    - [ACTION] Editors to update table in core spec that indicates 
      when to use wsu:id vs id defined by other schemas
    - Hal: proposed text a week or so ago to fix issue with line 20
    - Chris: there are situations where a MUST cannot always be true
    - Hal: hadn't seen that
    - [ACTION] Editors to look into SHOULD vs. MUST for order of 
      encrypted elements
    - line 21
    - Hal: we should consider requiring people to always using Zulu
    - Chris: thought that was already in there
    - says UTC format, which is different than the timezone of the
    - Prateek: we went thru this in SAML, and it greatly helps to
      specify Zulu time
    - [ACTION] Editors to update spec to require Zulu time
    - line 22
    - Hal: order matters, and question is how you determine the order
    - proposed a few different ways of doing that
    - Kelvin: we'll get into that later
    - line 23
    - Hal: interop clearly stated 3DES-CBC, so people didn't follow
    - don't think we want to restrict algorithms in spec, that's more
      of a WS-I profile exercise
    - line 24
    - Chris: similarly, this is more of a WS-I BP exercise
    - first 2 bytes in a SOAP message can be a BOM
- Kelvin: great job to those who participated
- found that docs work
- Chris: learned that we need to have Hal write our interop docs
- big thanks to Hal
- Peter Rostin: learned we need to state more about how we expect 
  people to use this, because there are surprising variations
- Chris: isn't that more in domain of WS-I BSP?
- Tony: that WS-I effort will get underway next week
- Chris: lots of same people involved in that group
- Tony: trying to correlate work we did over last 2 days to the spec
- sees that there are a few issues to address
- should publish a draft-13
- question is next step, where to go from there
- Chris: we've clearly surpassed the three elements of interop that
  OASIS requires
- when through the spreadsheet, and even with connectivity problems,
  over 66% of the more than 300 cells are marked positive
- Phill: can people speak to press about these positives
- Kelvin: TC can't really control it
- but, would be very disappointed to read article tomorrow stating who
  participated and who didn't, etc
- can say that we've had good progress
- Hal: concerning interop, after talking to people informally, there
  are corrections and notations that should be made
- [ACTION] Hal will update interop spreadsheet based on emails sent
  to him, and will post to Kavi
- since the raw version went to mailing list last night, the updated
  version should go there as well
- can also go to document repository, and be marked TC private
- Chris: his counterparts mentioned value in continued testing
- they have an IP address where their stuff can be tested
- mail list is probably not best place to circulate that
- Kelvin: there aren't any good, secret ways of doing that through TC
- Peter Rostin: can just post each company and a contact
- [ACTION] Chris to post MS contact name for further interop testing

> 4. Top down (lightweight) document review/walkthrough

- skipped

> 5. Discussion of open issues, review latest issues list
>    11 PENDING Pick date for OASIS submission date after initial
>       drafts available 

- Chris: on agenda for tomorrow

>    25 OPEN Core: How can a Signature element occurring outside of
>       the header be referenced?

- Chris: Ron was to send proposal to list, not sure if it happened
- Hal: he indicated that he'd be satisfied if spec said this wasn't
- Chris: is there any objection to this resolution
- Hal: Thomas had responded to one of my comments that he wants to
  spread signature elements throughout message
- Tony: thinks that is really troublesome, would favor not supporting
- Hal: not necessarily in favor of Thomas' suggestion, and may not
  even be representing it correctly
- Chris: we'll resolve this as unsupported, and see if Thomas has any

>    30 PENDING How should XML be explained

- Phill: has inserted text into his docs
- Chris: will leave as PENDING

>    31 PENDING Should use OASIS Namespace

- still waiting on OASIS

>    62 OPEN Versioning Mechanisms

- Kelvin: Jerry did send proposal to list
- Jerry not on list
- Chris: there was discussion on last call on different mechanisms
- thought Jerry was going to propose specifics
- Tony: 
- Chris: Thomas posted comment about our QNames, based on URIs, 
  implicitly having version information
- seems very straightforward, and would solve the problem
- QName's namespace identifier has the URI
- Resolution: Adopt a versioning scheme that has version information in
  the URIs
- [ACTION] Editors to add text for QName versioning solution
- change to PENDING

>    67 OPEN Resolve usage labels

- Tony: there is a proposal up there now
- Hal: proposed everything except the actual symbols
- if we are happy with approach, just pick identifiers
- Tony: slight modification, each profile should state which labels
  (and therefore usages) are to be used
- don't want to be limited by core
- Hal: concerned that semantics may be different
- Tony: don't see the practical potential danger there
- there may be specific labeling requirements for each profile
- Chris: there was discussion previously about industries having 
  different labels
- concerned about trying to put universe in one doc
- Hal: imagines having a consistent set in core, and profiles identify
  applicable subset
- Chris: do you have a set in mind?
- Hal: yes, was included in posting, had about 5
  < http://www.oasis-open.org/archives/wss/200305/msg00008.html >
- going through them
- Hal: the model here is a very authorization-specific model
- may not accommodate all intentions
- Chris: wondering whether or not the discussion of the base set of
  usage values needs to be put in core
- Hal: could make separate doc, but wanted to avoid separate docs 
  defining the same semantics
- wants symbols defined in OASIS namespace
- discussion of defining symbols, but not complete semantics
- not deemed a good idea
- [more discussion]
- Hal: open to making a separate profile
- Chris: thinks we'll make more progress
- Kelvin: we need to assign an editor for such a profile
- Thomas: thinks message body will need these labels, so they'll have 
  to define them again
- Hal: this brings up an earlier point of security components in body,
  vs. just the security header
- (related to issue 62)
- Jeff: that is a significant decision to make
- Chris: thought we already decided to stick to header
- Jeff: thought so too
- Hal: yes, intention was to keep implementations from hunting through
  whole message by keeping security elements in security header
- a change to that would be a fairly radical departure
- Thomas: not proposing we specify the message body stuff
- saying that some security stuff may need to be repeated in body
- resolution: start a separate profile, with Hal as editor, where
  motivating scenarios can be captured
- Jeff: suggests it not be a formal profile doc, but rather a proposal
- [ACTION] Hal to begin editing a Usage Label document, which may
  transition into a profile
- change to PENDING

>    69 PENDING The specification is vague on the topic of Key
>       Identifiers

- Editors have chatted, and will be reflected in next round of profile
- leave PENDING

>    70 OPEN The specification needs to clarify usage of
>       S:mustUnderstand. There were several opinions on what
>       understanding would include: understanding and processing
>       <wsse:Security> header element and all its sub elements when
>       the header element is tagged with mustUnderstand="1", 
>       understanding but not processing, tagging all child elements
>       with explicit S:mustUnderstand values of "0" or "1"...

- Hal: there has been months/years of discussion in PKIX arena in this
- no reason for us to repeat it all here
- Phill: there is a good reason to address it here
- reason for criticality is to break things
- if you don't understand something, stop & discard the received item
- Hal: problem was the there were features that implementations could
  recognize, but don't consider relevant to them
- basically not eager to rehash this discussion
- need to capture and summarize their discussions
- Chris: we need to take a position
- Hal: problem in PKIX was that they took a position, but people 
  determined that the position was ambiguous
- Chris: we need to make an unambiguous position
- Hal: is the problem here different that the problem in PKIX?
- Phill: we could declare that mustUnderstand not be used within
  Security header
- Chris: can put mustUnderstand on top level Security element
- what happens to sub-elements?
- Tony: could leave that to policy
- Phill: thinks that for this implementation, there are no requirements
  for mustUnderstand
- the security header itself can't be signed, so a mustUnderstand bit
  can't be trusted
- Chris: we could say that if you see a Security header, and you don't
  understand it, you SHOULD fail, and if the security header has a 
  mustUnderstand bit, and you don't understand it, you MUST fail
- Hal: going back to inability to sign security header, is that right?
- Phill: not without putting it in another security header
- Chris: could use enveloped signature
- Chris: trying to get agreement at the top level of the decision tree,
  where a sender can dictate failure if the recipient knows nothing
  of WS-Security
- Frederick: so agrees that if you understand the Security header "in
  general", you can pass the first level of mustUnderstand
- Peter Rostin: what does understand "in general" mean?
- Phill: still can't resolve the fact that you can't truly trust the
  security header (and it's mustUnderstand bit) until you process the
  security header and verify its signature
- [more discussion]
- resolution: mustUnderstand on Security header simply means you are
  aware of the WS-Sec spec, and there are no implied semantics
- [ACTION] Editors to reflect mustUnderstand resolution in docs
- change to PENDING

>    71 OPEN Inconsistent token pre-pending rules

- Hal: related to 84, can't solve one without the other
- mark CLOSED, with pointer to issue 84

>    72 OPEN Awkward status of message timestamps in WSS core

- Hal: posted comments, but don't recall any responses
- had comments on both expiration and timestamp trace
- boils down to either we should eliminate them or layout a specific
  set of rules for them
- profiles can define new sets of rules
- rules aren't currently present, and they couldn't conclude what they
  should be
- Tony: other areas, like signature processing, are left without rules
- Hal: but in those areas, the rules are dictated by other people/
- Prateek: there is a body of knowledge in the signature case that we
  are pointing to / relying on
- Martijn: the point is that we are leaving technical stuff and getting
  into semantics
- maybe this needs to go into a profile
- Hal: a lot of the scenarios that were suggested weren't security-
- if other specs, like reliable messaging, want to specify semantics,
  that's fine
- we should define semantics that are security-specific, which should 
  be few
- Hal: with timestamp trace, if we have synch'ed clocks, sees no
  security usefulness
- [discussion of possible scenarios]
- Chris: so the suggestion is to drop expiration and timestamp trace?
- Hal: that is one resolution
- Prateek: can see intermediaries indicating that they touched a msg
  at particular instances
- Hal: if receiver can't determine that it has/hasn't seen a nonce
  before, other timestamps in message won't help
- Peter Dapkus: most of the content for timestamp trace had to do
  with time synch, which didn't seem reasonable, but if there are 
  other usecases, that could be fine
- Peter Rostin: better approach for time synch could be a party
  vouching for time synch of previous hops (agreeing with notion of
  dropping timestamp trace, and possibly expiration)
- timestamp trace doesn't completely solve the time synch problem
- thinks we should drop both, but if only one, timestamp trace should
  be dropped
- Chris: need to separate these into different issues
- may have the same resolution
- Timestamp trace discussion
    - we've discussed this considerably already
    - resolution is to remove this from core and possibly put into
      another doc
- Expires discussion
    - we haven't discussed this much yet
    - Chris: looking for opinions on this
    - thinks intention was for sender to express desired expiration
      of message
    - thinks that is security-related
    - Tony: considers this much like proposal to include token labeling
    - we're leaving the semantics open
    - Peter Dapkus: that seems circular
    - Chris: do we agree that sender expressing expiration is a good
    - [think so]
    - Chris: there is an expiration element, that says semantics will
      be specified elsewhere, but there is a timestamp header, and if
      expiration is included, the semantics are clearly spelled out
    - Frederick: not sure how to reconcile this with semantics in
      Reliable Messaging
    - Chris: we have this notion of expiration that can be reused, and
      we defined the Expires element
    - then we defined a specific use, with the Timestamp header, where
      the presence of expires has specific semantics
    - [this didn't appear to be clear to everyone previously]
    - Tim: for parallel, X509 has separate expiration of public keys
      and private keys
    - [looking at spec, draft-13, Section 10.3 Timestamp Header]
    - Peter Dapkus: still seems like sender isn't guaranteed after
      sending the message
    - Chris: how guaranteed are we of anything after sending?
    - Jeff: depends on the protocol, TCP guarantees you a reliable
    - Hal: we should have enough mechanisms to prevent things like
      replay attacks
    - this doesn't seem to be in same category as relay attack
    - Peter Rostin: this doesn't address replay problem
    - Chris: actually, it does, because it limits the window of 
      usefulness, after which, replay wouldn't benefit anything
    - in this scenario, there is an acceptable replay window
    - John: in a farm scenario, it's hard to manage sequence numbers
      so an acceptable relay window approach has been taken
    - Hal: traditional approach to security engineering is to identify
      threats and to devise complete ways to defeat those threats
    - this seems incomplete, and likely to bite us later
    - Tony: this is just like expiration of certificates
    - Peter Rostin: difference in the significance of clock skew
    - for a 10 year cert, skew of an hour is insignificant
    - with WS-Sec messages, 1 hour of clock skew seems very significant
    - Phill: thinks discussion this belongs in WS-SecureConversation
    - Chris: disagrees, thinks we need a primitive at the base level
    - John: +1, there are situations where entities don't want to or 
      can't establish a session, and can't manage sequence numbers,
      and want to use an expiration directive
    - Tony: suggests we change lines 1263-1264 of core-13:
      change "it is STRONGLY RECOMMENDED that recipients ..." to 
      "Recipients MUST ..."
    - Peter Rostin: relative to receiver's clock?
    - Tony: that issue applies to many areas, so why choke on it here?
    - John: are we disagreeing over MUST?
    - STRONGLY RECOMMENDED was used to allow for clock skew issues,
      where reliable determination can't be made
    - Peter Rostin: can we clarify that expiration of the message is
      expiration of the security aspects of the message rather than
      some application-specific notion of expiration
    - [general agreement]
    - Jeff: doesn't understand requirement being met by expiring the
      security context of the message
    - Hal: thinks the model here is that applications don't want to
      see any messages that haven't "passed" the security layer
    - Chris: senders are providing authorization with their message,
      and it seems reasonable for them to express when that authZ
    - Jeff: one scenario is timestamps on security token, but currently
      not all token formats have timestamp header defined
    - could use token wrapper with the timestamp header, and could
      specify that all tokens operate within their expiration period
    - Chris: could be an alternative for that scenario, but there are
      other scenarios
    - Jeff: this seems to bleed over into reliable messaging
    - Tony: lots of areas have similar notions
    - Jeff: agrees, but thinks this is a layering matter
    - Tony: describes scenario with one message where you want to set
      an expiration time, which has nothing to do with app-level
    - [discussion of clock synch issues]
    - Jeff: looking at WS-ReliableMessaging, and another proposal on
      their table, and they all have their own similar mechanisms, so
      in the case of a single message, what happens when both that
      layer mechanism is used and the WS-Sec mechanism is used?
    - Chris: there's an issue of bootstrapping to the RM approaches
    - there's also some competition between agendas, with RM trying
      to repeat messages, and Security trying to defeat repeats
    - Peter Dapkus: if we got clearer about how we are to evaluate
      times, he could get more comfortable
    - Chris: doesn't understand how this is any different than 
      receiving a cert with a 10 minute lifetime
    - Peter Dapkus: doesn't think 10 minute certs are practical
    - Peter Rostin: even if the problem is the same in principle, it
      is different in practice due to the scale of time periods
    - Chris: thinks those differences aren't there with Kerberos
    - Phill: now convinced that we need the expires field
    - larger argument is whether this should have been taken up by
      SOAP, but since they haven't, Security is the next best place
      for it
    - Prateek: so is expiration linked to a credential or does it
      apply to whole message?
    - Hal: we were discussing dropping the free standing expiration
      and keeping the timestamp header
    - Frederick: have we required the use of synch'ed clocks in order
      to use WS-Sec?
    - returning to Tony's proposal
    - Peter Rostin: amends with clarification excluding application-
      level expiration concepts
    - Gene: so what should happen
    - Chris: we should make wording clearly apply to discarding the
      security context of the message, not necessarily the whole
      message itself
    - Jeff: there's a meta-level issue in lines 1242-1244, with other
      parties stuffing other timestamp actions in there
    - [ACTION] Editors to 1) change lines 1263-1264 of core-13 from "it
      is STRONGLY RECOMMENDED that recipients ..." to "Recipients MUST
      ..."; 2) change introductory paragraph around lines 1234-...,
      clarifying the expiration for security purposes rather than
      application purposes, and clarifying the consideration of clock
    - Martijn: how is Timestamp header related to Security header?
    - Charles: should it be a child of Security header?
    - Chris: according to spec, there is only one Security header and
      one Timestamp header per role
    - Hal: Section 10.3 reads like intermediaries can add Timestamps
    - Chris: intention of that sentence line (1239) was for "if" to be 
      "only if"
    - There should only be one timestamp per actor
    - Martijn: so why not make Timestamp a child of Security?
    - Eric: original description of Timestamp was that it applied to
      the data in the message, but with the change to making it apply
      just to the security aspects, this move seems appropriate
    - [ACTION] Editors to make Timestamp header a child of Security
      header, and to remove the ability of Expires to stand alone 
      (section 10.2.2 moves to child of section 10.3)
    - Jeff: lines 1243-1244 need to be fixed, seems indeterminate
    - sentence is broken, and intent is unclear
    - [ACTION] Editors to clarify lines 1243-1244 of core-13
    - Jeff: meta issue around 1188
    - does this belong here, or does utility schema belong in separate
    - deferring this discussion until later
    - Peter Dapkus: should sender choose expiration value based on
      guess of receiver's clock, or should receiver evaluate expiration
      value based on guess of skew from sender's clock?
    - third case is to NOT factor any guess of skew
    - will defer this until tomorrow, after folks have chance to sleep
      on it
    - Kelvin: suggests closing this point, and allowing anyone with
      strong feelings/questions to open new issue
    - mark PENDING



Attendance of Voting Members:

Attendance of Observers or Prospective Members:


Membership Status Changes:


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]