RE: [ws-sx] RE: Issue 90: Description of Strict Formatting seemswrong for EncryptedKey

[Martin Gudgin <mgudgin@microsoft.com>]

Hal,

Here is a proposal for resolving issue 90. Let me know if it works for you. I've just duplicated 6.7.1 so we now have a version for WSS 1.0 and a version for WSS 1.1.

Regards

Gudge

6.7.1 Strict Layout Rules for WSS 1.0

        1.      Tokens that are included in the message MUST be declared before use. For example,
                a.      A local signing token MUST occur before the signature that uses it.
                b.      A local token serving as the source token for a derived key token MUST occur before that derived key token.
                c.      A local encryption token MUST occur before the reference list that points to xenc:EncryptedData elements that use it.
                d.      If the same token is used for both signing and encryption, then it should appear before the ds:Signature and xenc:ReferenceList elements in the security header that are generated using the token.

        2.      Signed elements inside the security header MUST occur before the signature that signs them.  For example,
                a.      A timestamp MUST occur before the signature that signs it.
                b.      A Username token (usually in encrypted form) MUST occur before the signature that signs it.
                c.      A primary signature MUST occur before the supporting token signature that signs the primary signature's signature value element.

        3.      When an element in a security header is encrypted, the resulting xenc:EncryptedData element has the same order requirements as the source plain text element, unless requirement 4 indicates otherwise. For example, an encrypted primary signature MUST occur before any supporting token signature per 2c above and an encrypted token has the same ordering requirements as the unencrypted token.

        4.      If there are any encrypted elements in the message then a top level xenc:ReferenceList element or a top level xenc:EncryptedKey element which contains an xenc:ReferenceList element MUST be present in the security header. The xenc:ReferenceList or xenc:EncryptedKey MUST occur before any xenc:EncryptedData elements in the security header that are referenced from the reference list.


6.7.2 Strict Layout Rules for WSS 1.1

        1.      Tokens that are included in the message MUST be declared before use. For example,
                a.      A local signing token MUST occur before the signature that uses it.
                b.      A local token serving as the source token for a derived key token MUST occur before that derived key token.
                c.      A local encryption token MUST occur before the reference list that points to xenc:EncryptedData elements that use it.
                d.      If the same token is used for both signing and encryption, then it should appear before the ds:Signature and xenc:ReferenceList elements in the security header that are generated using the token.

        2.      Signed elements inside the security header MUST occur before the signature that signs them.  For example,
                a.      A timestamp MUST occur before the signature that signs it.
                b.      A Username token (usually in encrypted form) MUST occur before the signature that signs it.
                c.      A primary signature MUST occur before the supporting token signature that signs the primary signature's signature value element.
                d.      A wsse11:SignatureConfirmation element MUST occur before the signature that signs it.

        3.      When an element in a security header is encrypted, the resulting xenc:EncryptedData element has the same order requirements as the source plain text element, unless requirement 4 indicates otherwise. For example, an encrypted primary signature MUST occur before any supporting token signature per 2c above and an encrypted token has the same ordering requirements as the unencrypted token.

        4.      If there are any encrypted elements in the message then a top level xenc:ReferenceList element MUST be present in the security header. The xenc:ReferenceList MUST occur before any xenc:EncryptedData elements in the security header that are referenced from the reference list. However, the xenc:ReferenceList is not required to appear before independently encrypted tokens such as the xenc:EncryptedKey token as defined in WSS.

        5.      An xenc:EncryptedKey element without an internal reference list [WSS: SOAP Message Security 1.1] MUST obey rule (1).


-----Original Message-----
From: Martin Gudgin [mailto:mgudgin@microsoft.com]
Sent: Tuesday, September 05, 2006 9:33 PM
To: Hal Lockhart
Cc: ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] RE: Issue 90: Description of Strict Formatting seems wrong for EncryptedKey

Hal,

I think I'm fine with your text below for clause 4 of 6.7.1. but I wonder if what we actually need is a version of 6.7.1 for the cross product of the binding types and WSS 1.0 and WSS 1.1

When I asked you to look at Appendix C.3, I was really asking if you felt it was accurate at least with respect to the example covered. I agree that simpler examples would be useful, but as you say, might be quite a bit of work...

Gudge

-----Original Message-----
From: Hal Lockhart [mailto:hlockhar@bea.com]
Sent: Tuesday, August 22, 2006 3:19 PM
To: Martin Gudgin
Cc: ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] RE: Issue 90: Description of Strict Formatting seems wrong for EncryptedKey


Martin Gudgin wrote:

> I believe that you are correct that 6.7.1 clause 4 is incorrect when
> applied generally to asymmetric bindings. The easiest fix is probably
to
> remove the words 'top level' from line 1503 of [1].

