← Prev in month ← Prev in thread

Next in thread → Next in month →

[wss] Web Services Security Issues List #18

From: "Uijay Hajjala"
Date: 2003-06-17T05:12:52+00:00
ID
Thread: [wss] Web Services Security Issues List #18

Title: [wss] Web Services Security Issues List #18

<<wss-issues-18.htm>>

OASIS Web Services Security Issues List

Version 18, Modified on Monday June 16, 2003 22:11:58 -0700
Status

This table include issues from the June 12 meeting minutes
http://lists.oasis-open.org/archives/wss/200306/msg00091.html and on the issues list through June 17.

The previous version of the issues list is at

http://www.oasis-open.org/archives/wss/200306/msg00071.html. An archive of the discussion list can be found here: http://lists.oasis-open.org/archives/wss/.

If you identify items that are missing or need correction please contact John Shewchuk or Vijay
Gajjala.

Issues

WSS ID
Type
Status
Issue
Resolution
Owner(s)

1
Technical
Closed
Can we have alternative mechanisms of signature and encryption other
than XML DSIG and XML Encryption?
Closed on 10/8/02 - http://lists.oasis-open.org/archives/wss/200210/msg00085.html
Conformant implementations must support XML sig/enc and MAY support
additional mechanisms.
Closed

2
Procedural
Closed
Clarify the IP status and licensing terms for the submissions to
the working group
Closed on 9/24/02 - http://lists.oasis-open.org/archives/wss/200210/msg00011.html.
References Prateek Mishra's posting. http://lists.oasis-open.org/archives/wss/200208/msg00011.html.
Closed

3
Technical
Closed
Proposal to Label Tokens to Indicate Their Semantics

F2F Topic - Ronald Monzillo and Anthony Nadalin will send out a
proposed set of changes.

http://lists.oasis-open.org/archives/wss/200211/msg00184.html

Closed

4
Technical
Closed
Why is the token in the header, and not a child of KeyInfo?
Chris talked with PHB. Chris will write up a
proposal. http://lists.oasis-open.org/archives/wss/200212/msg00037.html

Closed

5
Technical
Closed
Within the KeyInfo, why not use a ds:RetrievalMethod?
Chris talked with PHB. Depends on 4 and conversation with
PHB.
http://lists.oasis-open.org/archives/wss/200212/msg00037.html
Closed

6
Investigation
Closed
Will the authors of the roadmap submit it?
Kelvin to update Road Map URL in WSS TC pages to the permanent URL. http://lists.oasis-open.org/archives/wss/200301/msg00073.html

Closed

7
Technical
Closed
Does WS-Security assume SOAP 1.1?
Per Sept 4 minutes – it will support all versions of SOAP
Closed

8
Investigation
Closed
Determine interest in a Use case document
Formed a sub-committee, led by Erik Herring. http://lists.oasis-open.org/archives/wss/200210/msg00127.html
Closed

9
Investigation
Closed.
Approach authors to submit the App Note to the TC
http://lists.oasis-open.org/archives/wss/200301/msg00073.html

Closed

10
Investigation
Closed
Investigate interop fest at some later time.
http://lists.oasis-open.org/archives/wss/200301/msg00073.html.
Closed planned interop event in the middle of June: http://lists.oasis-open.org/archives/wss/200304/msg00049.html

Chair

11
Investigation
Pending
Pick date for OASIS submission date after initial drafts
available

http://lists.oasis-open.org/archives/wss/200306/msg00025.html

Pending: agenda item for F2F
Chair

12
Procedural
Closed
Remove all references to ws-routing and such
References were removed.
Closed

13
Technical
Closed
Element ordering in the Security tag.
Editors instructed to clarify. http://lists.oasis-open.org/archives/wss/200210/msg00085.html
Closed

14
Technical
Closed
State that the recipient SHOULD authenticate the assertion issuer and
ensure that the assertion has not been modified
http://lists.oasis-open.org/archives/wss/200212/msg00037.html

Closed

15
Technical
Closed
Core: Spec should indicate that it is based on the SOAP messaging
model.
http://lists.oasis-open.org/archives/wss/200212/msg00037.html

Closed

16
Technical
Closed
Core: The spec should indicate that nonce and / or timestamp elements
should be used to prevent replay.
http://lists.oasis-open.org/archives/wss/200210/msg00085.html

Closed

17
Technical
Closed
Core: Should SOAP nodes acting in a particular role create or update
the appropriate timestamp element.
Editors instructed to clarify. http://lists.oasis-open.org/archives/wss/200209/msg00094.html
Closed

