[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Consolidated minutes to 11-12 June F2F
Sorry for the late posting ... * Combined all 3 sets of minutes * Pulled summary together at the top * Updated attendance * Updated with correction from Gene <<2003-06-11+12-F2F-minutes.txt>> -- Steve
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, John Weiland, Merlin Hughes
======================================================================
Summary
======================================================================
Votes:
- 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
elements
- 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
- Chris and Kelvin to compile lists of contributors
- Editors to change the text on reporting faults; may already be
noted
- Merlin to post Signature transform text
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
- 73: marked CLOSED
- 74: maked PENDING
- awaiting text from Hal & Merlin
- 76-79: Tim to provide a reference to the latest X509 standard
- 80: marked PENDING
- 84: Tony to propose edits and/or provide history
- 87: marked CLOSED, no owner
- 88: marked CLOSED, duplicate of 11
- 89: marked CLOSED
- Chris to post an email identifying why it would not work in
practice
- 90: marked PENDING, with the following updated needed to text:
- 1. clarify id on line 728 other things can sign this
- 2. 742 - 743 should show embedded saml token
- 3. 730 733 contain cut and paste error should say embedded
rather than KeyIdenfier.
- 91: marked CLOSED, interop issue
- 94: marked PENDING, Editorial update fixed in next release
- 95: marked PENDING, Editors to clarify utilization.
- 96: marked PENDING
- items except 5 & 8 are non-controversial editorial items
- item 5: resolved as editorial update
- item 8: no change warranted
- 97: marked PENDING, Editors to update document to define an order,
schema should match the document
- 98: marked PENDING, Hal and Thomas will work on proposed text
- New issue (Merlin): Remove the section on token reference lookup
processing order?
- New issue (Merlin): Should STR -> BST ValueType be a BST, not an
X509v3
- New issue (Martijn): Timestamps associated with individual tokens
- New issue (Chris/Eric): Discuss deleting section 9.3
======================================================================
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
uses
- 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
implementations
- 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
tests
- 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
padding
- 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
implementation
- 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
crisp
- 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
directive
- 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
it
- 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
time
- Chris: thought that was already in there
- says UTC format, which is different than the timezone of the
value
- 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
it
- 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
supported
- 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
objections
- PENDING
>
> 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
docs
- 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
area
- 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/
specs
- 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-
related
- 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
anyway
- 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
thing?
- [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
stream
- Hal: we should have enough mechanisms to prevent things like
replay attacks
- this doesn't seem to be in same category as relay attack
prevention
- 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
expires
- 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 if a RESPONSE message has "expired"?
What does it means for a client to "discard" the response?
- 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
skew
- 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
doc
- 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
[NEW MINUTE-TAKER TAKING OVER HERE (John Weiland)]
>
>Issue 73 - What tokens are allowed within Token Reference? Add an embedded reference, but this isn't well defined>
>
- Editors were to make proposal - Jerry's issue (not present)
- Either enumerate or define tokens or non-tokens. Definition of security tokens but extensible nature leaves this in doubt.
- line 214 defines the definition.
- Is a signature or a security manifest a type of security token?
- No one present could argue that a signature represents a claim.
- mark it closed.
>
>Issue 74 - Encrypting a password. Points of discussion:
>
1. Should we encrypt password, username or the entire UsernameToken element?
2. Should we add an XCBF parameter to Usernametoken? Should this be used in interop?
3. If interop model is viewed as guidance from the TC on secure usages, shouldn't it be secure completely?
4. How do we balance against existing deployments, which require passwords in the clear?
- Hal submitted text to satisfy this Issue. <WSS Message dated Jun 2>
- Merlin made additional internal reference issues.
- Solution: Put in password token profile, internal reference will be fixed in Hal's text.
- Pending text from Hal and Merlin
>
>Issue 74 Still Pending Due phoncon next week.
>
>
>Issue 76 - 79 pending Tim Moses review. Still pending.
>
- Action provide a reference to the latest X509 standard
>
>Issue 80 - X.509 profile issue 5: Suggest MUST use common error codes
>
- Move to Pending
>
>Issue 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.
- Background - Signatures can be in any order, multiple encryption that overlap need to be in right order.
- Proposal: determine order to process by message rather than policy.
- Tokens should be placed just prior to use to eliminate ambiguity. <WSS Message> dated Jun 2>
- A must in the absence of other agreements or encryption transform is not specified.
- Action defer to tomorrow after examination.
>
>Issue 86 - defer to tomorrow.
>
>
>Issue 87 - no owner Add a profile for XKMS to WS-Security Action - Close.
>
>
>Issue 88 - Deferred to what are our next steps proposal. Closed as duplicate of Issue 11.
>
>
>Issue 89 - Proposal for making Binary Token and XML Token to be abstract types.
>
- Don's issue - Technical flaw pointed out may work in theory but not in practice.
- Close Issue
- Action - Chris will post an email identifying why it would not work in practice.
>
>Issue 90 - Clarification needed on wsse:Embedded.
>
Is the motivation for wsse:Embedded to have the token literally embedded in an STR?
If so, the examples with wsu:Id seem incorrect.
- Updates needed to text -
- 1. clarify id on line 728 other things can sign this
- 2. 742 - 743 should show embedded saml token
- 3. 730 733 contain cut and paste error should say embedded rather than KeyIdenfier.
- Action 90 to pending, awaiting updates.
>
>Issue 91 - closed interop issue SOAP 1.1 and 1.2 differ 1 or 0 rather than True False
>
>
>Issue 94 - Embedded missing from STR preferred. Embedded References were not added to the list in lines 642-648
>
- Pending fixed in next release. Editorial update
>
>Issue 95 - The xmlenc schema does not specify anyAttribute;
>
I think this means that the permitted attributes of EncryptedData are fixed,
and the original unqualified Id attribute would then be correct.
- Pending
- Action editors will clarify utilization.
>
>Issue 96 - Subjects 5 and 8 are most important, other items are mostly editorial.
>
v) Lines 562-566:
Why is it RECOMMENDED that the namespace prefixes be declared within the wsse:BinarySecurityToken element?
They have to be declared somewhere, in order for the QName to have meaning;
so I'm not sure what this recommendation is adding. If anything, shouldn't we be requiring that exclusive c14n,
if used, include any non-visibly-utilized namespace prefixes in its unsuppressed prefix list?
- Action - editorial update approved.
viii) Line 615:
Does wsse:Usage deserve to be a global attribute? It only appears to be used once.
- Action - No change warranted.
>
>Issue 97 - i) Whitespace The examples appear to have spaces around usernames, passwords, created.
We should state whether or not whitespace is significant, and possibly update the examples.
Is the encoded form of the Created element ' 2001...Z ' or '2001...Z'?
- Is whitespace stripped prior to digest. Whitespace should be preserved.
ii) Ordering The schema doesn't specify an element order. Does our UsernameToken profile mandate the order
Username,Password,Nonce?,Created? or is any order valid, or should we make the schema more strict?
- Action - Update document to define an order, schema should match the document.
- Pending editorial action
>
> Issue 98
>
- Hal asks Should validity checking occur at security layer or within the application.
- Pending
- Action - Hal and Thomas will work on proposed text to address this issue.
>
>Issue 25 was discussed because Thomas was not available earlier.
>
- Pending Thomas concurs.
>
>Message number 49 in May was discussed, resolved in next version.
>
Other Business
- Reminder there will be a call next week even though it will be so close to the F2F.
- Documentation discussed, contributor list procedure. SAML 1.0 document used as a template.
- Action to Chris and Kelvin to compile lists of contributors.
- Ok agenda tomorrow
- 830 start discuss milestones, straw man roadmap. Road to version 1. revisit 84, 86, and 11.
- Groundwork for v1 vote.
Homework - read roadmap email be ready to discuss.
[NEW MINUTE-TAKER TAKING OVER HERE (Merlin Hughes)]
EG: Presentation - Receipt Profile
CK: What do you mean by crypto proof of rcpt; versus ACKs.
EG: No proof that you got my msg unaltered in existing rcpt mechanisms.
AN: Reliable Messaging uses ACK/NACK; sign the ACK..
EG: If the signature was lifted from msg, how does sender know that
signature was received and verified.. Tony gets in the middle,
modifies msg & removes sig. You know that the recipient is making
a statement that they received something.
CK: Don't you get into Gray's conundrum (Jim Gray) - only way I can
get receipt is for you to reliably transmit it; for this we need
an RM protocol so I need to ACK, & you need to ACK...
EG: Only works in success case when both msgs get thru. Could use with
RM protocol. Without RM, not getting receipt means nothing.
CK: What guarantees do I get?
HL: When you get done you hav an audit trail.
CK: RM session with policy that we'll require and check signatures
then a signed ACK is sufficient.
EG: If responding party is lazy & doesn't check sig, they can repudiate
signature & you have no proof that msg was unaltered.
CK: Stay at technical vs legal level: What's the difference between
this & BEA ACK. What are semantics of no RCPT?
SA: Without this I could get a response suggesting that something
was done right when it wasn't. This gives a cryptographic audit
trail.
CK: Isn't this RM?
EG: Crypto chain of evidence.
PHB: Useful and necessary to have in stack; had to invent it for XKMS,
don't want to have to do this for everything else. Is this WSS
or sec conversation or RM?
SA: Almost in RM. Why not get them to fix it.
EG: This is useful in unreliable sense.
PHB: What does this committee do post WSS 1.0?
KL: Core + profiles; then we make that decision on what next. This
might be appropriate for another TC.
PHB: RM not crypto secure; not necessarily a good match.
HL: We seem to be providing crypto building blocks; receipts
not necessarily a bad match for us. Secure conv & policy
don't seem a good match.
PHB: Motion to table & revisit after discussion of future.
Issue 84 from yesterday..
CK: Why is encrypting a signature with this spec difficult?
HL: Strike the sentence..
AN: Disagree with not allowing dcrpt transforms as part of the base
spec.
MH: Disagree that recipient needs to look through all security
headers; only intended recipient will be able to perform
decryptions.
AN: Spec is not wrong; may need clarification. Need to revisit
old notes on why dcrpt transform is needed.
HL: Attn my original msg on these issues; will repost.
CK: Issue open; action: Tony propose edits &| provide history.
Goals moving forward:
KL: What is essential for 1.0 and when.
PHB: Core spec & Username & X.509 & SAML & XRML; Kerb has less work.
HL: Obs. Interop only tested username & X.509 & core.
AN: If core spec fairly stable then do v1 core spec, evolve profiles.
PC: Wearing WS-I hat; basic security profile WG; we have normative
ref to this group; we have 9 months from when WSS enters committee
spec. Our profile will be against core, username, X.509 & Kerb.
Just publishing core spec will not help us very much.
TJP: Try to get as many profiles out as possible; XRML & SAML are
fairly mature..
RM: Are there plans for more interops.
GH? Need at least one more. Should we push some small list of
specs out quickly?
KL: Do we do another interop soon testing much of core spec & username/x509,
deliver these as 1.0 & others as a rapid 1.1 or a larger 1.0?
CK: WSI needs username, x509 & kerb.
DF: No need for all profiles to be on same timeframe as core.
HL: General agreement for that.
GH? Can have all profiles on v1.0 just with different timeframes.
KL: What's minimal first deliverable:
SS & many others: Core, username, X.509.
FS: Integration with WS trust & secure conv!
AN: Would also like kerb, XRML.
JM: Would also like SAML.
PM: Should have one of the XML tokens SAML/XRML.
PHB: Kerberos could invoke beasts from swamp; would be good to look at it ASAP.
CK: Kerb good to look at after username/X.509.
RM: SAML very important.
DF: Incumbent on us to get min spec out quickly. Core, username, X.509.
Others can be run on a parallel path.
PW: Core & X.509 cover a lot of the interesting use cases.
ER: SAML should not _too_ far behind.
KL: General consensus around core & u/n & x.509; SAML & kerb; XRML.
RM: Can we have non-first-track profiles in interop along with cores.
CK: Concerned about delaying core profiles.
MH: Virtual interops might work for us at this stage.
KL: How many thing core & 2 need more interop before v1.
TN: What are the uncomfortable issues on this spec.
KL: Just a finite number of issues untested.
phone: Could declare committee spec now & have interop as part of public
review.
GH: At least one more full-fledged interop preferably with further
profiles. More scenarios will provide greater assurance to OASIS
to accept this.
CK: Don't believe we can pull together a short-order physical interop.
People should agree to virtual interop. Should agree finite list
of things to interop test.
HL will work on new interop scenarios based on list.
Key interop things:
MH: Signature transforms, X.509 multiple certs, embedded
??: Specific fault codes; negative testing.
??: Timestamps w/ signatures.
RM: Different orders of tokens.
CK: Lets avoid conformance testing.
PR: Support for multiple key tokens (sign vs encrypt).
PC: Underlying signature tests?
EG: Attachments.
??: Bare reference lists.
RM: Token processing order.
CK: PKIPath/PKCS7 is well known; why test.
PHB: We're not using it in classical sense.
RM: Aren't we recommending PKIPath.
RM: Some profiles don't reference core fault coeds
AN: We should fix that outside of interop testing
MH: Fault codes are conformance testing, not spec testing
@RSA: But maybe the spec isn't clear which faults to return when.
RM: KeyInfo content order
MH: Hard to test without contrived; what's the point of it.
Issue: Remove the section on token reference lookup processing order?
It buys nothing.
@RSA: At least one test with multiple sign/encryptions.
CK: Multiple SOAP headers just tests actor/role.
EG: 9.3 has a section on encrypting attachments; should be tested.
CK: What attachment spec? Maybe we should remove 9.3.
EG: Reasonable to remove it as long as we readdress it when SOAP 1.2
finishes.
Action: Discuss deleting section 9.3.
Standalone ReferenceList is a novel use so we should test it.
Encryption & signature in different order depends on a resolution
to the open decryption transform / etc. issue.
RM: ValueType tests?
CK: We only have b64.
RM: References with non-local URIs.;
CK: What would this be testing wrt WSS; it's an XMLDSIG issue.
MH: Issue for the list; should STR -> BST ValueType be a BST, not an X509v3.
RM: Fault codes need testing.
MH: This just needs spec auditing.
KL: We don't require you to return a fault so we can't test it.
RM: Text says 'report' fault.
CK: Decided on phone that this does not need to be returned.
Action: Change the text on reporting faults; may already be noted.
MdB Need real-world scenario test cases when we test parts of spec.
How to associate Timestamp with signature.
MH/CK: Timestamp associated with security header, not signature or
individual token.
MdB: Action: Raise this issue.
@RSA: Expires needs more discussion on list, may need interop.
MH: Action: Post signature transform text.
KL: No violent objection to doing interop in parallel with ctte spec.
Timeframe for next virtual interop?
MH: 3 weeks after resolve interop-related issues?
AN: Not rehash old interop tests; focus on new interop tests.
CK: Beware 4 July. Plan on a call on the 24th to accelerate issue
resolution of issues? Est Jul 15th interop.
KL: Try to have vote for ctte spec before that.
Aim for July 1st vote on ctte spec?
CK: All v1 issues need to be on the table by June 17th.
KL: Will revisit receipt proposal.
-----------------------------------------------------------------------
Attendance of Voting Members:
Gene Thurston AmberPoint
Frank Siebenlist Argonne National Lab
Merlin Hughes Baltimore Technologies
Peter Dapkus BEA
Hal Lockhart BEA
Symon Chang CommerceOne
Thomas DeMartini ContentGuard
TJ Pannu ContentGuard
Shawn Sharp Cyclone Commerce
Sam Wei Documentum
Tim Moses Entrust
Toshihiro Nishimura Fujitsu
Jason Rouault HP
Yutaka Kudo Hitachi
Maryann Hondo IBM
Kelvin Lawrence IBM
Anthony Nadalin IBM
Nataraj Nagaratnam IBM
Don Flinn Individual
Phil Griffin Individual
Venkat Danda IONA Technology
Paul Cotton Microsoft
Vijay Gajjala Microsoft
Chris Kaler Microsoft
John Shewchuk Microsoft
Prateek Mishra Netegrity
Frederick Hirsch Nokia
Ed Reed Novell
Charles Knouse Oblix
Steve Anderson OpenNetwork
Eric Gravengaard Reactivity
Andrew Nash RSA Security
Peter Rostin RSA Security
Martijn de Boer SAP
Pete Wenzel SeeBeyond
Jeff Hodges Sun Microsystems
Ronald Monzillo Sun Microsystems
Jan Alexander Systinet
Michael Nguyen The IDA of Singapore
John Weiland US Navy
Phillip Hallam-Baker VeriSign
Attendance of Observers or Prospective Members:
Jonathan Tourzan Sony
Chris Kurt Microsoft
Jeff Turpin Cyclone Commerce
Henry Chung IBM
Takeshi Imamura IBM
Kojiro Nakayama Hitachi
Membership Status Changes:
Tom Rutt Fujitsu Granted voting status after F2F
Jonathan Tourzan Sony Granted voting status after F2F
Clifford Thompson Individual Lost voting status due to inactivity
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]