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 Telecon, Tuesday 06 May 2003


Minutes for WSSTC Telecon, Tuesday 06 May 2003
Dial in info: 1-405-244-5555 Passcode: 6921
Minutes taken by Steve Anderson

======================================================================
                              Summary
======================================================================

  Votes:
  
    - Minutes from 22 April 2003 meeting accepted (unanimous)
  
  New (General) Action Items:
  
    - Chris & Kelvin to flesh out answers to Don's timeline email and
      propose to the TC

  Issues List Action Items & Status Updates:
  
    - 76:
        - wsu:id is not for what you're pointing at, but rather how you 
          refer to the containing element
        - move to PENDING
    - 78:
        - PhillHB to add clarifying text and Tim will review
        - move to PENDING
    - 79:
        - two proposals from Chris:
            - the X509 profile should state use of single cert for the
              X509 value type, and if something like a PKCS7 chain is 
              desired, another value type should be used
            - second, state that standard X509 processing rules apply,
              and you might find related certs in other binary tokens in
              the message
        - move to PENDING
    - 81:
        - STR usage attribute should support multiple usages, via 
          QName list
        - move to PENDING
    - 83:
        - was PENDING, now CLOSED
    - 85:
        - CLOSED
    
======================================================================
                             Raw Notes
======================================================================

> 
> Agenda:
> 
> 1. Roll call
>

- Attendance attached to bottom of these minutes
- Quorum achieved

> 
> 2. Review minutes from previous meeting (4/22/2003)
>    < http://lists.oasis-open.org/archives/wss/200304/msg00050.html >
>

- [VOTE] unanimous consent, accepted

> 
> 3.  Interop/F2F straw poll results
>

- Chris: results
    - of the 4 weeks, observed inconsistent voting, for one week or
      multiple weeks
    - had conflicting votes from given companies
    - 4th week had lowest votes for F2F, by a significant margin
    - 1st week had fewest votes for interop
    - 2nd & 3rd were fairly even
    - proposes just going around and asking what companies will have
      implementations ready for 2nd or 3rd week
- Hal: didn't appear that any of the weeks had enough votes to suggest
  quorum
- John Weiland: was confused about implication of vote, for interop vs.
  F2F
- Chris: we should decide between 2nd & 3rd week on phone now
    - for 2nd week, who would have implementations?
        - MS, BEA, IBM, Systinet, SAP, VeriSign, RSA, Hitachi, Fujitsu
          will
        - HP, Navy, Sun, AmberPoint, Oracle will not
    - for 3rd week
        - MS, BEA, IBM, Systinet, SAP, VeriSign, Hitachi, Fujitsu
            - BEA would prefer 2nd week
        - RSA, Sun not certain
        - HP, Navy, ContentGuard, AmberPoint, Oracle, Novell will not
    - who couldn't attend F2F in 2nd week in SF
        - Don Adams:
        - Ron: most of Sun could not
        - Jerry: personal commit
        - PhilG: same
        - Frederick: same
        - Jan: cannot, but could make 3rd
    - who couldn't make 3rd week
        - Paul
        - Hal: preference for 2nd week, but could do 3rd
        - Pete Rostin
        - Hemma
        - Martin
        - Jason
        - Irving: prefers 2rd
    - for those that can't make 2nd week, would dial-in help
        - Ron: no
        - DonA: maybe
        - PhilG: yes
        - Frederick: maybe
        - Systinet: no
    - If we do it 2nd week with dial-in, we seem to maximize interop
      and F2F participants
- Paul: do we have a host?
    - Chris: we can sort that out
- Ron: do you think a poll of the entire membership on just this 
  question would help determine whether we'd have quorum?
    - Chris: based on today's attendance, and the small number of 
      negative indications, we should have quorum
- PhilG: so there will be dial-in?
    - Chris: yes, appears we'll need that
    - PhilG: that will help