18
Technical
Closed
Core: No attribute or reference to the senders time.
http://lists.oasis-open.org/archives/wss/200210/msg00085.html

Closed

19
Technical
Closed
Core: Why is it necessary to special case a Username/Password POP
token?

http://lists.oasis-open.org/archives/wss/200302/msg00017.html

Closed

20
Technical
Closed
Core: Define security token propagation.
http://lists.oasis-open.org/archives/wss/200212/msg00037.html

Closed

21
Technical
Closed
Core: Update definition of a security token to reflect role in
defining key or broaden definition.
Was related to 2 and 22. http://lists.oasis-open.org/archives/wss/200210/msg00127.html

Closed

22
Technical
Closed
Core: Should the spec preclude security tokens whose purpose is other
than to convey or bind a key to an identity or entity?
Editors to clarify by added "entity" instead of "client". http://lists.oasis-open.org/archives/wss/200212/msg00037.html

Closed

23
Technical
Closed
Core: Make Proof-of-Possession a fundamental type or relationship
within [sic] within the ws-security model?
http://lists.oasis-open.org/archives/wss/200212/msg00037.html

Closed

24
Technical
Closed
Core: Why is it necessary to treat XML Signature elements as other
than security tokens?
http://lists.oasis-open.org/archives/wss/200212/msg00037.html

Closed

25
Technical

Closed

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

http://lists.oasis-open.org/archives/wss/200306/msg00025.html
Put scenarios on mailing list. Ron will dig up scenarios. The TC will try to close at the F2F. Ron will put a proposal to close this issue on the e-mail list.
Resolved to not support!
Closed

26
Technical
Closed
Core: What does it mean to process a BinarySecurityToken?

http://lists.oasis-open.org/archives/wss/200301/msg00000.html

Closed

27
Technical
Closed
Core: Reference element should have an @any to allow for attribute
extensibility
http://lists.oasis-open.org/archives/wss/200211/msg00184.html

Closed

28
Technical
Closed
SAML Binding: Include the use of the URI attribute (on
SecurityTokenReference) from the SS TC submission

http://lists.oasis-open.org/archives/wss/200302/msg00017.html

Closed

29
Technical
Closed
SAML Binding: Should there be a reference form that carries what
amounts to a SAML assertion Query such that the sender does not need to
have acquired the assertion (to be able to apply it to a request)?

http://lists.oasis-open.org/archives/wss/200212/msg00037.html

Closed

30
Technical

Pending

How should XML be explained.

http://lists.oasis-open.org/archives/wss/200306/msg00025.html
Pending: Chris will send e-mail to editors with explanation of what they are to do.
Editors

31
Technical
Pending
Should use OASIS Namespace

http://lists.oasis-open.org/archives/wss/200306/msg00025.html
Pending, waiting for OASIS to provide solution. For now proceed as is.

Karl Best had formed committee to solve this problem. The target to resolve is in 2 or three months.
Chair

32
Technical
Closed
A couple of parameter values are prescribed (e.g. SHA-1 in the case of
the password digest and “five minutes” in the case of message
freshness). The specification should be flexible in these
respects.
Closed in Draft 4 of Core specs. http://lists.oasis-open.org/archives/wss/200211/msg00184.html

Closed

33
Technical
Closed
The specification should prescribe clear behavior for all parties in
regard to freshness safeguards. And it should require that time
values be enclosed in integrity mechanisms.
Closed in Draft 4 of Core specs. http://lists.oasis-open.org/archives/wss/200211/msg00184.html

Closed

34
Technical
Closed
<wsu:Created> appears to be just a convenient way for the
originator to create a nonce. Therefore, it seems unnecessary to
require processing different from that required for the <wsu:Nonce>
element.
Closed in Draft 4 of Core specs. http://lists.oasis-open.org/archives/wss/200211/msg00184.html

Closed

35
Technical
Closed
Is it necessary to support the HexBinary encoding of tokens?
Closed in Draft 4 of Core specs. http://lists.oasis-open.org/archives/wss/200211/msg00184.html

Closed

36
Technical
Closed
In section 10.2.2, why not just specify that the <Created>
element type be xsd:dateTime?

http://lists.oasis-open.org/archives/wss/200301/msg00000.html

Closed

37
Technical
Closed
lines 193-195: Where does the threat of replay attacks belong to? To
the first or the second group?
Closed in Draft 4 of Core specs. http://lists.oasis-open.org/archives/wss/200211/msg00184.html

Closed

