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

["Hal Lockhart" <hlockhar@bea.com>]

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
> > >>>
> > >>>