[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 seemswrong for EncryptedKey
I don't believe so. I think for WSS 1.0 we want to allow the xenc:RefList to appear inside the xenc:EncKey and for WSS 1.1 we want the xenc:RefList to be outside the xenc:EncKey. Gudge -----Original Message----- From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com] Sent: Monday, October 02, 2006 8:49 AM To: Martin Gudgin Cc: Frederick Hirsch; Hal Lockhart; Marc Goodner; ws-sx@lists.oasis-open.org Subject: Re: [ws-sx] RE: Issue 90: Description of Strict Formatting seems wrong for EncryptedKey Should item #4 in the proposed 6.7.2 be the same as the revised #4 in proposed 6.7.1? (i.e. should the second #4 be the same as the first one?) regards, Frederick Frederick Hirsch Nokia On Sep 30, 2006, at 1:47 PM, ext Martin Gudgin wrote: > 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]