OASIS Web Services Security Issues List

338

Technical

Open

Hal: Proposed new work - WSS Templates

http://lists.oasis-open.org/archives/wss/200410/msg00060.html

TC

364

Technical

Pending

SWA profile: Can XML attachments be XML canonicalized and used in conjunction with SwA profile?

http://lists.oasis-open.org/archives/wss/200502/msg00054.html
Resolution: This is a substantive change -  Hal wants opinions on what is the processing model.  Frederic will take another pass.

Status: Reopened based on Brian's feedback
Action: Frederick to send proposal to list

Status: Frederick sent proposal to list.

Frederick

370

Technical

Pending

SWA profile: Add processing rules/guidance for SOAP and MIME intermediaries

http://lists.oasis-open.org/archives/wss/200502/msg00054.html
Status: Frederick to come up with proposal
Action: Frederick to make a proposal for discussion.

Status: Frederick sent proposal to list.

Frederick

378

Process

Open

Deprecating or otherwise superceding documents

Status: Chairs to track status of OASIS process for deprecating or otherwise marking a document as superceded.
Action: Kelvin and Paul Cotton to follow up.

Chairs

384

Technical

Pending

Kerberos TP: Channel Binding

Section 4, last paragraph (lines 214-215) says "It should be noted that transport-level security MAY

be used to protect the message and the security token."  I think this needs some clarification.

Why should the AP-REQ message require additional protection from lower layers?  From what

sorts of attacks?  What if no such protection is available?  Shouldn't the session key from the AP-REQ

be used to provide integrity protection to the S11 header?

Or is this text indicating, obliquely I suppose, that it is possible to use this profile for authentication

but rely on lower network layers for session protection?

If the latter, note that there is a channel binding problem in that more normative text is needed to

ensure that the end-points of the lower-layer channel and the application layer are effectively the

same, else MITM attacks may be possible.  [Note: I assume that the "transport-level security" is

secure against MITM attacks, but MITM attacks may be feasible nonetheless by misdirecting the

system/application so that one layer or the other it is speaking to an otherwise properly authenticated

attacked.]  This can be avoided with some additional requirements.
http://lists.oasis-open.org/archives/wss-comment/200504/msg00001.html
clarification why should AP require additional protection from lower layers.  pending additional detail needed - action by editors
Status: Tony has action item to roll the changes into Kerberos TP document and publish.

Anthony Nadlin

385

Editorial

Pending Review

Kerberos TP: References to obsolete documents

RFC1510 will be obsoleted as soon as the RFC-Editor publishes

   draft-ietf-krb-wg-kerberos-clarifications-07.txt

as an RFC.  That Internet-Draft has already been approved as a Proposed Standard by the IESG.

The WSS Kerberos Token Profile should be reviewed with kerberos-clarifications in mind

and, if it should not progress from Draft status prior to the publication of

kerberos-clarifications as an RFC, then it should be changed to list the new RFC as a

normative reference for the Kerberos Network Authentication Service (V5).

http://lists.oasis-open.org/archives/wss-comment/200504/msg00001.html
pending 1510 refresh

TC

As for mutual authentication, if the "mechanisms described in

WS-Security" provide it, then that should be explained in the profile, just as with replay protection.

http://lists.oasis-open.org/archives/wss-comment/200504/msg00001.html

WSS ID

Type

Status

Issue

Resolution

Owner(s)

3

Technical 

Closed, Duplicate of 67?

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
Resolution: Follow link above for resolution.

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
Resolution: Follow link above for resolution.

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
Resolution: Follow link above for resolution

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
Resolution: Follow link above for resolution. 

Closed

30

Technical

Closed

How should XML be explained.

http://lists.oasis-open.org/archives/wss/200306/msg00025.html.
Resolution: Chris has sent mail to Editors for what they are supposed to do!

Closed

35

Technical

Closed, Related to 290?

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
Resolution: Follow link above for resolution.

Closed

44

Technical

Closed

SAML Cannonicalization

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

Closed

53

Technical

Closed for v1

Open (post-v1)

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 token makes no mention of its potential value in defining the key to support the 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 than obvious from the description that these tokens could be used to identify a signing (or encryption key); which perhaps is the most significant use case that features such tokens.

The example in section 3.4  beginning at line 248,  seems to depict the use of such tokens (as revealed by lines 299-300), as a means to carry a 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
Resolution: Username token profile has been separated from the core specification. The primary issue of key material for username token will be handled in this document. Follow link above for additional information.
Note: Issue placed here to relate to potential re-opening of this issue.
Resolution: closed by 282. 

Closed 

59

Technical

Closed

Various editorial comments on XrML binding

http://lists.oasis-open.org/archives/wss/200302/msg00019.html
Resolution: Thomas sent mail closing this.

Closed

63

Technical

Closed

XML Token Wrapper

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

Closed

67

Technical

Closed

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.
http://www.oasis-open.org/archives/wss/200408/msg00064.html
Hal has sent out a proposal.

Closed

84

Technical

Close

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.
Action: Editors to review and potentially incorporate the proposed text
Status: Hal and Tony to follow up.
Status: Discussion on the email list on the necessity for decryption transform being always present vs. where we don't: http://lists.oasis-open.org/archives/wss/200411/msg00037.html
Status: Action on Mike to respond to Hal's email before next call.
http://lists.oasis-open.org/archives/wss/200411/msg00053.html
Status: Mike didn't have time to respond. Leave as pending. http://lists.oasis-open.org/archives/wss/200412/msg00038.html
Status from 12/14/04: Mike to follow up with new proposal. Editors to remove transform stuff.
Resolution: Remove the transform section. This was done. The latest document has the changes. Closed.

