It
seems equally absurd to me to merely “suggest” use of anything
(WS-security in
this case) in a normative section of a specification.
Either
we recommend or we don’t. If we do not want to mandate we use lowercase
“recommend”.
Devoting a normative section to merely “suggest” something is silly.
In that case let
us just stay silent and kill the entire section.
WS-Security It is a
stable and well adopted OASIS standard specification. I see
nothing wrong with recommending the use of WS-Security, as long as we
do not mandate it via RFC 2119 language (viz. uppercase RECOMMEND).
Alex
already conveyed his willingness to accept the amendment proposed.
Regards,
Prasad
From: Ronald.Ten-Hove@Sun.COM
[mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Thursday, July 13, 2006 1:47 PM
To: Danny van der Rijn
Cc: Prasad Yendluri;
Alex
Yiu; wsbpeltc
Subject: Re: [wsbpel] Issue 291 - Proposal for vote
The whole area of security is far too broad
and
deep for us
to give it a proper treatment in three paragraphs. It seems absurd to
recommend
(or RECOMMEND) WS-Security, when it:
a) isn't applicable to most binding types
b) isn't sufficient to address the general topic of security
c) has no connection at all with WS-BPEL 2.0.
If WS-BPEL had some sort of security model,
and
it
had some
sort of connection to WS-Security, then I could see including it as a
recommendation. Is there such a model and connection, and I missed them
somehow?
The way chapter 16 currently reads, it sounds like we (the TC) are
providing a
strong endorsement of WS-Security. Indeed, I wouldn't be surprised if
the
reader of chapter 16 took away an impression that WS-Security will
address all
security concerns except denial-of-service attacks. For this reason, I
was
quite happy with Alex's "softening" of the wording in chapter 16,
using "suggested" in place of "recommended".
Danny van der Rijn wrote:
I'm not saying we should force everyone to use
WS-Security. That's not what "strongly RECOMMENDED" or
"SHOULD" mean. To be clear, I am advocating, and have always
advocated that we leave the wording as is.
Prasad Yendluri wrote:
Danny,
It seems you are actually -1'ng Alex's original proposal and not my
amendment
as you are calling for using the RFC / uppercase wording. I am not
convinced
that we should force everyone to use WS-Security to use BPEL (I think
that
would be result). However that is the status quo. So is your position
then to keep the current RFC language in that section ?
Regards,
Prasad
Danny van der Rijn wrote:
-1. We need to use RFC language, uppercase.
Prasad Yendluri wrote:
Hi Alex,
If we are including lower case "should" in the text of this section
anyway, I don't see an issue with use of lower case recommended, like
"it is recommended" or "it is highly recommended".
"strongly suggested" seems like an oxymoron to me :)
Section 2 of the spec (Notational Conventions), clearly shows the
normative
keywords to be upper case (and referes to RFC2119). If needed, we could
add a
sentence to state that 'only upper case form of these keywords are
normative'
in that section. Going out of way to change lower case recommended to
suggested is an overkill IMO.
Best regards,
Prasad
------- Original Message --------
Issue 291: Normative wordings in chapter 16 "Security Consideration"
Proposal for vote: (changes highlighted in green)
============================
Since messages can be modified or forged, it is
strongly suggested that business process implementations use
WS-Security to ensure messages have not been modified or forged while
in
transit or while residing at destinations. Similarly, invalid or
expired
messages could be re-used or message headers not specifically
associated with
the specific message could be referenced. Consequently, when using
WS-Security,
signatures should include the semantically significant
headers and the message body (as well as any other relevant data) so
that they
cannot be independently separated and re-used.
Messaging protocols used to
communicate among business processes are subject to various forms of
replay
attacks. In addition to the mechanisms listed above, messages should include a message timestamp (as described
in WS-Security) within the signature. Recipients can use the timestamp
information to cache the most recent messages for a business process
and detect
duplicate transmissions and prevent potential replay attacks.
It should also be noted that
business process implementations are subject to various forms of
denial-of-service
attacks. Implementers of business process execution systems compliant
with this
specification should take this into account.
============================