[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
+1 to Hal's rationale However I suggest we modify the strict processing rule #4 from wss 1.0 to be as follows for both wss 1.0 and wss 1.1 , changing "encrypted" to "xenc:EncryptedData" in the first sentence, and adding the 2nd paragraph as noted: > 4. If there are any xenc:EncryptedData 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. > Any xenc:EncryptedKey elements that do not contain a > xenc:ReferenceList element should be treated as a security token > and placed in the message before the key needs to be referenced. regards, Frederick Frederick Hirsch Nokia On Oct 16, 2006, at 8:08 PM, ext Hal Lockhart wrote: > 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]