I think it would be clearer to change clause 4 to say:

4. If there are any encrypted elements in the message then a top level
xenc:ReferenceList element or a top level xenc:EncryptedKey element
which contains a xenc:ReferenceList element MUST be present in the
security header. The xenc:ReferenceList or xenc:EncryptedKey MUST occur
before any xenc:EncryptedData elements in the security header that are
referenced from the reference list. However, the xenc:ReferenceList or
xenc:EncryptedKey is not required to appear before independently
encrypted tokens such as the xenc:EncryptedKey token as defined in WSS.


>
> Did you also look at Appendix C.3 (which I think is more detailed than
> 6.7.1 and applies directly to the Asymmetric Binding)?

In general I think it is poor practice to expect the reader to deduce
processing rules from examples, which necessarily must show only a
single instance.

As I mentioned on a previous call, I think it would be useful to have
some shorter, simpler examples. The current "kitchen sink" examples have
so many moving parts it is hard to see what bit of policy drives what
part of the message.

An alternative (but I admit it would be a lot of work) would be to
annotate every few lines of the message to indicate exactly which lines
in the policies were responsible for causing them to be included.

Hal

>
> Regards
>
> Gudge
>
> [1]
>
http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/18836/ws
> -securitypolicy-1.2-spec-ed-01-r07-diff.doc
>
> > -----Original Message-----
> > From: Hal Lockhart [mailto:hlockhar@bea.com]
> > Sent: 18 July 2006 15:18
> > To: Marc Goodner; ws-sx@lists.oasis-open.org
> > Subject: [ws-sx] RE: Issue 90: Description of Strict
> > Formatting seems wrong for EncryptedKey
> >
> > As I mentioned on the last call, the WS-I Basic Security Profile was
> > written assuming that either a ReferenceList or an EncryptedKey
would
> > appear at the top level for each encryption step, but not both. See
> > especially section 6.1 and section 10 of that document.
> >
> > http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html
> >
> > Hal
> >
> > > -----Original Message-----
> > > From: Marc Goodner [mailto:mgoodner@microsoft.com]
> > > Sent: Tuesday, July 11, 2006 1:59 PM
> > > To: Hal Lockhart; ws-sx@lists.oasis-open.org
> > > Subject: Issue 90: Description of Strict Formatting seems wrong
for
> > > EncryptedKey
> > >
> > > Issue 90.
> > >
> > > -----Original Message-----
> > > From: Hal Lockhart [mailto:hlockhar@bea.com]
> > > Sent: Tuesday, July 11, 2006 7:59 AM
> > > To: ws-sx@lists.oasis-open.org
> > > Cc: Marc Goodner
> > > Subject: NEW Issue: Description of Strict Formatting seems wrong
for
> > > EncryptedKey
> > >
> > > 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/apps/org/workgroup/ws-sx/download.ph
> > p/18837/ws
> > > -securitypolicy-1.2-spec-ed-01-r07.pdf
> > >
> > > Artifact:  spec
> > >
> > > Type:
> > >
> > > design
> > >
> > > Title:
> > >
> > > Rules for strict format of security element seem incorrect
> > in the case
> > > of encrypted key used with Asymmetric Key. It is my
> > understanding that
> > > for every encryption, there will either be a ReferenceList (for
> > > Symmetric) or an EncryptedKey (for Asymmetric). However, the rules
> > seem
> > > to require a tope level ReferenceList even when an EncryptedKey is
> > > present. This causes implementation problems, especially
> > for WSS 1.0.
> > >
> > > Description:
> > >
> > > Section 6.7.1 (lines 1528-1536) say:
> > >
> > > ----
> > > 4.        If there are any encrypted elements in the message then
a top
> > > level xenc:ReferenceList element MUST be present in the security
> > header.
> > > The xenc:ReferenceList MUST occur before any xenc:EncryptedData
> > elements
> > > in the security header that are referenced from the reference
list.
> > > However, the xenc:ReferenceList is not required to appear before
> > > independently encrypted tokens such as the
> > xenc:EncryptedKey token as
> > > defined in WSS.
> > > 5.        An xenc:EncryptedKey element without an internal
reference
> list
> > > [WSS: SOAP Message Security 1.1] MUST obey rule (1).  An
> > > xenc:EncryptedKey element with an internal reference list MUST
> > > additionally obey rule (4).
> > > ----
> > >
> > > But my understanding is that you use either an EncryptedKey or a
> > > ReferenceList, but not both. If this is not a simple error, but
> > > intentional, I will provide information about implementation
> > > difficulties.
> > >
> > >
> > > Related issues:
> > >
> > >
> > >
> > > Proposed Resolution:
> > >
> > > Change #4 to say ReferenceList or Encrypted Key.
> > >
> > > Hal
> >
> >