[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
Ch 5: Security Header
lines 435-445 (SHOULD) (Ordering guidelines)
Ch 8: Signatures
lines 856-858 (SHOULD)
lines 922-925 (MUST)
Ch 9: Encryption
lines 1105-1110 (MUST)
The discrepancy is that the MUSTs in Ch 8,9 logically override
the SHOULD in Ch 5. The guidelines in Ch 5 appear to be what
existing applications and the example in Ch 11 are using.
My proposal is that the guidelines in Ch 5 should be modified
to accurately describe the ordering algorithm and that the
statements in Ch 8 and Ch 9 be modified to refer back to those
guidelines.
There appear to be two requirements driving the guidelines:
1. A technical reqt that sig and encr elements precede
previous sig and encr elements so that the receiver can
properly apply the transformations to decrypt data and
verify signatures. These operations must be done in
the reverse order that they were originally performed
in order for them to work properly.
2. A usability requirement that information bearing elements
such as tokens and the timestamp appear in front of the
signature and encryption elements so that the document
is more readable and user-friendly.
Therefore, my proposal is that the following changes will remove the
current ambiguities in the spec and meet the above requirements:
Replace the first sentence on lines 435-436 with the following:
"The following are the Security header element ordering
guidelines: As elements (except signature blocks and encryption
blocks) are added to a <wsse:Security> header block
they SHOULD be prepended to existing elements. When a
new signature or encryption block is added it MUST
be prepended to any existing signature or encryption
blocks, or if none are present, it MUST be appended
as the last child of the <wsse:Security> header
block."
Replace the sentence starting on line 856 with:
"Finally, if a producer wishes to sign a message before
encryption, they must follow the Security header element
ordering guidelines for inserting signature and encryption
elements."
Replace the sentence starting on line 922 with:
"To add a signature to a <wsse:Security> header block,
a <ds:Signature> element conforming to the XML Signature
specification MUST be prepended to any existing signature
or encryption blocks of the <wsse:Security> header block,
in order to indicate to the receiver the correct order of
operations, according to the Security header element
ordering guidelines."
Replace the sentence starting on line 1105 with:
"When a producer or active intermediary encrypts portion(s)
of a SOAP message using XML Encryption they must prepend a
sub-element to any existing signature or encryption elements
according to the Security header element ordering guidelines."
Thanks,
Rich Levinson
-----Original Message-----
From: Levinson, Richard
Sent: Wednesday, January 14, 2004 1:45 PM
To: 'Chris Kaler'; Jerry Schwarz; Levinson, Richard;
wss@lists.oasis-open.org
Subject: RE: [wss] Issue 13, Lines 856-858 in Core, discussed at the call
today
Chris,
The proposal would have to based on whether or not
it is desirable to keep the rule 442-445. I am not
aware of what drove this to be included, except possibly
that it is more intuitive to see the tokens up front
rather than buried amongst the signatures, etc.
Proposal 1:
If it is desirable not to keep the rule, then I would
suggest removing lines 442-445 and changing the example
in ch 11 to have the xenc:EncryptedKey element and the
ds:Siganture element precede the wsu:Timestamp element
and the wsse:BinarySecurityToken element.
Proposal 2:
If it is desirable to keep the rule, I would suggest
that the wsse:Security header have 2 sections: a front "section" for
security tokens and timestamps and a back section for signature and
encryption blocks. New sigs and encr blocks would be prepended to the back
section and all other tokens and timestamps would be prepended to the front
section. The sections are conceptual only, it would be up to the
implementation to determine the boundary.
This would keep the example in Chapter 11 intact, and
435-445 and 922-925 could be modified as follows:
At line 435 insert something like:
"As elements (except signature blocks and encryption
blocks) are added to a <wsse:Security> header block
they SHOULD be prepended to existing elements. When a
new signature or encryption block is added it SHOULD
be prepended to any existing signature or encryption
blocks, or if none are present, it SHOULD be appended
as the last child of the <wsse:Security> header
block."
Lines 922-925 could be modified as follows:
"To add a signature to a <wsse:Security> header block,
a <ds:Signature> element conforming to the XML Signature
specification MUST be prepended to any existing signature
or encryption blocks of the <wsse:Security> header block,
in order to indicate to the receiver the correct order of
operations."
Conclusions:
Personally, I think the first proposal is technically easier to
understand and implement, but from a usability perspective for
people actually looking at the messages, then the second proposal might be
preferred.
It depends to a large degree as to what motivated the inclusion of lines
442-445 in the current spec.
Rich Levinson
At 10:07 AM 1/14/2004, Chris Kaler wrote:
>Jerry, you suggested that we all make strict proposals, so
>Jerry/Richard, what is the exact proposal?
I'm not proposing any changes. I was simply lending support to Richard's
observation.
I raised this issue a long time ago and believe the committee rejected my
concern at the time. The document as it stands now reflects that decision.
The two rules are contradictory, but since one is a MUST and the other is a
SHOULD it's clear that the MUST rule applies in cases where they conflict.
-----Original Message-----
From: Chris Kaler [mailto:ckaler@microsoft.com]
Sent: Wednesday, January 14, 2004 1:07 PM
To: Jerry Schwarz; Levinson, Richard; wss@lists.oasis-open.org
Subject: RE: [wss] Issue 13, Lines 856-858 in Core, discussed at the call
today
Jerry, you suggested that we all make strict proposals, so Jerry/Richard,
what is the exact proposal?
-----Original Message-----
From: Jerry Schwarz [mailto:jerry.schwarz@oracle.com]
Sent: Wednesday, January 14, 2004 10:06 AM
To: Levinson, Richard; Chris Kaler; wss@lists.oasis-open.org
Subject: RE: [wss] Issue 13, Lines 856-858 in Core, discussed at the call
today
I share this concern.
At 07:18 AM 1/14/2004, Levinson, Richard wrote:
>I am reluctant to stoke the coals on this, but based on the emails it
>appears the ordering rules in lines 435-445 are being considered the
>primary guideline and that lines 856-858 introduce some ambiguity that
>is desired to be removed.
>
>I have an additional concern that there is a greater ambiguity
introduced
>in lines 922-925 that state:
>
> "To add a signature to a <wsse:Security> header block,
> a <ds:Signature> element conforming to the XML Signature
> specification MUST be prepended to the existing content
> of the <wsse:Security> header block, in order to indicate
> to the receiver the correct order of operations."
>
>I am having trouble resolving this statement with the lines 442-445
>which state:
>
> "When a sub-element refers to a key carried in another
> sub-element (for example, a signature sub-element that
> refers to a binary security token sub-element that
> contains the X.509 certificate used for the signature),
> the key-bearing element SHOULD be ordered to precede the
> key-using Element:"
>
>It appears to me that the "MUST" in 922-925 would override the "SHOULD"
>in lines 442-445. In particular, lines 922-925 say the prepending is to
>existing content and does not exclude key-bearing elements.
>
>In order to resolve this I think it is necessary to decide if
>key-bearing elements "MUST" appear before key-referencing elements
>related to the same key, and that a little more explanatory text be
>included to make it clear when a Signature is prepended to the content
>vs being inserted before the appropriate key-bearing element.
>
>That all being said, maybe I am still missing something, but it appears
>to me that the text segments referenced above are in conflict.
>
> Rich Levinson
>
>-----Original Message-----
>From: Chris Kaler [mailto:ckaler@microsoft.com]
>Sent: Wednesday, January 14, 2004 9:10 AM
>To: wss@lists.oasis-open.org
>Subject: RE: [wss] Issue 13, Lines 856-858 in Core, discussed at the
call
>today
>
>
>Do we all agree then on removing it? Speak now...
>
>-----Original Message-----
>From: DeMartini, Thomas [mailto:Thomas.DeMartini@CONTENTGUARD.COM]
>Sent: Tuesday, January 13, 2004 3:42 PM
>To: wss@lists.oasis-open.org
>Subject: RE: [wss] Issue 13, Lines 856-858 in Core, discussed at the
call
>today
>
>This sounds great. I think if we go with this, the intention should be
>clear.
>
>Since the normative rules are laid out in section 5, this section can
be
>informative and we can replace both of the "SHOULDs" with lowercase
"would".
>This should address the concerns of those who would not like to see the
>normative material repeated as well as the concerns of those who would
like
>to have seen more clarifying text.
>
>&Thomas.
>
>So, with the replacements, it would look like this:
>
> Finally, if a producer wishes to sign a message before encryption,
> then following the ordering rules laid out in section 5, "Security
> Header", they would first prepend the signature element to the
> <wsse:Security> header, and then prepend the encryption element,
> resulting in a <wss:Security> header that has the encryption
element
> first, followed by the signature element:
>
> +------------------------+
> | <wsse:Security> header |
> +------------------------+
> | [encryption element] |
> | [signature element] |
> | : |
> | : |
> +------------------------+
>
> Likewise, if a producer wishes to sign a message after encryption,
> they would first prepend the encryption element to the
<wsse:Security>
> header, and then prepend the signature element. This will result
in a
> <wsse:Security> header that has the signature element first,
followed
> by the encryption element:
>
> +------------------------+
> | <wsse:Security> header |
> +------------------------+
> | [signature element] |
> | [encryption element] |
> | : |
> | : |
> +------------------------+
>
>
>-----Original Message-----
>From: Gene Thurston [mailto:gthurston@amberpoint.com]
>Sent: Tuesday, January 13, 2004 3:24 PM
>To: wss@lists.oasis-open.org
>Subject: RE: [wss] Issue 13, Lines 856-858 in Core, discussed at the
call
>today
>
>I guess I agree with Ron. When I read the text on lines on lines
856-858,
>it sounds like I have to do something "different". But, unless I do
not
>understand the gist of the conversation, I basically just need to
follow the
>standard rules as laid out in the paragraph starting on line 435.
>
>While Thomas' proposed replacement text is better than what is there
now,
>let me suggest another, more verbose, alternative:
>
> Finally, if a producer wishes to sign a message before encryption,
> then following the ordering rules laid out in section 5, "Security
> Header", they SHOULD first prepend the signature element to the
> <wsse:Security> header, and then prepend the encryption element,
> resulting in a <wss:Security> header that has the encryption
element
>
> first, followed by the signature element:
>
> +------------------------+
> | <wsse:Security> header |
> +------------------------+
> | [encryption element] |
> | [signature element] |
> | : |
> | : |
> +------------------------+
>
> Likewise, if a producer wishes to sign a message after encryption,
> they SHOULD first prepend the encryption element to the
<wsse:Security>
> header, and then prepend the signature element. This will result
in a
> <wsse:Security> header that has the signature element first,
followed
> by the encryption element:
>
> +------------------------+
> | <wsse:Security> header |
> +------------------------+
> | [signature element] |
> | [encryption element] |
> | : |
> | : |
> +------------------------+
>
>
>
>-----Original Message-----
>From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM]
>Sent: Tuesday, January 13, 2004 11:41 AM
>To: DeMartini, Thomas
>Cc: wss@lists.oasis-open.org
>Subject: Re: [wss] Issue 13, Lines 856-858 in Core, discussed at the
call
>today
>
>Thomas,
>
>I would prefer that the two existing sentences simply be removed. I
find
>
>them
>incongruous WRT the description of algorithms which preceeds them and,
>as was pointed out in the call, they can be read to mean that a
>producer somehow should
>change the order of existing signature and encryption elements in a
header.
>
>I think the text beginning at line 435 and also that of section 9.4
>define how signature and encryption elements must be ordered.
>
>That said, I think your text is an improvement over what's in the doc.
>
>Ron
>
>DeMartini, Thomas wrote:
>
> > I can understand the meaning of 856-858 when read in context, so I
> > don't think a change is absolutely necessary. However, I would like
to
>
> > offer the following text, which I think more clearly states the
> > intention of these lines:
> >
> >
> > "Finally, if a producer wishes to sign a message before encryption,
> > they SHOULD place the signature element after the encryption element
> > inside of the <wsse:Security> header. If a producer wishes to sign a
> > message after encryption, they SHOULD place the signature element
> > before the encryption element inside of the <wsse:Security> header."
> >
> > instead of
> >
> > "Finally, if a producer wishes to sign a message before encryption,
> > they SHOULD alter the order of the signature and encryption elements
> > inside of the <wsse:Security> header. This order of elements
> > represents order of operations."
> >
> > If there is disagreement with the proposed clarification, I am fine
> > with the existing text.
> >
> > &Thomas.
> >
>
>
>To unsubscribe from this mailing list (and be removed from the roster
of the
>OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgrou
p
>.php.
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster
of the
>OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgrou
p
>.php.
>
>
>To unsubscribe from this mailing list (and be removed from the roster
of the
>OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgrou
p
>.php.
>
>
>To unsubscribe from this mailing list (and be removed from the roster
of the
>OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgrou
p.php
>.
>
>To unsubscribe from this mailing list (and be removed from the roster
of
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgrou
p.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]