- Kelvin: any volunteers to host, please contact
- Paul: concerning meetings, will we continue on a bi-weekly basis
  through the summer
    - Kelvin: would like to make it weekly, but didn't appear like
      people's schedules would permit
    - Paul: will the F2F be on the 'on' week or 'off'?
    - it's the 'off' week
    - Paul: will be keep the before & after phone calls, making 3 in a 
      row?
    - Kelvin: yes

> 
> 4. Interop scenarios and updates
>

- Hal: thinks it's basically good to go
- latest is draft 2
- most valuable feedback would be from someone coding against it
- Chris: still needs to update the schema
- Hal: thought someone else was going to post URLs for wsu and
  wsee
- Prateek: question on relative ordering in header and encrypted key,
  do we have clarity on that?
- Hal: still working through it, but thinks the way it's stated is
  correct
- Hal: there was an item concerning X509 profile and the key identifier
    - PhillHB: working on it, talking with Tim Moses
    - discussion of using 2 key pairs vs 4, resolved to keep to 2 pairs
- Hal: one of the logistic questions is who will produce certificates
  and send them
    - also need to generate a username/password list
    - Chris: will put cert generation on his list
    - Hal: assumes everyone will intend to act as sender & receiver, so
      everyone will need both sets of keys
- Hal: interested in feedback from developers on what has been left out
    - hopes to reuse this to document the usage of mechanisms described
      in other docs
- Kelvin/Chris: thanks Hal for taking this over

> 
> 5. WSNR submission
>    < http://lists.oasis-open.org/archives/wss/200304/msg00016.html >
>

- Kelvin: Eric is asking the TC to consider taking this doc on
- needs IPR clarification, and a general overview
- Eric: license has been re-outlined as RF, and there are no known IP
  issues with it
    - currently with signature, receiver knows signed data hasn't been
      altered
    - receiver does not know that response is related to a previously 
      sent message
    - receiver could have previously sent a message with a request for
      a signed receipt, which, if honored by sender, will fulfill this
    - split signature into two parts, one for a request and one for a
      response
- Kelvin: name has changed from 'non-repudiation' to 'receipt token
  profile'
- Don Adams: has looked at this several times, and the 'non-repudiation'
  term caused problems, but the new terminology makes it a reasonable
  submission
- Jerry: concerned with nature of responses, mechanism by which 
  response is directed somewhere
    - being dealt with in WS-Addressing
    - if this could be addressed in this document, that would be
      preferable
- Hal: had raised the possibility of an amplifier DOS attack
    - attacker does small amount of work and causes others to do large
      amounts of work
    - PhillHB: this problem will need to be handled at a higher level
      anyway, identifying the unacceptability of a message before doing
      expensive operations like signature verification
- Ron: thinks this is generally necessary, but not sure how policy
  relates
    - Eric: likely that the request for response will need to be rolled
      into policy
    - Ron: 
- Paul: how would this be used with existing profiles? orthogonal, used
  on top of the others?
    - Eric: thinks so
- Paul: does this profile imagine this would be used on every message?
    - < ... missed response ... >
- Chris: proposes we have a more detailed discussion on next call

> 
> 6. Discuss XKMS request that we review their specs (10 minutes)
>

- Kelvin: reminds everyone that we've been asked by XKMS group to 
  provide feedback as a TC
    - send comments in and we'll collate them

> 
> 7. Editorial updates/document status [Editors]
>

- Chris: would like an update from PhillHB & Ron
- Ron: did post update to SAML profile
    - looks like PDF writer overlaid some portions, so if people see
      oddities, let him know
    - had some issues with terminology from SAML
    - there are 2 version, with/without changebars
    - will regenerate PDF
- PhillHB: no updates, but he & Tim know what to do, and he'll be
  doing it
- Kelvin: so the SAML profile is pretty stable?
    - Ron: not comfortable with examples
    - could still be terminology changes
- Kelvin: how about Phill's doc set
    - PhillHB: X509 & Kerb, we know what to do, and it's a few edits
    - XrML has some naming issues brought up by ContentGuard, and it
      needs examples
    - does anyone have anything to help generate examples?
    - (no response)
    - Kelvin: should but out an email request for examples
