OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [wss] Issue 84 - Resolved

A further note on the subject.

There is an important distinction between use of the
decryption transform and insertion of an enc:ReferenceList
or enc:EncryptedKey in a WSS header. The enc:* elements in
a security header destructively decrypt the referenced
encrypted data, resulting in an unencrypted payload. The
decryption transform, on the other hand, performs
non-destructive decryption, solely for the purpose of

Consider this message:
      <Security actor/role="Eve">
        <EncryptedKey ... URI="#secret-payload" />
        <Signature ... URI="#body" ... />
      <Security actor/role="Bob">
        <EncryptedKey ... URI="#secret-payload" />
        <Signature ... URI="#body" ... />
    <Body Id="body">
      <EncryptedData Id="secret-payload" ... />

Here, the message is sent through Eve, the intermediary,
to Bob. Eve's job is to verify that the payload is signed;
however, in doing so, she decrypts the body. What she then
passes on to Bob will be in plaintext.

      <Security actor/role="Eve">
        <Signature ... URI="#body" ... Algorithm="&dcrpt;" ... />
      <Security actor/role="Bob">
        <EncryptedKey ... URI="#secret-payload" />
        <Signature ... URI="#body" ... />
    <Body Id="body">
      <EncryptedData Id="secret-payload" ... />

Here, Eve verifies the plaintext payload, but does not
damage the security. Bob's header could equally use the
decryption transform, as long as it is understood that
he should then use what was signed, rather than the
final state of the Body. Also worth noting is that if
Bob does not get the decryption transform, then there
may be subtle differences between what he and Eve verify,
depending on the interaction of the &c14n; embedded in
&dcrpt; and the recommended use of &exc-c14n; in wss.

[ Aside: Yes, I think this is a flaw in the specification
of &dcrpt;. In retrospect, I think it should have been
specified as &deref; is specified, with a C14nMethod
parameter. ]

Obviously Eve could make a copy of the document before
verification, then strip her header from the original before
passing it on; or, if she shares a secret with Bob, she
could re-encrypt parts of the document. However, all such
approaches have a non-trivial impact on intermediaries.


>Summary of conclusion: The Decryption Transform does not have any practical
>use in WSS and therefore should be prohibited.
>To review:
>Signatures can be combined and verified in any order without difficulty.
>However, when data is encrypted more than once or is signed before or after
>encryption the coresponding verification and/or decryptions must occur in
>the proper order or the signature verifications or decryption will fail.
>We have established that within a single security header order can always be
>unambigiously specified by prepending the encryption and signature elements
>to the existing header. Thus there is no need to support the Decryption
>Transform in this case. It has been suggested that the Decryption Transform
>is required in cases where distinct security headers specify overlapping
>operations. This analysis addresses that question.
>What is the Decryption Transform (DT)? It is actually quite a simple idea.
>Recall that data being signed can be passed through one or more
>transformations before the digest is calculated. This mechanism is used to
>implement C14N. The DT simply says: before you sign this stuff, decrypt it.
>In the absence of something like a SOAP header it provides a way to specify
>In general, ordering breaks into three cases: super-encrypt, encrypt & sign
>and sign & encrypt. Obviously, the DT is irrelevant to the first two. Let us
>consider sign & encrypt.
>Suppose an entity wants to encrypt data that has been signed (presumably by
>another entity, but that does not matter for our purposes.) It could prepend
>to the existing header, but suppose it believes that the decryption and
>verification will be performed by distinct SOAP Roles. For the sake of
>example, let us assume 4 roles: S, E, V, D, each of which is capable of
>performing the corresponding operation: sign, encrypt, verify and decrypt.
>The roles may reside within 2, 3 or 4 SOAP nodes.
>First suppose the DT is not used. The encryption element is put in the
>header addressed to D and the signature element is put in the header
>addressed to V. This presumes the configuration is like this:
>           S-E-D-V or SE-D-V (or perhaps S-E-DV assuming the DV node can
>sort out the order.)
>However, what if the actual path is like: S-E-V-D or SE-V-D. In general SOAP
>intermediaries are ignorant of routing. (Note the initial sender and
>ultimate receiver perforce always know their identities.) Here is where it
>is proposed that the DT might help. Suppose the E Role modifies the
>signature to include the DT pointing to the decryption in a different
>header. If the V Role gets the message first, it will begin processing the
>signature, see the DT and perform the decryption first, removing the
>encryption header. This does require the E Role to search all the other
>headers to find any overlapping signatures, but this does not seem a serious
>objection, since this already a tricky and rare case.
>However, suppose this approach is taken and the path actually is S-E-D-V.
>The D node gets the message and ignoring any signatures, does the decryption
>and removes the entire security header addressed to Role D. Then when the V
>Role tries to validate the signature, the DT will point to a non-existent
>header. I orginally thought that this would force the D Role to always
>search every header for possible signatures pointing to the decryption it
>performed, and remove the DT. I thought this would be quite onerous, given
>that it would have to be performed on every message with more than one
>header, even if the DT was never used!
>However, there is simpler approach. All we need to do is add a special rule
>that says if you are verifying a signature and you come across a DT that
>points to a non-existent encryption, assume it is already done and proceed
>with the verification. (If your assumption is wrong, the verify will fail.)
>All of this was an amusing exercise, but in fact quite useless! No Role can
>do decryption unless it knows the key. The D and V Roles have no way to
>route the messages to each other and get them back. Ignoring the fact that
>in general sharing a long term secret among multiple nodes is a bad security
>practice, if the V Role can do decryption, why bother to have the D Role at
>all? I can see no sensible usecase where it is not necessary to simply
>assume that the routing will have to allow the operations to be performed in
>the correct order. If not, the verification will fail and the routing will
>have to be corrected, the DT will not solve the problem.
>Note that this actually applies to all three cases: super-encrypt, encrypt &
>sign and sign & encrypt. Incorrect routing will cause either verification or
>decryption to fail (although failed decryption might be harder to detect)
>and there is nothing WSS can do about it.
>Therefore my conclusion is that we might as well prohibit the use of the DT
>in signatures in security headers, since they are never useful and require
>work to support. Of course if applications want to send signed objects in
>SOAP bodies or attachments, that is their business and outside of the scope
>You may leave a Technical Committee at any time by visiting http://www.oasis-o

The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]