RE: [ws-sx] Issue 116: Is Appendix D Normative?

["Hal Lockhart" <hlockhar@bea.com>]

As promised, I have tried to determine the origin of all the rules in
Appendix D, to try to settle the issue of whether the information is a
summary of rules normatively specified elsewhere. I also looked at the
discussion thread for Issue 33, which resulted in the creation of
Appendix D.

Issue 33, began when Prateek noted that one could infer from Appendix C
(clearly marked as non-normative) certain information about what items
should be encrypted. Prateek suggested that this information appear in
section 7.3 & 7.4, which would of course have indicated it was
normative. This was later expanded to include signatures as well as
encryption and moved to Appendix D.

Here is what I have found. Although it is easy to tell when you find a
rule, it is much harder to say for sure no rule exists or that there are
not other, contradictory rules elsewhere. So I hope someone will correct
me if I have missed a reference.

First I am confident that the WSS and WS-SecCon and WS-Trust do NOT tell
you what you should encrypt or sign.

Therefore I confined my attention to WS-SP. Here is what I found. Note
once again that this is only the stuff you always have to sign or
encrypt in the absence of SignedElements or EncryptedElements
assertions. My notes are inside of {}.

D.1 Elements signed by the message signature

1. The wsu:Timestamp element.
{Section 6.2 says if the timestamp is present it must be signed or
protected by the transport level. Perhaps the latter should be called
out in a separate rule in the same way as D.2 #2.}

2. All wsse11:SignatureConfirmation elements.
{I can't find anything. Specifically section 9 - WSS 1.1 Properties
[Signature Confirmation] (lines 2288-2294) does not mention an integrity
requirement the way section 6.2 does, even though this is the logical
place for the rule.}

3. Security Tokens corresponding to [Initiator Signature
Token],[Recipient Signature Token], [Initiator Encryption Token],
[Recipient Encryption Token], [Signature Token] or [Encryption Token]
when [Token Protection] has a value of 'true'.
{Section 6.5 mandates this}

4. Security Tokens corresponding to [Signed Supporting Tokens] or
[Signed Endorsing Supporting Tokens].
{Section 8.2 & 8.5 mandate this.}

D.2 Elements signed by all endorsing signatures

1. The ds:Signature element that forms the message signature.
{Section 8.3 mandates this.}

2. The wsu:Timestamp element in the case of a transport binding.
{Section 8.3 mentions this using a lowercase "should".}

D.3 Elements signed by a specific endorsing signature

1. Security Tokens corresponding to [Endorsing Supporting Tokens] or
[Signed Endorsing Supporting Tokens] when [Token Protection] has a value
of 'true'
{Section 8.8 mandates this.}

D.4 Elements that are encrypted

1. The ds:Signature element that forms the message signature when
[Signature Protection] has a value of 'true'.
{Section 6.4 mandates this.}

2. All wsse11:SignatureConfirmation elements when [Signature Protection]
has a value of 'true'.
{Section 6.4 mandates this.}

3. Any wsse:UsernameToken when a transport binding is NOT being used.
{I can't find this anywhere. Section 6.7.1 #2. b. (Strict Layout Rules)
says "A Username token (usually in encrypted form) MUST occur ..." I
take this as a clear indication that a Username token will not ALWAYS be
encrypted.}

-----

My recommendations are:

I. Amend Appendix D with references to the source.
II. Add a rule for Timestamp protected by Transport.
III. Amend the Signature Confirmation text in section 9 to indicate an
integrity requirement.
IV. Amend the part of 8.3 that mentions transport binding to be an
uppercase MUST.
V. Amend or eliminate rule D.4 #3 based on the outcome of Issue 115.

Hal


> -----Original Message-----
> From: Hal Lockhart
> Sent: Monday, October 16, 2006 11:18 AM
> To: Marc Goodner; ws-sx@lists.oasis-open.org
> Subject: RE: [ws-sx] Issue 116: Is Appendix D Normative?
> 
> Ok, then where specifically does rule D.4 #3 come from? (for example)
> 
> Hal
> 
> > -----Original Message-----
> > From: Marc Goodner [mailto:mgoodner@microsoft.com]
> > Sent: Monday, October 16, 2006 10:55 AM
> > To: Marc Goodner; Hal Lockhart; ws-sx@lists.oasis-open.org
> > Subject: RE: [ws-sx] Issue 116: Is Appendix D Normative?
> >
> > I've looked into this and Appendix D was added to SP per issue 33.
> >
> > From Gudge's accepted proposal for that issue:
> > "I think this information belongs in an appendix, as it's really a
> > collation of existing material."
> >
> > So Appendix D is not normative and the material does exist
elsewhere.
> I
> > believe 116 can be closed with no action.
> >
> > -----Original Message-----
> > From: Marc Goodner [mailto:mgoodner@microsoft.com]
> > Sent: Wednesday, October 11, 2006 6:33 AM
> > To: Hal Lockhart; ws-sx@lists.oasis-open.org
> > Subject: [ws-sx] Issue 116: Is Appendix D Normative?
> >
> > Issue 116
> >
> > -----Original Message-----
> > From: Hal Lockhart [mailto:hlockhar@bea.com]
> > Sent: Tuesday, October 10, 2006 2:12 PM
> > To: ws-sx@lists.oasis-open.org
> > Cc: Marc Goodner
> > Subject: [ws-sx] NEW Issue: Is Appendix D Normative?
> >
> > PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD
UNTIL
> > THE ISSUE IS ASSIGNED A NUMBER.
> > The issues coordinators will notify the list when that has occurred.
> >
> > Protocol:  ws-sp
> >
> >
>
http://www.oasis-open.org/committees/download.php/20578/ws-securitypolic
> > y-1.2-spec-ed-01-r10-diff.pdf
> >
> > Artifact:  spec
> >
> > Type:
> >
> > editorial
> >
> > Title:
> >
> > Is Appendix D normative or is it just a summary of information found
> > elsewhere in the spec as Appendix A is?
> >
> > Description:
> >
> > The last sentence of section 1 says "Section 11, all examples and
all
> > Appendices are non-normative." That suggests that Appendix D is a
> > summary of normative information which is found elsewhere. However,
I
> > can not find any other source of the information in WS-SP. If
Appendix
> D
> > is non-normative, then I question why it is in the document at all.
> >
> > Note that Appendix A explicitly says it is non-normative, suggesting
> > that some Appendices may be. Appendix B could conceivably be
> considered
> > normative, it is hard to tell. Appendix C is examples, so it seems
> safe
> > to assume they are not normative, however it might be good to say
> > explicitly that if Appendix C conflicts with section 6.7 then 6.7
> takes
> > precedence.
> >
> > Related issues:
> >
> > My previous issue.
> >
> > Proposed Resolution:
> >
> > Clarify which Appendices are normative.