- any other editors?
    - PhilG: XCBF is fairly stable, but could use more examples, and 
      definitely more feedback
    - also not sure how this will get integrated into any username
      profile
- Prateek: there is a SAML 1.1 Last Call process going on, and he'll
  be sending an email over regarding that
- Kelvin: we don't have Tony on call

> 
> 8. Discussion of open issues, review latest issues list
>    < http://www.oasis-open.org/archives/wss/200305/msg00021.html >
>

- we'll start where we left off last week, which was 76
- 76: X.509 profile issue 1: Is it desirable to use same element as 
  reference and referrent?
    - Chris: we put text in core, and thinks there was misunderstanding
    - we should make that more clear
    - wsu:id is not for what you're pointing at, but rather how you 
      refer to the containing element
    - can move this to PENDING
    - [ACTION] PhillHB to clarify for issue 76
- 77: X.509 profile issue 2: In Section 3.4, the proposal should be
  more fully described. Why would one not just put the wsu:id in the
  ds:keyName element of the ds:keyInfo
    - Ron: thinks this could be done, no reason you couldn't
    - Chris: keyName is not strongly-typed, so you wouldn't know it's 
      an id
    - Jerry: we can make that part of the profile
    - Chris: keyName is typically an X.500 DN, so this would be a little
      inconsistent
    - Ron: this is a reference to a cert, so there is a little wiggle
      room
    - SAML also used it slightly different
    - Chris: maybe we should defer until Tim is on call
    - Hal: DN wouldn't uniquely identify a key/cert anyway
    - PhillHB: keyName is recommended to have issuer DN and serial
      number, which is as unique as you can get in X509
    - defer
- 78: X.509 profile issue 3: Under what circumstances would one need
  to reference an X.509 certificate containing an encryption key?
    - PhillHB will add text explaining this and Tim will review
    - PENDING
- 79: X.509 profile issue 4: It might be necessary to carry more than
  one certificate. It should be explained which element needs to be
  duplicated in order to convey multiple certificates.
    - Hal: summary: can you put 2 certs in a binary token?
    - like for a PKCS7 cert chain
    - Hal: this is a question of syntax in this binary token
    - Kelvin: need a clarification, which PhillHB can write up
    - Ron: believes PKIX folks defined an ASN.1 encoding of a cert
      chain, which can be put in binary token element
    - PhillHB: PKIX stuff is generally ignored
    - would prefer to follow XML Signature
    - Chris: thinks Tim is just asking us to describe how those are
      used/interpreted in the binary token
    - PhillHB: never thought it made any sense to use binary tokens for
      certs when XML Signature already has a means of expressing a 
      cert in XML
    - Chris: proposes the X509 profile should state use of single cert
      for the X509 value type, and if something like a PKCS7 chain is 
      desired, another value type should be used
    - second, state that standard X509 processing rules apply, and you
      might find related certs in other binary tokens in the message
    - PENDING
    - Ron: should be make an issue of PhillHB's comment on the value
      of binary tokens for X509?
        - Chris: this is been brought up and answered twice before
        - Hal: PhillHB could make a concrete proposal on list and
          we can consider it
        - Chris: notes that XML Signature is closed, and we can't add
          things like wsu:id
        - Jerry: we can use our STR wrapper
- 80: X.509 profile issue 5: Suggest MUST use common error codes
    - John: seems harsh
    - Chris: didn't understand precedent of error codes
    - Hal: could return the first one you discover
    - thinks Tim is looking for some minimal set of codes that must be
      supported
    - Ron: in SAML profile, tried to use the ones in core
    - pattern could be used here
    - this will be examined and considered on next call
- 81: Question on STR usage attribute: Does the definition of the usage
  attribute of STR allow for the association of multiple usage
  annotations with an STR?
    - Ron: didn't believe it did
    - yes, it should support multiple usages, via QName list
    - will fix in schema
    - PENDING
- 82: Scrub specs and update links to other specifications
    - Kelvin: some have been fixed, but there are more
