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



Can you explain why we are singling out the decryption
transform for prohibition? What about other transforms;
the basic XPath transform, the foo-bar transform, the
decryption transform Mark II, schema-centric c14n, ...?

It would seem far more productive to come up with a
RECOMMENDED set of algorithms - transforms, c14n,
digest, signature, encryption, that SHOULD be supported
and SHOULD be used, and say nothing about anything else.

If people choose to use other algorithms then they know
that they cannot guarantee interop with wss-compliant
software. Prohibiting just one thing doesn't seem, to me,
to achieve anything.

For example, by not prohibiting RC2 and RSA/OAEP/MGF1/MD5
with non-standard parameters, are you implying that all
implementations must support them?

Merlin

r/hlockhar@bea.com/2003.07.29/12:02:24
>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
>decrypt-then-verify.
>
>Analysis:
>
>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
>WSS.
>
>Hal
>
>
>You may leave a Technical Committee at any time by visiting http://www.oasis-o
>pen.org/apps/org/workgroup/wss/members/leave_workgroup.php
>


-----------------------------------------------------------------------------
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.
http://www.baltimore.com



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