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

[Martin Gudgin <mgudgin@microsoft.com>]

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