38
Technical
Closed
line 238: Since this is a normative text, how "inappropriate claims"
is defined here?
Pending owner’s examination of changes in Draft 4. http://lists.oasis-open.org/archives/wss/200211/msg00184.html

Closed

39
Technical
Closed
Lines 251-255: Since the UrenameToken element does not have password
digest, what is the purpose of the Nonce and Created elements
here?
http://lists.oasis-open.org/archives/wss/200212/msg00037.html

Closed

40
Technical
Closed
Paragraphs in lines 535-537 and 538-540 repeat each other and one of
them needs to be eliminated.
Closed. http://lists.oasis-open.org/archives/wss/200211/msg00044.html
Closed

41
Technical
Closed
Line 1016: what specification's section 4.5.3 does it refer to? The
above text implies XML Encryption. It should be explicit.
Closed. http://lists.oasis-open.org/archives/wss/200211/msg00044.html
Closed

42
Technical
Closed
Line 1155: the meaning of "materially" is unclear.
Pending Konstantine’s review of current text. http://lists.oasis-open.org/archives/wss/200211/msg00184.html

Closed

43
Technical
Closed
Lines 1430, 1431: The clause "these elements be included in the
signature" is unclear. What does "included in the signature" mean? Should
they be signed?
Closed. http://lists.oasis-open.org/archives/wss/200211/msg00044.html
Closed

44
Technical
Closed
SAML Cannonicalization
http://lists.oasis-open.org/archives/wss/200212/msg00037.html

Closed

45
Technical
Closed
WS_Security Core, Draft 3 uses "Multiple trust domains" on Lines 114
and 141 but never defines this term. "End-to-end message level
security" on line 141 is also not defined.
http://lists.oasis-open.org/archives/wss/200212/msg00037.html

Closed

46
Technical

Closed

WSDL definitions - It seems to me that a stand-alone specification
should just define the semantics of its elements. If an application
wants those semantics, then the application WSDL should specify the header
as being required.

http://lists.oasis-open.org/archives/wss/200301/msg00073.html

Hal: follow up and find out what the real issue is. Hal followed up:
http://lists.oasis-open.org/archives/wss/200305/msg00006.html

Closed

47
Technical
Closed
Add example. Working Draft 3. Page 21, Section 7.1, lines
644-648, recommends that <wsse:SecurityTokenReference> element
should be used as direct children of <ds:KeyInfo> elements to
retrieve signing and encryption certificate when using XML Signature and
XML Encryption. Although in section 8.4, there is a XML Signature example
for using <wsse:SecurityTokenReferences> element within the
<ds:signature>'s <ds:KeyInfo> element, there is no examples
provided to using SecurityTokenReference element for XML Encryption in
section 9. E.g., Section 9.2 does have a <wsse:KeyIdentifier>
contained within the <xenc:EncryptedKey> element. However, it does
not have the <wsse:securityTokenReference> element encapsulating the
<wsse:KeyIdentifier> as specified in section 7.3.

http://lists.oasis-open.org/archives/wss/200301/msg00073.html

Closed

48
Technical
Closed
Make URI attribute required. Working Draft 3. Page 22, Section
7.2, lines 662, indicates that SecurityTokenReference/Reference/@URI is an
optional attribute. However, the corresponding XML Schema for WS-Security
core specification does not explicitly specify the the attribute "URI" of
the ReferenceType complex type as an optional attribute by use of
"use=optional". I suggest that the URI attribute be required rather than
be optional as stated on line 662.

http://lists.oasis-open.org/archives/wss/200301/msg00073.html

Closed

49
Technical
Closed
Working Draft 3. Page 26, Section 8.4, lines 852-856, indicates a
specifialized type of <ds:KeyInfo> element that although is
compatible with Section 7.1, I am concerned that the core specification is
silent on the subject of acceptability of processing a signature element
that uses an in-line X.509 data (representing, e.g., a signing
certificate). What processing behaiour is expected from WS-Security
compliant system that may receive a SOAP message that contains a signature
element in its SOAP security header, i.e., <wsse:security>, that has
a <ds:KeyInfo> element that does not contain
<wsse:SecurityTokenReference> element rather contains an in-line
X509 data pertaining to the signing cert? I think the specification needs
to clearl state that all <ds:KeyInfo> instances that contain in-line
cert data are also acceptable in addition to
<SecurityTokenReference> element option if indeed we are allowing
such in-line X509 cert data type of KeyInfo element be part of signature
elements. The motivation of using SecurityTokenReference is mostly in the
use case where the same signing certificate, for example, may be used to
generate multiple signature elements (i.e., when same signing cert is used
for signing multiple SOAP message parts) within a <wsse:Security>
header. Having specific wordings of minimum requirements of what a
SOAP/WS-Security sending and receiving application must support w.r.t.
KeyInfo elements will help in security interoperability tests.