- 83: <xenc:EncryptedData> element should precede the 
  <xenc:EncryptedKey/> element in the interop scenario.
    - Hal: was pending, but can now be closed, since there haven't been
      any comments to the change
- 84: Comment on Core Spec and Interop Scenario #3 - Decryption
  Transform. Ordering semantics of the <wsse:Security> header can not
  be used in all cases to determine the encryption and signature
  ordering. Perhaps we should require use of the Decryption Transform
  on all signatures or at least in every case when both encryption and
  signatures are being used.
    - Hal: had written an email about this this morning
      < http://www.oasis-open.org/archives/wss/200305/msg00022.html >
    - people need to decide whether multiple recipients use case is
      necessary
    - Hal: will write up proposal and circulate
    - Jerry: how does this affect the MinimalProfile?
    - seems consistent, but could use more verification
- 85: Post a draft of F2F questions. Paul Cotton has posted draft
    - CLOSED
- 86: Non-repudiation proposal to be included as part of WS-Security
    - Chris: we've had the first proposal today
    - stays open
- 87: Add a profile for XKMS to WS-Security
    - until everyone gets to review XKMS, this would be premature
- 62: 
    - Ron: sent problem description to list
    - didn't receive any other comments
    - Chris: folks need to review this

> 
> 9. Other business
>

- Kelvin: Don Flinn sent note to list concerning our original 6 month
  timeframe
    - he and Chris need to draw up a timeline for completion
    - Hal: we need to decide if we are going to sign up for core and
      5-6 profiles all at once
    - Don: laid out 5 questions we need to ask ourselves in the email
    - Kelvin: these seem like the right questions
    - Don: thinks there will be a 1.0 & a 1.1, so what profiles will
      go in which release?
    - [ACTION] Chris & Kelvin to flesh out answers to Don's timeline 
      email and propose to the TC

> 
> 10. Adjourn
>

- Adjourned


-----------------------------------------------------------------------

Attendance of Voting Members:

  Gene Thurston AmberPoint
  Merlin Hughes Baltimore Technologies
  Irving Reid Baltimore Technologies
  Hal Lockhart BEA
  Symon Chang CommerceOne
  Guillermo Lao ContentGuard
  TJ Pannu ContentGuard
  Shawn Sharp Cyclone Commerce
  Ganesh Vaideeswaran Documentum
  Sam Wei Documentum
  Toshihiro Nishimura Fujitsu
  Yutaka Kudo Hitachi
  Jason Rouault HP
  Kelvin Lawrence IBM
  Nataraj Nagaratnam IBM
  Don Flinn Individual
  Phil Griffin Individual
  Bob Morgan Individual
  Venkat Danda IONA Technology
  Paul Cotton Microsoft
  Chris Kaler Microsoft
  John Shewchuk Microsoft
  Prateek Mishra Netegrity
  Frederick Hirsch Nokia
  Lloyd Burch Novell
  Ed Reed Novell
  Steve Anderson OpenNetwork
  Vipin Samar Oracle
  Jerry Schwarz Oracle
  Eric Gravengaard Reactivity
  Rob Philpott RSA Security
  Peter Rostin RSA Security
  Martijn de Boer SAP
  Pete Wenzel SeeBeyond
  Yassir Elley Sun Microsystems
  Jeff Hodges Sun Microsystems
  Ronald Monzillo Sun Microsystems
  Sirish Vepa Sybase
  Jan Alexander Systinet
  Don Adams TIBCO
  John Weiland US Navy
  Phillip Hallam-Baker VeriSign
  Hemma Prafullchandra VeriSign
  
    
Attendance of Observers or Prospective Members:

  Vijay Gajjala Microsoft
  Padraig Moloney NASA
  Andrew Nash RSA Security
  

Membership Status Changes:

  Vijay Gajjala Microsoft - Granted voting status after 5/6 call
  Clifford Thompson Individual - Granted voting status after 5/6 call
  Padraig Moloney NASA - Granted voting status after 5/6 call
  Tom Rutt Fujitsu - Requested membership 5/1/2003
  Rich Salz Data Power - Lost status due to inactivity


--
Steve



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