[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] RE: Issue 90: Description of Strict Formatting seems wrong for EncryptedKey
Ok, I have reluctantly decided to accept this proposal. Hal > -----Original Message----- > From: Martin Gudgin [mailto:mgudgin@microsoft.com] > Sent: Saturday, September 30, 2006 1:48 PM > To: Hal Lockhart; Marc Goodner > Cc: ws-sx@lists.oasis-open.org > Subject: RE: [ws-sx] RE: Issue 90: Description of Strict Formatting seems > wrong for EncryptedKey > > 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 > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]