http://lists.oasis-open.org/archives/wss/200301/msg00073.html

Closed

50
Technical
Closed
Sections 7.1 (beginning at line 617 of Draft 3 of the core) through
7.3 define the Security Token Reference Element, Direct References and Key
Identifiers. I find the use of these varying forms of references
confusing. Perhaps Direct References and Key Identifiers are the 2 forms
of STRs, but it looks like there is also a n elemental form of STR that is
neither a direct reference or a key identifier.

http://lists.oasis-open.org/archives/wss/200301/msg00073.html

Closed

51
Technical
Closed
The example beginning at line 637, seems to contain a "direct
reference" (in the section on STRs), which makes thedistinction between
STR's and direct references difficult (for me) to understand.
http://lists.oasis-open.org/archives/wss/200211/msg00057.html

Closed

52
Technical
Closed
The example in section 3.4 (line 278) seems to have been set up to do
a reference bywsu:id attribute value, although the reference is done by
URI where the value of theURI is the attribute value. Is this the prefered
use model? or would we expect a simpleSTR with a wsu:id value as apposed
to a Direct reference/URI to be used? The description of key identifiers
seems to imply that Direct references are theprefered form of reference,
and where they cannot be used a key identifier isrecommended.

http://lists.oasis-open.org/archives/wss/200301/msg00073.html

Closed

53
Technical
Closed
Section 6.1 Usernames and Passwords, beginning at line 422,
defines the use of the <wsse:UsernameToken> element "as a way of
providing a username and optional password information". The definition of
this tokenmakes no mention of its potential value in defining the key to
supportthe signing or encryption of the attached SOAP message. I
realize that the
core document is intended to serve as a framework, but
it seems less thanobvious from the description that these tokens could be
used to identifya signing (or encryption key); which perhaps is the most
significant usecase that features such tokens.

The example in
section 3.4 beginning at line 248, seems to depict the useof
such tokens (as revealed by lines 299-300), as a means to carrya password
derived signing key. However, the importance of this example,warrants
further discussion in section 6.1.

http://lists.oasis-open.org/archives/wss/200301/msg00073.html

Closed

54
Technical
Closed
i) Lines 180 to 184: It is not clear to me whether this definition is
meant to describe a case of delegation where the client and sender are two
different entities or whether the sender is the channel acting on behalf
or a client. From the definition on lines 217 to 223 it appears that
delegation is not intended. Either way I believe this paragraph
should be clarified.

ii) Line 294: Should read Lines (005) to (009)
.

iii) Line 461: I believe that this line should read - "This
required element specifies the username of the authenticated party or the
party to be authenticated" NOT "of the authenticating party."
A clarifying question - am I correct in believing that this specification
does not intend to prohibit the receiving party from using the username
and password to authenticate the client?

iv) Lines 534 & 535: I
believe that these lines should read " ... binary or XML tokens ..", not
just "binary tokens"

v) Lines 575 to 588: Are these lines needed
since we RECOMMEND that Exclusive Canonicalization be used?

vi)
Section 6.3.2: We say in the WSS-SAML specification to use the
assertion id to reference SAML tokens, not to use the wsu:Id and license
id for XrML? This section should state this and shouldn't
unequivocally use "SHOULD" for the wsu:id attribute.

vii) Section
7.1 & 7.2: These sections also don't mention assertion id's for SAML
and license id's for XrML.

viii) Section 7.4: This section
only discusses BinarySecurityTokens. SAML also has a KeyInfo
token.
http://lists.oasis-open.org/archives/wss/200211/msg00184.html

i) to be corrected in drafts - pending.

ii) corrected in draft 4 of core specs - pending.

iii) need to correct draft - pending

iv) closed.

v) closed.

vii) closed.

viii) closed.

Closed

55
Technical
Closed
Is it really appropriate to endorse a claim via encryption? Perhaps
line 209 in 3.1
should be changed to read: "that is digitally signed by
the authority."

Editorial comment - the word "unendorse" can be
misinterpreted as some sort of revocation.
I'd argue, remove it from
line 208 ("A claim can be endorsed by a trusted authority.") and
then
begin line 213 with "A claim may be trusted without explicit endorsement
if there is ..."