Status: This was not resolved completely. Latest draft (
http://www.oasis-open.org/apps/org/workgroup/wss/download.php/12305/oasis-2004xx-wss-soap-message-security-1.1-changes.pdf) contains decryption transform section.

Close

86

Technical

Closed

Non-repudiation proposal to be included as part of WS-Security.

http://lists.oasis-open.org/archives/wss/200304/msg00016.html.

Resolution: Defer till after v1. Resolution date: Jun-17-03.
Status: Related to 319.
Propose that we close the issue. If we don't find interest by Tuesday Oct 19 con call, we will close.
Resolution: No action. Rolled into 319.

Closed

87

Technical

Closed

Add a profile for XKMS to WS-Security.

Currently no owner for this.

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

103

Editorial

Closed

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
Resolution: Change text REQUIRED on BST and RECOMMENDED on Reference.
Ron: Revisited? Ron to figure out the status of this issue
Resolution: Add to Errata/1.1 "ValueType is recommended on all non-local URIs (direct references via shorthand xpointer)."
ACTION[Editors]: Update Errata and 1.1 per 103 resolution

Closed

127

Technical

Closed

Peter Dapkus: Spec should address the issue of non-visibly used namespaces

http://lists.oasis-open.org/archives/wss/200307/msg00070.html

Resolution: Consensus on two points:
 - remove recommendation for exclusive c14n
 - add brief description under interop considerations
Hal to propose wording for issue 127.
Resolution: Doesn't block ship
Hal to provide non normative text.

http://lists.oasis-open.org/archives/wss/200311/msg00058.html

Closed

165

Technical

Closed

Passing binary data in SAML Assertion Token

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

Closed

196

Editorial

Closed
 

WSS: Soap message security: General: Also, why use qualified names instead of URIs for identifying encoding types. Ron: editors
chose to use URIs fragments based on ambiguously specified roots

W3C XMLP WG Feedback  http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html

TC to review http://lists.oasis-open.org/archives/wss/200311/msg00016.html Too late to accommodate with changes.

In the last two calls we have had unanimous agreement to not address this in V1 (if at all -- needs further research)

TC voted to switch to URIs.
Resolution: Fixed. This was a left over issue.

Closed

242

Editorial

Closed

Update SAML profile to use new URLs

Editors to make this change

Closed

243

Editorial

Closed

Update XrML profile to use new URLs

Editors to make this change

Closed

244

Editorial

Closed

Update Kerberos profile to use new URLs

Editors to make this change

Closed

245

Editorial

Closed

Rename SAML profile document

Editors to make this change

Closed

246

Editorial

Closed

Rename XrML profile document

Editors to make this change

Closed

247

Editorial

Closed

Rename Kerberos profile document

Editors to make this change

Closed

249

Technical

Closed

the saml token profile depends on non-global attributes in keyidentifier/wsse schema does not support keyIdentifier element extensibility -

 http://lists.oasis-open.org/archives/wss/200401/msg00120.html

Resolution:
non global attributes does not support element extensibility....
SAML has a work around
should schema support mixed content....

Closed

250

Technical

Closed

Should ValueType attribute of STR reference element be moved to top level STR definition? - post v1 review period

 http://lists.oasis-open.org/archives/wss/200401/msg00121.html
Resolution: Postponed to v1.1. http://lists.oasis-open.org/archives/wss/200402/msg00062.html
Action: Ron to generate proposal for STR ValueType.
Status: Ron sent email. http://www.oasis-open.org/archives/wss/200411/msg00005.html
Action: TC to review before next conf call.
Action: Ron and Thomas each forward proposal to TC http://lists.oasis-open.org/archives/wss/200412/msg00003.html
Status: Corinna, Ron and/or other champions of the issue to
garner support. http://lists.oasis-open.org/archives/wss/200412/msg00057.html has more information
Action: Ron to produce updated proposal. Based on above minutes.
http://lists.oasis-open.org/archives/wss/200501/msg00019.html
Status: Ron sent a proposal. http://lists.oasis-open.org/archives/wss/200501/msg00020.html
Action: Ron to send proposal to the list
From meeting notes:There ensued a long discussion of issue 250. The final result was that there be a lead agenda item at the next telecom to vote on accepting either Ron's proposal or Thomas's proposal. However, if Ron and Thomas can come up with a common, combined proposal before the next telecom; that will be accepted.
Status: Motion passed. Editors to make changes. Leave issue 250 (open/pending/Pending Review?) to track changes.

Closed

251

Technical

Closed

keyIdentifier valuetypes of Username and X509 profiles are defined relative to wsse schema - post v1 review period

 http://lists.oasis-open.org/archives/wss/200401/msg00122.html
Resolution: http://lists.oasis-open.org/archives/wss/200402/msg00062.html

Closed

252

Editorial

Closed

Trivial editorial bug on SOAP Message Security - post v1 review period

http://lists.oasis-open.org/archives/wss/200401/msg00117.html

Closed

253

Editorial

Closed

minor editorial comment on SOAP Message Security - post v1 review period

http://lists.oasis-open.org/archives/wss/200401/msg00116.html

Closed

254

Editorial

Closed

comments on core spec-  Line 853 (Table) Soap message security 011504 - merged:
SOAP Message Normalization may be used as a"Transform" algorithm,
not a "Canonicalization" algorithm - post v1 review period

http://lists.oasis-open.org/archives/wss/200401/msg00104.html Resolution: Move to Errata
Resolution: Addressed in Errata.

Closed

255

Editorial

Closed

Editorial comments on core spec - post v1 review period

http://lists.oasis-open.org/archives/wss/200401/msg00101.html

Closed

256

Technical

Closed

STR attributes are not protected.

http://lists.oasis-open.org/archives/wss/200402/msg00042.html
Resolution: Clarifications added to Errata.

Closed

257

Technical

Postponed Duplicate

STR attrubutes are  not protected

http://lists.oasis-open.org/archives/wss/200402/msg00042.html

Closed

259

Editorial

Closed

Editorial comments on Username Token profile - post v1 review period.

http://lists.oasis-open.org/archives/wss/200401/msg00113.html
Resolution: Clarifications added to Errata

Closed

260

Editorial

Closed

Editorial comments on X.509 Token profile - post v1 review period.

http://lists.oasis-open.org/archives/wss/200401/msg00114.html
Resolution: Clarifications added to Errata

Closed

261

Editorial

Closed

How do we handle the sender voucher scenario for SAML

http://lists.oasis-open.org/archives/wss/200402/msg00034.html
Resolution: Will leave the part of the SAML token spec. relating to sender-vouches unchanged. There will be no key in sender-vouches, subject confirmation.
http://lists.oasis-open.org/archives/wss/200402/msg00062.html

Closed

262

Editorial

Closed

Comments on sender voucher signed section in SAML interop draft.

http://lists.oasis-open.org/archives/wss/200402/msg00032.html

Resolution: document ok until SAML discussions require change. http://lists.oasis-open.org/archives/wss/200402/msg00042.html

Closed

263

Technical

Closed

Open enumerations - post v1 review period.

http://lists.oasis-open.org/archives/wss/200402/msg00011.html
Action: Gudge to revive proposal for Open enumerations
Status: Gudge has sent an email. Discussion about whether we should do this or not.
Resolution: No change. TC decided that it was not worth the effort clean up.

Closed

264

Editorial

Closed

Post review period comments: Errors in WSS core and username/x.509 profile examples.

http://lists.oasis-open.org/archives/wss/200403/msg00034.html

Resolution: Editors placed text in Errata

Closed

265

Technical

Closed

Encryption of wsse: security header

http://lists.oasis-open.org/archives/wss/200403/msg00011.html
Resolution: Covered by 317

Closed

266

Technical

Closed

Manesh: Are AttributeStatements the only statements pertinent to the SAML TP?
Are AuthenticationStatements and AuthorizationDecisionStatements useful in the WSS scenarios?

http://lists.oasis-open.org/archives/wss/200403/msg00074.html

Closed

267

Editorial

Closed

Typos in Sender-Vouches and Holder-of-Key examples listed in Saml interop document.

http://lists.oasis-open.org/archives/wss/200404/msg00007.html

Closed

268

Technical

Closed

How do we secure SOAP attachments?

http://lists.oasis-open.org/archives/wss/200404/msg00004.html
Resolution: Proposals sent to mailing list

Closed

269

Editorial

Closed

Need clarification on the URIs for type attributes.

http://lists.oasis-open.org/archives/wss/200404/msg00034.html

Closed

270

Process

Closed

Comments from Wells Fargo: support from SAML 1.1 token profile

http://lists.oasis-open.org/archives/wss/200404/msg00054.html

Closed

271

Technical

Closed

Comments from Wells Fargo: Username token does not provide a mechanism for indicating its type or domain

http://lists.oasis-open.org/archives/wss/200404/msg00054.html
Resolution: Not fixed. Username can contain other fields if necessary.

Closed

272

Editorial

Closed

SAML interop scenario doc should use 1.1 for version.

http://lists.oasis-open.org/archives/wss/200404/msg00061.html

Closed

273

Technical

Closed

Should we have conditions in SAML tokens? Should their presence indicate that they should always be processed?

http://lists.oasis-open.org/archives/wss/200404/msg00061.html
Resolution: Condition processing is to be same as in SAML Core.

Closed

274

Technical

Closed

Format attribute vs NameQualifier attribute of NameIdentifier

http://lists.oasis-open.org/archives/wss/200404/msg00061.html

Closed

275

Editorial

Closed

SAML token profile, Interop - dateTime formats - need clarification

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

Closed

276

Editorial

Closed

Problem with document URLs

http://lists.oasis-open.org/archives/wss/200404/msg00082.html

Closed

277

Technical

Closed

Kerberos profile: Ticket granting ticket should be removed from Kerberos profile

http://lists.oasis-open.org/archives/wss/200404/msg00093.html
Action Item: Phil will add text to propose a resolution to this question
http://lists.oasis-open.org/archives/wss/200406/msg00028.html

Closed

278

Technical

Closed

Kerberos profile: Deriving Session Keys from master secret

http://lists.oasis-open.org/archives/wss/200404/msg00094.html
Resolution: No action required

Closed

279

Technical

Closed

XrML: Multiple grants

http://lists.oasis-open.org/archives/wss/200404/msg00097.html
Resolution: there should be only one keyHolder
principal across those grants

Closed

280

Process

Closed

What if any IP issues apply for SAML interop?

http://lists.oasis-open.org/archives/wss/200405/msg00001.html
Resolution: http://lists.oasis-open.org/archives/wss/200405/msg00019.html
Action item: Rob will get Andrew to repost the issue to state this.
Resolution: Andrew Nash sent a clarifying note to the TC.

Closed

281

Editorial

Closed

X509 Token profile - sample still uses QNames. (BinarySecurityToken attributes)

http://lists.oasis-open.org/archives/wss/200405/msg00003.html
Resolution: Tony will create errata for each separate document.
Resolution: Addressed in Errata.

Closed

282

Technical

Closed

Password based key derivation - revisited

http://lists.oasis-open.org/archives/wss/200402/msg00060.html
Action item: Paul Cotton has action item to research and get back.
http://lists.oasis-open.org/archives/wss/200406/msg00026.html
Action: Tony to propose text.
Action: Additional section in UserNameToken.vNext describing the mechanism. Additional data in UserNameToken.vNext security considerations.
Action: Tony to update v.next
Status: Updated posted. http://www.oasis-open.org/apps/org/workgroup/wss/download.php/10656/oasis-2004xx-wss-username-token-profile-1.1-changes.pdf
Action: TC to review.
Resolution: Changes in update seem correct. Closed.

Closed

283

Technical

Closed

User To User Kerberos

http://lists.oasis-open.org/archives/wss/200405/msg00018.html
Action item: Hal and Phillip will research and report back on this issue.
http://lists.oasis-open.org/archives/wss/200406/msg00028.html

Closed

284

Editorial

Closed

SAML virtual interop scenario typos

http://lists.oasis-open.org/archives/wss/200405/msg00021.html
Resolution: Fixed.

Closed

285

Technical

Closed

Transforms for securing attachments

http://lists.oasis-open.org/archives/wss/200405/msg00022.html
Action Item – Jerry Schwarz, Fredrick Hirsch and Mike McIntosh to issue a proposal on these issues
http://www.oasis-open.org/apps/org/workgroup/wss/download.php/7236/wss-swa-profile-1.0-draft-04-diff.pdf
Written as interoperability scenarios. Needs more discussion.
Resolution: The proposal has made enough progress. Individual areas will be addressed as necessary.

Closed

286

Technical

Closed

The examples should be made consistent so that the assertion always has the same subject identified and issuer. Should specify how the issuer is specified

Issue raised during SAML interop

Closed

287

Technical

Closed

Need to use namespace qualified mustUnderstand for interop

Issue raised during SAML interop.

Closed

288

Technical

Closed

When using a signature to bind an on msg assertion to its soap msg, why is it necessary to use an STR to reference the assertion from signedInfo of the signature.

Issue raised during SAML interop

Closed

289

Editorial

Closed

minor typo in the interop document. Lines 705-708 should be contained within the ds:Transform.
<dsig:Transform
Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform"/>
<wsse:TransformationParameters>
<dsig:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</wsse:TransformationParameters>

should be

<dsig:Transform
Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform">
<wsse:TransformationParameters>
<dsig:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</wsse:TransformationParameters>
</dsig:Transform>
 

Issue raised during SAML interop

Closed

290

Technical

Closed

Inconsistency in the KeyIdentifier encoding type default between core and SAML specifications. Core defines default of Base64Binary while SAML spec defines default to be xsi:string.

Issue raised during SAML interop
http://lists.oasis-open.org/archives/wss/200406/msg00066.html

Resolution: Core also defines the unencoded string so the profiles will not have to redefine that themselves.  Any profile that does not have Base 64 will have to change, only one exists presently (SAML).  

Action: Ron to write up and send to list
Action: Editors to make changes as described in http://lists.oasis-open.org/archives/wss/200407/msg00077.html
Action: Editors to fold this into next document of the core.
Note: There is two versions of docs related to core: 1) errata for core 2) errata plus previously closed issues opened for review
Resolution: Fixed in errata for core.

