[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]