Editorial - line 362 in 4.2, spell out
"Post-Schema Validation InfoSet". I guess this last paragraph says that
for non-schema aware processors, support for wsu:Id is optional but
recommended? Wouldn't it be better to require support regardless of
implementation?

http://lists.oasis-open.org/archives/wss/200301/msg00000.html

Closed

56
Technical
Closed
General issue with the use of the "utility" namespace for defining
elements and attributes used in wsse. It has not been explicitly stated
anywhere that I am aware of that the WS-Security TC is responsible for
defining this namespace and its associated schema. WS-Security cannot just
presume the existence of the utility namespace schema. ... If there
is an expectation that "utility" is to be a truly general Web Services
Utility namespace, then it may need to be defined by another TC with input
from other Web Services-oriented bodies. But then, again, WSS won't be
able to presume its existence at this time.

http://lists.oasis-open.org/archives/wss/200301/msg00073.html

Closed

57
Technical
Closed
[Section 4.2 and elsewhere] I do not see any value in using "wsu:Id"
when the base XML schema ID Type is available. This is especially true
since "wsu:Id" is simply defined in utility as just being of type
"xsd:ID". I believe it can only lead to confusion (and minor
additional processing overhead). I recommend removing the use of wsu:Id in
vavor of the base xsd:ID.

Related to 56.

http://lists.oasis-open.org/archives/wss/200211/msg00036.html

Closed

58
Technical
Closed
Various editorial comments

http://lists.oasis-open.org/archives/wss/200211/msg00036.html

Closed

59
Technical
Closed
Various editorial comments on XrML binding

Thomas sent mail closing this.

http://lists.oasis-open.org/archives/wss/200302/msg00019.html

Closed

60
Technical
Closed
Proposal for processing rules. It seems that for certain
bindings of WSS (SAML and XrML in particular) there may be a more
straight-forward way of describing processing rules. Currently, the
bindings for these have processing rules described under
"proof-of-possession" (in other words, you start with the token and then
try to figure out if there is proof of possession, without even knowing if
you need to do that for the purposes of that message). Recall that SAML
and XrML express, among other things, things like "A can do B upon C." A
statement such as "A can do B upon C" doesn't have any inherent processing
rules that need to be associated to it necessarily. A better way might be
to look at the message. For instance, if the message is encrypted, we only
need an identification of the key that can decrypt it, not a statement
like "A can do B upon C." If the message is signed using a key (say k), we
need to validate the signature (say it succeeds), check the semantics of
the message (say that it is that Alice is requesting two tickets (to see a
movie)), check that the request is fresh (say that it is), check that
Alice is authenticated to k (say that she is), check that "Alice can
request upon tickets" (say that she can), and, finally, process the
request and generate the response. (Also, as Phill pointed out in his
recent e-mail, we ought to also indicate where the callers should put --
and the receivers expect to find -- the tokens for each of these steps in
order to avoid the cost of figuring out the chains on the server side.) In
this way, it is clear what the intent and processing rules of the token
are, once we establish that there is first some processing to determine
what it is we are trying to prove with the tokens based on the message
coming in. I think this is clearer rather than just looking at the tokens
and explaining some of the things we can prove with them.

http://lists.oasis-open.org/archives/wss/200301/msg00073.html

Closed

61
Technical
Closed

Proposed change in wording to address lines [813]-[820] in merged draft
8, 12 Dec 2002.

"An XML signature may also be used to prove that the claims in a token
apply to the signer. Proving possession of a key associated with a token
key claim supports applying the other token claims with the signer. The
relying party acceptance of the claims may depend on confidence in the
token integrity, such as validation of an authority signature on the
token. Multiple tokens may have a key claim for a signature and may be
referenced from the signature using a SecurityTokenReference. A key claim
can be an X.509 Certificate token, or a Kerberos service ticket token to
give two examples."

Frederick: Wording on doc is fine: http://lists.oasis-open.org/archives/wss/200302/msg00066.html

http://lists.oasis-open.org/archives/wss/200302/msg00017.html

Closed

62
Technical
Pending
Versioning Mechanisms.

http://lists.oasis-open.org/archives/wss/200306/msg00025.html

The TC has to decide whether to address the versioning
issue. If it is decided to address this issue, then put a concrete proposal on the mailing list.

Anyone interested in looking at what other groups have invented contact John or Hal - Hal, Phil, John to participate so far.
This group to report back with a proposal.

Jerry will make a propsal.

Resolution: Adopt a versioning scheme that has
version information in the URIs. For more information see thread: http://lists.oasis-open.org/archives/wss/200306/msg00036.html