Closed

291

Technical

Closed

Clarify that the SAML token profile only covers SAML 1.1

Issue raised during SAML interop
Resolution: Fixed in SAML 1.1

Closed

292

Technical

Duplicate

Interop scenario #3 has an enveloped signature that signs the assertion (referenced using the AssertionID) and a detached signature signing the assertion as well as the message body. One option is to sign the assertion referenced via a SecurityTokenReference. Another option is to have referenced the assertion directly using the AssertionID attribute. What is the right option?
 

Issue raised during SAML interop
Resolution: Issue 288

Closed

293

Technical

Closed

Does the x509 token profile standardize an interoperable encapsulation of  an X.509 V1 certificate in a BinarySecurityToken

http://lists.oasis-open.org/archives/wss/200405/msg00067.html
Action: Need to fold clarification into Errata:
http://lists.oasis-open.org/archives/wss/200406/msg00068.html

Closed

294

Procedural

Closed

XrML trademark issues

http://lists.oasis-open.org/archives/wss/200405/msg00068.html
Resolution: XRML changed to REL

Closed

295

Technical

Closed

Ramana Turlapati: Comments on SAML Token profile - sender vouches scenario is too complex.

http://lists.oasis-open.org/archives/wss/200406/msg00052.html
Resolution: Friendly amendment suggested and closed.

