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