Editors to add text for QName versioning solution.

Editors

63
Technical
Closed
XML Token Wrapper

http://lists.oasis-open.org/archives/wss/200302/msg00017.html

Closed

64
Procedural
Closed
Add glossary
http://lists.oasis-open.org/archives/wss/200301/msg00073.html.
Terminology section is like a glossary. No additional action required. http://lists.oasis-open.org/archives/wss/200304/msg00049.html

Editors

65
Technical
Closed
Adding support for biometric authentication to the UserName security
token.
http://lists.oasis-open.org/archives/wss/200301/msg00073.html.
Closed, pending changes from Phil. http://lists.oasis-open.org/archives/wss/200304/msg00048.html

Phil Griffin

66
Technical
Closed
Open transform
http://lists.oasis-open.org/archives/wss/200302/msg00017.html

Add subsection to section 7 to define the case where the a security
token can be a subelement of a STR. Related note: http://lists.oasis-open.org/archives/wss/200303/msg00002.html

67
Technical
Pending
Resolve usage labels.

http://lists.oasis-open.org/archives/wss/200306/msg00025.html

Hal to begin editing a Usage Label document, which may transition into
a profile.
TC

68
Technical
Closed
Review username password hash encryption issues
http://lists.oasis-open.org/archives/wss/200302/msg00017.html
Chris:
no uniform way to express which shared secret to use, but could define
QName values for this.
TC

69
Technical
Pending
The specification is vague on the topic of Key Identifiers.

http://lists.oasis-open.org/archives/wss/200306/msg00025.html

Editors have chatted, and will be reflected in next round of profile
docs
Editors

70
Technical
Pending
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"...

http://lists.oasis-open.org/archives/wss/200306/msg00025.html

resolution: mustUnderstand on Security header simply
means you are aware of the WS-Sec spec, and there are no implied semantics.

Editors to reflect mustUnderstand resolution in docs
Editors

71
Technical
Closed
Inconsistent token pre-pending rules

http://lists.oasis-open.org/archives/wss/200306/msg00025.html

Continue to discuss on list. Related to #84. Please look at
issue #84 for resolution.
Closed.

72
Technical
Pending
Awkward status of message timestamps in WSS core. Two issues: Timestamp
trace and Expires.

http://lists.oasis-open.org/archives/wss/200306/msg00025.html

Continue to discuss on list. If no decision, discuss at F2F.

Resolution: Timestamp trace -> remove from the core specification and put
into another doc.

Resolution: Expires ->

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
Editors

73
Technical
Closed
What tokens are allowed within TokenReference? Add an embedded
reference, but this isn't well defined.

http://lists.oasis-open.org/archives/wss/200306/msg00025.html
Editors have not yet made a
proposal. Chris will contact the editors to pull this together.
Closed

74
Technical
Pending
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 Username token? 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?

http://lists.oasis-open.org/archives/wss/200306/msg00025.html

The Interop issues, which are part of this issue, have been closed. Open: text for Security Considerations needs to be done. Hal has sent proposed
text. Please review.
Resolution: Put in
password token profile, internal reference will be fixed in Hal's text.
Due phoncon next week.

http://lists.oasis-open.org/archives/wss/200306/msg00005.html
Hal

75
Technical
Closed
Denial of service attacks and error reporting.

http://lists.oasis-open.org/archives/wss/200306/msg00025.html

Use standard SOAP language. Must generate a fault, however, generating a fault does not mean sending a fault. Review editorial changes.
Closed

76
Technical
Pending
X.509 profile issue 1: Is it desirable to use same element as
reference and referrent?

http://lists.oasis-open.org/archives/wss/200306/msg00025.html

To wait for Tim to join the discussion.
Tim Moses

77
Technical
Pending
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

http://lists.oasis-open.org/archives/wss/200306/msg00025.html

To wait for Tim to join the discussion.
Tim Moses

78
Technical
Pending
X.509 profile issue 3: Under what circumstances would one need to
reference an X.509 certificate containing an encryption key?
http://lists.oasis-open.org/archives/wss/200305/msg00026.html

Tim Moses will have a chance review in June.

Tim Moses

79
Technical
Pending
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.
http://lists.oasis-open.org/archives/wss/200305/msg00026.html

Tim Moses will have a chance review in June.

Tim Moses

80
Technical
Pending
X.509 profile issue 5: Suggest MUST use common error codes
http://lists.oasis-open.org/archives/wss/200303/msg00036.html

Tim Moses will have a chance review in June.

Tim Moses