Closed

295b

Technical

Closed

Ramana Turlapati: Profile does not cover SAML "Bearer" tokens. Is this scoped for future?
 

http://lists.oasis-open.org/archives/wss/200406/msg00052.html
 

Closed

296

Technical

Closed

Anthony Nadlin: Comments on SAML Token profile and ID usage.

http://lists.oasis-open.org/archives/wss/200406/msg00058.html
Resolution: Add clarification to be added to future version. "SAML token profile mandates use of key identifier method of referencing local SAML tokens excluding use of the
direct reference method to local tokens other than wsu:Id"
Resolution: Fix was added to draft.

Closed

297

Technical

Closed

Attachment Profile Question/Comment

http://lists.oasis-open.org/archives/wss/200406/msg00067.html
Resolution: clarification was added to this issue

Closed

298

Technical

Closed
 

X509 TP: IssuerSerial - What are the advantages of IssuerSerial as opposed to using SubjectKeyInfo

http://lists.oasis-open.org/archives/wss/200406/msg00104.html
Action: Hal to create a proposal - Proposal sent: http://lists.oasis-open.org/archives/wss/200407/msg00066.html
Action: Editors to look over the
wording on token ordering in the core and make sure that it is clear
(otherwise clarify in v.next) that token profiles can define ordering
Status: Updated posted. http://www.oasis-open.org/apps/org/workgroup/wss/download.php/10649/oasis-2004xx-wss-soap-message-security-1.1-changes.pdf
Action: TC to review.

Closed

299

Editorial

Closed

Frederick Hirsch: SOAP security errata 1.0 comments

http://lists.oasis-open.org/archives/wss/200406/msg00111.html

Closed

300

Editorial

Closed

Frederick Hirsch: X.509 Token profile errata comments

http://lists.oasis-open.org/archives/wss/200406/msg00112.html

Closed

301

Editorial

Closed

Frederick Hirsch: Username Token profile errata comments

http://lists.oasis-open.org/archives/wss/200406/msg00113.html

Closed

303

Editorial

Closed

Attachment profile question: Sec 2.2.1 MIME Part CipherReference Transform line 265 says: The <xenc:CipherReference> must have a <ds:Transforms> child element,
and this element must have a <ds:Transform> child. But the example (starting line 334) is as follows: <Transforms>
  <ds:Transform ...
Shouldn't it be <ds:Transforms>? 

http://lists.oasis-open.org/archives/wss/200407/msg00007.html
Action: Editors to update
Resolution: Updated.

Closed

304

Editorial

Closed

REL Profile Lines 294-298: Use of MAY

http://lists.oasis-open.org/archives/wss/200407/msg00010.html
Resolution: No changes.

Closed

302

Editorial

Closed

Nishimura Toshihiro: A small errata for the core spec.

http://lists.oasis-open.org/archives/wss/200406/msg00117.html
Action: Tony to add to Errata

Closed

305

Technical

Closed

Kerberos profile - Exchanging raw tickets, that is without Kerberos authenticators, poses several risks. Related to Issue #283

http://lists.oasis-open.org/archives/wss/200407/msg00014.html
Action: Need a proposal on how to support user to user.
3 actions items
1. User to User is app specific  2. TGT is app specific  3. service ticket to AP_REQ
 

Closed

306

Technical

Closed

SwA Profile comments -
a. Specify MIME header canonicalization algorithm
b. Specify how to find details for any content types
c. Can we sign the Content-Transfer-Encoding header itself?

