[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [ws-sx] RE: Issue 90: Description of Strict Formattingseems wrong for EncryptedKey
I don't believe my proposed solution specifies two different sets of rules. On the contrary, it states that the rules for xenc:EncryptedKey are the same as for any other token in the WSS 1.1 case. I believe one can state 'for WSS 1.0' and 'for WSS 1.1' using the sp:WSS10 and sp:WSS11 assertions, respectively. I believe the objective of strict is to ensure that one has seen things in the wsse:Security header prior to needing to use them. And I believe the proposed solution does exactly that. FWIW - I don't believe my proposal for closing this issue changes anything. I believe all I have done is separate into two distinct sets of statements what was in the original text. Gudge -----Original Message----- From: Hal Lockhart [mailto:hlockhar@bea.com] Sent: Monday, October 16, 2006 8:08 PM To: Martin Gudgin; Frederick Hirsch Cc: Marc Goodner; ws-sx@lists.oasis-open.org Subject: RE: RE: [ws-sx] RE: Issue 90: Description of Strict Formatting seems wrong for EncryptedKey I don't agree with this solution. 1) It seems wrong to have two different sets of rules for what strict formatting requires. 2) I don't even think "for WSS 1.0" and "for WSS 1.1" are even well defined. Most messages are legal under both. Are we supposed to scan the message for the 1.1 namespace? I don't think even that is sufficient, since I believe there are cases where you can follow explicitly 1.1 processing rules even though the 1.1 namespace does not appear. How about a compromise where we say: a) If an encrypted key does not contain a reference list, it is considered a token and follows the rules for tokens. b) if an encrypted key contains a reference list, it indicates a encryption step and is interchangeable with a top level reference list. --- WRT to having interoped this style of formatting, the point is we are not allowing or prohibiting a particular style, we are defining what should be allowed as "strict". I presume the purpose of "Strict" is to minimize code complexity and/or processing speed. I suggest that your double rule proposal does neither. Hal > -----Original Message----- > From: Martin Gudgin [mailto:mgudgin@microsoft.com] > Sent: Tuesday, October 10, 2006 7:11 PM > To: Hal Lockhart; Frederick Hirsch > Cc: Marc Goodner; ws-sx@lists.oasis-open.org > Subject: RE: RE: [ws-sx] RE: Issue 90: Description of Strict Formatting > seems wrong for EncryptedKey > > While the syntax and processing described in Chapter 9 did not change, > xenc:EncryptedKey did become a first class token in WSS 1.1. Hence the > processing rules for WSS 1.1 WRT xenc:EncryptedKey match those for any > other symmetric key bearing token. Hence xenc:ReferenceList appears as a > child of wsse:Security. > > FWIW - Microsoft has done WSS 1.1 interop with several partners using this > style. > > Gudge > > -----Original Message----- > From: Hal Lockhart [mailto:hlockhar@bea.com] > Sent: Tuesday, October 03, 2006 9:17 AM > To: Frederick Hirsch; Martin Gudgin > Cc: Marc Goodner; ws-sx@lists.oasis-open.org > Subject: RE: [ws-sx] RE: Issue 90: Description of Strict Formatting seems > wrong for EncryptedKey > > I don't understand this either. It is true that WSS 1.1 defines a way to > reference encrypted keys as tokens. However the syntax and processing > described in Chapter 9 was not changed. I assumed that the normal > usecase for an encrypted key reference was if you were going to reuse > the key in a subsequent message - a kind of light weight session. > > Fundamentally this is about what should the canonical form be? I don't > think the 1.0 style of using Reference List for symmetric keys and > encrypted key for asymmetric keys is either easier or harder to process > than the Gudge proposed style of always using Reference list and > treating encrypted keys as a token. (I assume that ease of processing by > the receiver is the motivation behind "strict" mode.) > > Therefore, unless somebody can propose why the latter style should be > preferred in "strict" mode, I think it is better to use the same style > for both WSS 1.0 and 1.1 in the interests of avoiding endless confusion > and spurious "invalid strict format" faults. > > Hal > > > -----Original Message----- > > From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com] > > Sent: Monday, October 02, 2006 11:49 AM > > To: ext 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]