81
Technical
Closed
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?
http://lists.oasis-open.org/archives/wss/200305/msg00026.html

Will fix in schema. Fixed in schema?

Closed

82
Procedural
Open
Scrub specs and update links to other specifications
Kelvin Lawrence:
http://lists.oasis-open.org/archives/wss/200303/msg00056.html

83
Technical
Close
<xenc:EncryptedData> element should precede the
<xenc:EncryptedKey/> element in the
interop scenario.
http://lists.oasis-open.org/archives/wss/200305/msg00026.html

Closed as there were no comments.

Closed

84
Technical
Open
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 has written an email:

http://www.oasis-open.org/archives/wss/200305/msg00022.html

Needs to be reviewed. Hal proposed text for issue: http://lists.oasis-open.org/archives/wss/200306/msg00003.html
. Tony to propose edits and/or provide history.

85
Procedural
Closed.
Post a draft of F2F questions. Paul Cotton has posted draft.
http://lists.oasis-open.org/archives/wss/200304/msg00009.html

Closed

86
Technical
Open
Non-repudiation proposal to be included as part of WS-Security
http://lists.oasis-open.org/archives/wss/200304/msg00016.html

87
Technical
Closed
Add a profile for XKMS to WS-Security.
Currently no owner for this.
Closed

88
Procedural
Closed
Wrap up and release dates for version 1.0
http://lists.oasis-open.org/archives/wss/200305/msg00000.html
Kelvin to meet with Chris and draft a proposal. Others can indicate
critical dates. Duplicate of Issue #11.
Closed

89
Technical
Closed
Proposal for making BinaryToken and XML Token to be abstract
types.
http://lists.oasis-open.org/archives/wss/200305/msg00046.html
:
Chris to post a mail why it would not work in practice.

Closed

90
Technical
Pending
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.
http://lists.oasis-open.org/archives/wss/200305/msg00028.html

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.
Editors

91
Technical
Closed
Interop spec mustUnderstand uses "true" where as SOAP mustUnderstand
attribute is either "1" or "0". The interop schema doesn't validate
against SOAP schema.
http://lists.oasis-open.org/archives/wss/200305/msg00025.html
. Fixed in draft 3. Propose we close.
Closed

92
Technical
Closed
Should we support "multiple recipient" case for encryption? A possible
use of multiple EncryptedKey elements in different security headers is to
enable multiple roles, possessing distinct private asymmetric keys, to get
access to the same data, encrypted with the same symmetric key. In this
scenario, the intermediary, should perform the decryptions indicated in
the Security header labeled with its role, passing the result to its local
application. The problem is there is no way to distinguish this case
versus Super encryption case where multiple encryption headers might also
exist.
http://lists.oasis-open.org/archives/wss/200305/msg00022.html
not a separate issue, part of the order of decryption issue. No one
commented.

Resolution: if you want support multiple recipient case for encryption, you're on
your own
Closed

93
Technical
Closed
Error in WSS interop example #2.
http://lists.oasis-open.org/archives/wss/200305/msg00005.html

Fixed in latest draft. Closed.

Closed

94
Technical
Pending
Embedded missing from STR preferred. Embedded References were
not added to the list in lines 642-648
http://lists.oasis-open.org/archives/wss/200306/msg00012.html.
Editors to update.
Editors

95
Technical
Pending
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.

http://lists.oasis-open.org/archives/wss/200306/msg00027.html

Editors to clarify utilization.
Merlin Hughes

96
Technical
Pending
Various edits.

Some small issues/edits from reading half of the doc.

i) Line 186:

The xsd: prefix is also used in the document.

ii) Line 490 and globally:

"A string label" is, to me, a slightly vague definition for ID attributes; would "An ID label" or some such be better?

iii) Line 544:

... The ValueType attribute s/allows/is/ a qualified name ...

iv) Line 547 and elsewhere:

If EncodingType is unspecified, I presume that means base 64; should we say this explicitly? We say 'default'

in some places, but the meaning of that is not altogether clear to me; I could misinterpret as schema default.

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?

vi) Line 600:

... If a s/SecurityTokenRefeference/SecurityTokenReference is/ used outside ...

vii) Line 601:

... reference s/are// MUST be ...

viii) Line 615:

Does wsse:Usage deserve to be a global attribute? It only appears to be used once.

ix) Lines 703, 708 and elsewhere:

703: The ValueType attribute is used to optionally indicate

708: The optional EncodingType attribute is used to indicate

If we don't intend a different meaning, I'd suggest standardizing on the form of line 708.