http://lists.oasis-open.org/archives/wss/200407/msg00024.html
Action: Mark pending, editors to make changes to draft.
http://lists.oasis-open.org/archives/wss/200407/msg00047.html 
Resolution: Clarified text.

Closed

307

Technical

Closed

More SwA comments -
a. Relationship to SOAP versions
b. Processing of sub document parts in an XML attachment
c. Line 108, we should define MTOM.
d. Line 133 still refers to Content-Location
e. Need statement about attachment canonicalization when it is XML.
 

http://lists.oasis-open.org/archives/wss/200407/msg00025.html
Action: Frederick - make editor pass to see  if he can resolve this.
Resolution: Editorial pass resolved the issue.

Closed

308

Technical

Closed

Hal Lockhart: License Id in REL token profile

http://lists.oasis-open.org/archives/wss/200407/msg00041.html
Resolution: no action

Closed

309

Editorial

Closed

Dana Kaufman: Example 4.4.5 seems to be missing an <xenc:EncryptionMethod> tag

http://lists.oasis-open.org/archives/wss/200407/msg00103.html
Action: SwA profile to look into this. Resolution: SwA fixed.
Action: Other profiles to look into this. Non-normative comments to be added to core.
Action: Discuss on the list. 
Status: Frederick fixed in the SwA profile; text in the core may need to be changed;
Action: Editors to review other Token profiles and verify that it does not apply to other documents.
Action: Editors to incorporate. Review pending.

Closed

310

Technical

Closed

Hal Lockhart: Clarification on using Key Identifier when SKI extension is not present. Vijay Gajjala; Are there alternative mechanisms that can be used in this case? Revisit.

http://lists.oasis-open.org/archives/wss/200408/msg00008.html
Resolution: Current document meets the alternative #1. Spec + Errata says that KeyIdentifier cannot be used unless token contains an SKI.
Action: Vijay to send out a new proposal.
Status: Vijay sent out proposal. Rich commented that this seemed sufficient.
Status: Discuss on the mailing list if the implementations have concerns about this being optional.
Status: Make it clear that you can include multiple key reference
methods in a single KeyInfo. This allows you to include a potentially more efficient (SKI) mechanism along with a potentially more interoperable mechanism (IssuerSerialNumber) for example.
Action: Ron to review.
Action: Vijay to point out what has changed in the spec.
http://www.oasis-open.org/apps/org/workgroup/wss/download.php/10649/oasis-2004xx-wss-soap-message-security-1.1-changes.pdf
Action: Vijay to get proposal to list working with Ron.
Action: Ron to send out email with comments outlining differences.
Status: Ron sent out observations to the mailing list - http://lists.oasis-open.org/archives/wss/200503/msg00017.html
Status: Editors to make changes

Closed

311

Technical

Closed

Nishimura Toshihiro: SWA Profile comments

http://lists.oasis-open.org/archives/wss/200407/msg00097.html
Resolution: Change incorporated into the spec.

Closed

312

Technical

Closed

Dana Kaufman: Feedback on SWA Profile-1.0-draft-06

http://lists.oasis-open.org/archives/wss/200407/msg00101.html
Action: Dana to work with Frederick on part 2 and 3 and post to list
Action: Review of draft 8 of SwA profile.
Resolution: Fixed in the profile.

Closed

313

Technical

Closed

Manveen Kaur: Errata WSS:SOAP Message Security v1.0

http://lists.oasis-open.org/archives/wss-comment/200408/msg00001.html
Action: Editors to review
Resolution: Fixed in Errata.

Closed

314

Editorial

Closed

Kojiro Nakayama: Comments on final+errata documents

http://lists.oasis-open.org/archives/wss/200408/msg00022.html
Resolution: Fixed in Errata

Closed

315

Technical

Closed

Dana Kaufman: Provide PKI examples?

http://lists.oasis-open.org/archives/wss/200408/msg00024.html
Action: Hal to provide errata text clarifying why token examples are not specified in core. Direct readers to look for examples in relevant profiles.
Status: Hal created text for Errata.
Action: Editors to update Errata/1.1
Status: Tony to post updates. Updated posted. http://www.oasis-open.org/apps/org/workgroup/wss/download.php/10115/oasis-2004xx-wss-x509-token-profile-1.1-changes.pdf
Action: TC to review in 1.1 Errata.

Closed

316

Editorial

Closed

Dana Kaufman: Minor item from SwA profile

http://lists.oasis-open.org/archives/wss/200408/msg00048.html
Resolution: Fixed in draft 8. Minor namespace issue.

Closed

317

Technical

Closed

Vijay Gajjala: Encrypted Header

http://lists.oasis-open.org/archives/wss/200408/msg00057.html
Action: Vijay to propose text
Action: TC to review and provide feedback
Status: Hal - leave open, sent email regarding this
http://www.oasis-open.org/archives/wss/200410/msg00069.html
Requires further discussion on list
Status: Hal okay with the concept.
Action: Hal to review and respond with updated text. http://lists.oasis-open.org/archives/wss/200412/msg00037.html

Closed

318

Technical

Closed

Vijay Gajjala: Encrypted Key

http://lists.oasis-open.org/archives/wss/200408/msg00058.html
Action: Vijay to propose text
Action: TC to review proposed text and provide feedback
Status: Needs review

Closed

319

Technical

Closed

Vijay Gajjala: Signature Confirmation

http://lists.oasis-open.org/archives/wss/200408/msg00059.html
Action: Vijay to do comparison of prior proposal from Eric Gravengard.
Action: TC to review proposed text and provide feedback
Status: Needs review

Closed

320

Technical

Closed

If EncryptedData is referenced from an EK within security header, then you don't need a separate reference list as child of security header.

http://lists.oasis-open.org/archives/wss/200407/msg00101.html
Action: Dana to get status.

Closed

321

Technical

Closed

Dana Kaufman: Clarify how to interpret/transform the encrypted contents of the attachment

http://lists.oasis-open.org/archives/wss/200408/msg00071.html
Action: Review draft 9. Frederick believes it has been addressed in this draft.
Status:  http://lists.oasis-open.org/archives/wss/200409/msg00082.html
Resolution: Addressed in the draft. Dana agrees.

Closed

322

Technical

Closed

Blake Dournaee: Are XML attachments opaque or not

http://lists.oasis-open.org/archives/wss/200408/msg00072.html
Resolution: http://lists.oasis-open.org/archives/wss/200409/msg00012.html

Closed

323

Technical

Closed

Blake Dournaee: Statement in SwA that when <EncyptedKey> element is present, <KeyInfo> element should not be present. This seems wrong.

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

Closed

324

Technical

Closed

Maneesh Sahu: What is the value in canonicalizing the content-length mime header?

http://lists.oasis-open.org/archives/wss/200409/msg00002.html
Resolution: http://lists.oasis-open.org/archives/wss/200409/msg00078.html

Closed

325

Technical

Closed

Which attachment headers to include in signature? Should headers be included in signature?

http://lists.oasis-open.org/archives/wss/200409/msg00014.html
Resolution: http://lists.oasis-open.org/archives/wss/200409/msg00078.html

Closed

326

Technical

Closed

Dana Kaufman: More comments on SwA profile - Draft 8.

http://lists.oasis-open.org/archives/wss/200409/msg00024.html
 

Closed

327

Technical

Closed

Timestamp ValueType needs to be clarified

http://lists.oasis-open.org/archives/wss/200409/msg00054.html

Closed

328

Editorial

Closed

Errata on STR transform

http://lists.oasis-open.org/archives/wss/200409/msg00055.html

Closed

329

Technical

Closed

Dana Kaufman: SwA profile comments
1. Insignificant whitespace in MIME headers should probably be stripped
rather than compressed during canonicalization
2. MIME header parameters should probably be ordered alphabetically
during canonicalization.
3. The signature example is missing critical elements.

http://lists.oasis-open.org/archives/wss/200409/msg00058.html

Closed

330

Editorial

Closed

Comments on oasis-200401-wss-soap-message-security-1 0-errata-003-changes.pdf -
1. Soap normalizing transform uri is incorrect - 3.7 Section 8.1 Algorithms, line 111
2. 4.1 Section 3.4 Examples, line 114
The correct line numbers are 305-308 (not 301-304).
3. 4.6 Section 11 Extended Example
The correct line numbers are 1392-1397 (not 1392-1396)...
Missing  </wsse:SecurityTokenReference> tag?

http://lists.oasis-open.org/archives/wss/200409/msg00086.html
Action: Small changes for editors (Tony)
Status: Tony made small changes, but not posted document.
Status: Documents updated and posted.

Closed

331

Editorial

Closed

Manveen Kaur: Errata WSS: SOAP Message security v1.0

http://lists.oasis-open.org/archives/wss-comment/200408/msg00001.html
Status: Comments not posted.
Status: Documents updated and posted.

Closed

332

Editorial

Closed

Manveen Kaur: Comments on Errata

http://lists.oasis-open.org/archives/wss-comment/200409/msg00002.html
Status: Comments not posted.
Status: Documents updated and posted.

Closed

333

Technical

Closed

Blake : Quoting Issues

http://lists.oasis-open.org/archives/wss/200410/msg00036.html
Action: Change examples to use quotes per MIME RFC. Add text to
indicate that SwA does not conform in examples.
ACTION[Blake]: Change Interop examples to use quotes per MIME RFC.
ACTION[Frederick]: Change Profile examples to use quotes per MIME RFC. Add text to indicate that SwA does not conform in examples.
 

Closed

334

Technical

Closed

Vijay: Including SAML AssertionID in the core as a direct ID reference mechanism.