x) Line 726:

... is used to s/embedded/embed/ a token ...

xi) Lines 730,733:

s/KeyIdentifier/Embedded/

xii) Line 765:

... Additionally, s/defined for// e-mail addresses ...

xiii) Lines 768-777:

Is the font off?

http://lists.oasis-open.org/archives/wss/200306/msg00040.html

editorial update approved for v.

No change required for viii.
Merlin Hughes

97
Technical
Pending
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'?

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?
http://lists.oasis-open.org/archives/wss/200306/msg00041.html

i) Resolution: Whitespace should be preserved.

ii) Update document to define an order and schema should match the
document.

Editors

98
Technical
Pending
Because Interop Scenario #3 uses two key pairs instead of four key pairs, it avoids a security threat in a way that was not apparent to me until a recent internal review.
The basic issue is: when the responder encrypts the response, how does it determine that the public key it uses is that of the proper party and not some attacker.

Suppose each party has two key pairs, one for signatures and one for encryption. Let us assume the requester provides a certificate containing the public key to be used for
encrypting the response. Checking to see if the certificate is valid is insufficient (and probably unnecessary). That would not prevent an attacker from substituting his or
her own (perfectly

valid) certificate.

Interop scenario #3 does not have this problem, because the same key is used to sign the request, thus demonstrating that the requester knows the corresponding private key.

There is more than one way to solve this problem. One possible way would be to require that the SubjectName in the encryption certificate is the same as the one in the
signature certificate. I do not think this is a good approach. For one thing there are a least a dozen reasons that even if both certs were issued to the same system entity
(person), the SubjectNames won't match. Second it doesn't support the case where the requester and recipient are distinct.

A better solution would be to require that the encryption certificate (or at least the public key) fall under the signature of the request. This proves that the key came from
the requester, which is what we are really trying to determine. This might be a good time to use /Usage={receiver}.
http://lists.oasis-open.org/archives/wss/200306/msg00044.html

Hal Lockhart

99
Technical
Open
KeyIdentifier ValueType

The core spec currently takes the position that the ValueType which
optionally appears in the KeyIdentifier describes the thing referred to,
e.g. an X.509 cert, rather than the type of the KeyIdentifier itself. In
fact the spec says even if it does appear, it is only a hint. This doesn't
seem particularly useful...

Hal:

http://lists.oasis-open.org/archives/wss/200306/msg00076.html
TC

100
Technical
Open
Issue: Replay attacks and timestamp. Investigate if there are additional
implications of using time stamps and other replay detection mechanisms
across multiple SOAP roles.
Martijn:

http://lists.oasis-open.org/archives/wss/200306/msg00078.html

Status: Martijn has started a mil thread as he was supposed to.
TC

101
Technical
Open
Key Identifiers Should Not Be Used for Signatures. Using a key
identifier to indicate the key to be used for signature validation creates
an exposure to a certificate substitution since it is possible for several
certificates to exist which refer to the same key pair.
Hal:

http://lists.oasis-open.org/archives/wss/200306/msg00085.html
TC

102
Technical
Open
Remove 7.7 Token Reference Lookup Processing Order. Section 7.7 defines
a preferred order for processing the contents of a KeyInfo element, to
'resolve possible ambiguities'. Propose removing this section as it provides
no additional benefit.
Merlin:
http://lists.oasis-open.org/archives/wss/200306/msg00087.html
TC

103
Editorial
Open
ValueType attribute: docs should state "ValueType attribute is
RECOMMENDED for BinarySecurityToken and RECOMMENDED for Reference with
non-local URI". Rework the example in 7.2.
Merlin:
http://lists.oasis-open.org/archives/wss/200306/msg00088.html
TC

104
Technical
Open
Signature Transform: The signature transform in section 8.3 seems
underspecified. In particular, 'echo' isn't particularly meaningful when
transforming node sets
Merlin:

http://lists.oasis-open.org/archives/wss/200306/msg00089.html
TC

105
Technical
Open
Signature over EncryptedXXX: Signature over CipherData/CipherReference/@URI
to reference the externally-located ciphertext doesn't provide assurances
over encrypted data.

Merlin:
http://lists.oasis-open.org/archives/wss/200306/msg00090.html
TC

Notes on Issues

There are currently no additional notes on issues. In most cases the
history of an issue can be easily determined by examining the linked meeting
minutes or discussion message and/or previous versions of the issues
list.

View original preserved HTML → View on OASIS Connected Community →

← Prev in month ← Prev in thread

Next in thread → Next in month →