http://lists.oasis-open.org/archives/wss/200410/msg00037.html
Action[Editors]: Add SAML 1.1 AssertionId to set of IDREFs for signature references
Action[Editors]: Indicate xml:id will be added to set of IDREFs for
signature references when available.
Action([Ron]: Propose what to do about SAML 2.0 assertion IDs.
Status: Ron sent message -
http://www.oasis-open.org/archives/wss/200411/msg00003.html
Proposal is to anticipate SAML 2.0 attribute by adding another AssertionID, which has different namespace. Should add both for SAML 1.1 and SAML 2.0.Proposed as errata for 1.1
Already agreed to add 1.1 attribute, now deciding whether to add 2.0 as well. Ron draft specific text to enable vote on this
Action: Editors to integrate Ron's text into 1.1 document
Resolution: Text in core

Closed

335

Editorial

Duplicate

WSS comments list: Content-Type and wss-swa-profile-1.0-draft-11

http://lists.oasis-open.org/archives/wss-comment/200410/msg00000.html
Resolution: Duplicate of 333.

Closed

336

Editorial

Closed

Dana Kaufman - Small Change: wss-swa-profile-1.0-draft

http://lists.oasis-open.org/archives/wss/200410/msg00057.html
Resolution: Fixed in draft 13 of SwA profile.

Closed

337

Editorial

Closed

Frederick - Updated scenarios (Edits to scenario doc for SWA interoperability)

http://lists.oasis-open.org/archives/wss/200410/msg00058.html

Closed

339

Editorial

Closed

Hal: Errata for X.509 Token Profile - Reference for PKIPath

http://lists.oasis-open.org/archives/wss/200410/msg00067.html
Action: editors to update X.509 token profile
http://lists.oasis-open.org/archives/wss/200411/msg00053.html

Closed

340

Technical

Closed

Blake: Short list of SwA interop 1 issues

http://lists.oasis-open.org/archives/wss/200411/msg00004.html

Closed

341

Technical

Closed

Maneesh: Currently lose the content transfer encoding in WSS SwA encryption

http://lists.oasis-open.org/archives/wss/200411/msg00009.html
Duplicate of 344.

Closed

342

Technical

Closed

Ramana Turlapati: Phrasing in SwA profile implies that MimeType is required instead of being optional

http://lists.oasis-open.org/archives/wss/200411/msg00010.html

Closed

343

Technical

Closed

Frederick: Limiting SwA refernces to CID form?

http://lists.oasis-open.org/archives/wss/200411/msg00015.html

Closed

344

Technical

Closed

Comments on SWA profile interoperability - comments on base64 encoding in relation with encrypted and signed MIME parts.

http://lists.oasis-open.org/archives/wss/200411/msg00065.html
Status: Frederick sent specific proposal to list.  Please comment on the e-mail.  If no comments on the proposal will put in the new draft
Resolution: Proposal put in new draft. Closed.

Closed

345

Technical

Closed

Blake: Additional SwA interop issues

http://lists.oasis-open.org/archives/wss/200411/msg00054.html Resolution: Fixed. Closed.

Closed

346

Technical

Closed

Frederick: When doing Attachment-Complete-Transform for signatures should the "<>" associated with the Content-ID value be included in the MIME header canonicalization"

http://lists.oasis-open.org/archives/wss/200411/msg00087.html Resolution: Fixed. Closed.

Closed

347

Editorial

Closed

NISHIMURA: Editorial comments on core 1.0

http://lists.oasis-open.org/archives/wss/200412/msg00008.html
Resolution: Editors to incorporate text

Closed

348

Technical

Closed

Items needing clarification in SWA Profile draft 15. (Was SwA Profile draft 15 vote Dec 14)

http://lists.oasis-open.org/archives/wss/200412/msg00032.html
Resolution: Duplicate

Closed

349

Technical

Close

Ron: Does the profile effectively prohibit the use of a ReferenceList (in a Security header) to reference an encrypted attachment?
 

http://lists.oasis-open.org/archives/wss/200412/msg00042.html
Resolution: Don't want to prohibit ReferenceList. Doc needs to be updated.
Action: Frederick to make the update.

Closed

350

Technical

Closed

Thomas: thumbprint proposal

http://lists.oasis-open.org/archives/wss/200412/msg00057.html

Closed

351

Technical

Pending Review

Hal: Proposed text changes relating to EncryptedHeader

http://lists.oasis-open.org/archives/wss/200412/msg00037.html
Status: Editors to update

Closed

352

Technical

Pending Review

Hal: Proposed text changes to 1.1 re: EncryptedKey references

http://lists.oasis-open.org/archives/wss/200412/msg00034.html
Status: Editors to update

Closed

353

Technical

Closed

1.1 schema question

http://lists.oasis-open.org/archives/wss/200412/msg00058.html
Resolution: New schema elements have been added in 1.1.

Closed

354

Editorial

Closed

comments on wss-saml-token-profile-1.0-cd-04

http://lists.oasis-open.org/archives/wss-comment/200412/msg00003.html
Action: Editors to create an errata for SAML 1.1 token profile
Status: Ron posted an errata: http://lists.oasis-open.org/archives/wss/200503/msg00030.html

Closed

355

Editorial

Closed

Do examples of signing element(s) in security header need to be updated

http://lists.oasis-open.org/archives/wss/200502/msg00000.html
Action: Leave open for discussion on mailing list.
Resolution: All action items from the following mail have been resolved:http://lists.oasis-open.org/archives/wss/200502/msg00015.html

Closed

356

Editorial

Closed

Open SwA profile CD issues

http://lists.oasis-open.org/archives/wss/200502/msg00008.html
Status: Frederick has proposed some text.
Status: Frederick's text approved.

Closed

357

Technical

Closed

Need a Token Type URI in SAML token profile

http://lists.oasis-open.org/archives/wss/200502/msg00012.html
Status: Vijay proposal for Token type; Don't put in errata Use attribute in 1.1.

Status: Linked to 391.

Resolution: Changes incorporated into SAML Token Profile 1.1

Closed

358

Technical

Closed

Comments on wss-swa-profile-1.0-cd-01

http://lists.oasis-open.org/archives/wss-comment/200502/msg00004.html
Status: Split into specific issues.
Resolution: Duplicate. Issue was split into specific issues that are being tracked separately.

Closed

359

Editorial

Closed

SWA profile: Clarify Goals and non-goals

http://lists.oasis-open.org/archives/wss/200502/msg00054.html

Closed

360

Editorial

Closed

SWA profile: Add additional clarification of relationship to other work, particularly MTOM and S/MIME

http://lists.oasis-open.org/archives/wss/200502/msg00054.html

Closed

361

Technical

Closed

SWA profile: Layering Issue - MIME and SOAP processing are intermixed

http://lists.oasis-open.org/archives/wss/200502/msg00054.html

Closed

362

Technical

Closed

SWA profile: Clarify that Attachment-Content-Only/Attachment-Complete Signature Transform inputs are octet-streams

http://lists.oasis-open.org/archives/wss/200502/msg00054.html

Closed

363

Technical

Closed

SWA profile: Allow ds:Reference transform chain (section 4.4.4)  to allow additional transforms including base64, while clarifying typically not needed.

http://lists.oasis-open.org/archives/wss/200502/msg00054.html

Closed

365

Technical

Closed

SWA profile: Clarify relationship to S/MIME, including how S/MIME attachments are handled and of possible interactions in signature processing

http://lists.oasis-open.org/archives/wss/200502/msg00054.html

Closed

367

Technical

Closed

Can SwA signatures be persisted

http://lists.oasis-open.org/archives/wss/200502/msg00054.html

Closed

366

Technical

Closed

SWA profile: Review MIME headers that are included in signature, make extensible

http://lists.oasis-open.org/archives/wss/200502/msg00054.html
Status: Tony volunteered to help draft a proposal

Action Item: Frederick to follow up with Tony and draft a proposal and send to list.

Closed

368

Technical

Closed

SWA profile: Signatures over portions of attachments precluded

http://lists.oasis-open.org/archives/wss/200502/msg00054.html

Closed

369

Technical

Closed

SWA profile: Clarify which MIME headers are encrypted with "content and headers" encryption

http://lists.oasis-open.org/archives/wss/200502/msg00054.html
Resolution: Frederick to post changes.

Closed

371

Technical

Pending

Review

X.509v1 Certificate support in 1.0 Errata

http://lists.oasis-open.org/archives/wss/200502/msg00051.html
Action Item: Mike to send out revised proposal with new text.
Status: Mike sent out a proposal : http://lists.oasis-open.org/archives/wss/200503/msg00025.html
 

TC

372

Technical

Closed

Interop scenario 1:3->Timestamp

http://lists.oasis-open.org/archives/wss/200503/msg00000.html
Resolution: http://lists.oasis-open.org/archives/wss/200503/msg00001.html

Closed

373

Editorial

Pending

Review

WSS spec legibility

http://lists.oasis-open.org/archives/wss/200503/msg00002.html
Action: Editors to add additional white space
Action: Tony will cover core. Ron to cover SAML profile and Thomas to cover REL profile.

Editors

374

Technical

Pending

Review

TokenType URI for EncryptedKey

EncryptedKey doesn't have a TokenType URI.
For the EncryptedKey we propose the following URI:
http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-soap-message-security-1.1#EncryptedKey
And that the reference to established encrypted key be modified to use
http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-soap-message-security-1.1#EncryptedKeySHA1 
Status: Editors to incorporate this change.

Editors

375

Editorial

Closed

X.509 Token Profile 1.0 says "Interim draft"

http://lists.oasis-open.org/archives/wss/200503/msg00024.html
Status: no action

Closed

376

Technical

Closed

Manveen: Input format to transform

http://lists.oasis-open.org/archives/wss-comment/200503/msg00000.html;
Proposed resolution: http://lists.oasis-open.org/archives/wss-comment/200503/msg00001.html
Action Item: Frederick to incorporate his proposal into the SwA profile.

Closed

377

Technical

Closed

xenc:ReferenceList SwA comment

http://lists.oasis-open.org/archives/wss-comment/200503/msg00002.html

Incorporate into the docs. http://lists.oasis-open.org/archives/wss/200504/msg00018.html
Status: Changes are in draft 19
Resolution: See draft 19 for the changes.

Closed

379

Technical

Closed

Kerberos TP: Use Kerberos V GSS-API mechanism

http://lists.oasis-open.org/archives/wss-comment/200504/msg00001.html
Tony - good comment need to provide wrapped and unwrapped content both GSS and Kerberose level. 
Current interop only allows unwrapped raw Kerberos was found as part of interop looking at both wrapped and unwrapped. Another token type URI needed no objections from the TC so 379 pending action item editors add URI for wrapped token and update interop

Status: Use Kerberos V GSS-API mechanism - conceptual agreement reached
Resolution: Incorporated changes into Kerberos Token profile.

Closed

380

Technical

Closed

Kerberos TP: Service principal names

What kind of service principal names should be used? Or is this to be specified by applications that use this profile? 

If so then this should be pointed out.  Are non-Kerberos names to be mapped to Kerberos V principal names? 

If so, how, or where is this specified?

http://lists.oasis-open.org/archives/wss-comment/200504/msg00001.html
Tony - service principle name input requested, do we need this in the spec or should it be addressed in the application.  Tony stated it belongs in the application.  
Hal - Spec needs clarification should be pending due to it's new status.
Status: changes in revision 3
Resolution: Changes incorporated into Kerberos Token profile.

Closed

381

Technical

Closed

Kerberos TP: Session key negotiation and key re-use

The profile should say whether or not the optional sub-session key in the AP-REQ's 

Authenticator MAY/SHOULD/MUST be present/absent, which of the Ticket's or 

Authenticator's session key "wins" when the Authenticator asserts a sub-session key.

http://lists.oasis-open.org/archives/wss-comment/200504/msg00001.html
Tony - problem in interop some used session key and some sub key.  Spec leans towards sub key rather than session key.  Question is do we want to fix this with one URI and one processing model that states we use the sub key otherwise use session key.
Clarification - fix in processing, one URI defer to 1510. pending editors add clarification text
clarified in latest draft
Resolution: Changes incorporated into Kerberos Token profile.

Editors

382

Technical

Closed

Kerberos TP: Replay protection and mutual authentication

This profile says little about replay protection and nothing about mutual authentication.

While it may be sensible to leave replay protection to the "mechanisms described in WS-Security"

I get the impression from the text in section 4 that there are special considerations related to this

particular profile, yet no RFC2119 terminology (MAY/SHOULD/MUST/...) is used to indicate what,

if anything, implementers should do. As for mutual authentication, if the "mechanisms described in

WS-Security" provide it, then that should be explained in the profile, just as with replay protection.

http://lists.oasis-open.org/archives/wss-comment/200504/msg00001.html
unwrapped does have potential replay attack, however combined with timestamp would not.  Add clarification text - either use the wrapper or make sure that you are signed and call it out as a security consideration. 
pending editors adding clarification text preventing reply by combining with signed timestamp or wrapper as protection
Resolution: Changes incorporated into Kerberos token profile for replay protection. Mutual authentication issue is tracked through issue 396.

Closed

383

Technical

Closed

Kerberos TP: Error Handling

This profile does not make use of the KRB-ERROR Kerberos V PDU, nor does it mention any

Kerberos V error codes.  Instead it refers to error codes "defined in the WS-Security specification"

without giving any indication of how Kerberos V error conditions on the server (acceptor) side

should be mapped to WSS errors, if at all.

http://lists.oasis-open.org/archives/wss-comment/200504/msg00001.html

Closed

386

Editorial

Closed

Kerberos TP: Repeat symmetric encryption requirement from Section 3.5 in Section 3.4?

Section 3.5 says that "[when] a Kerberos ticket is referenced as an encryption key, the

encryption algorithm MUST be a symmetric encryption algorithm."  At first glance this

would seem self-evident given the normative reference to RFC1510, but since the encryption

in question is not based on Kerberos specifications this is not so obvious, which leads me

to ask; why not say the same thing in section 3.4?
http://lists.oasis-open.org/archives/wss-comment/200504/msg00001.html
pending action for editor to add clarification
Resolution: Changes made to Kerberos TP.

Closed

387

Editorial

Closed

Kerberos TP: Undefined terms/missing references

Section 2.3 lists terms not used anywhere else in the document, such as 'UCS' and 'UTF-8'. 

Is the document incomplete, perhaps with regards to internationalization (I18N)?  Note that

Kerberos V currently can only be interoperably used where principal and realm names are

limited to US-ASCII characters (the IETF KRB WG is working on properly

internationalizing the protocol).

http://lists.oasis-open.org/archives/wss-comment/200504/msg00001.html
pending editors add terminology.

Resolution: Changes made to Kerberos TP.

Closed