[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, ...? Yes, Issue 84 is about how the order of operations is specified and determined in WSS, in the cases where order matters. The Decryption Transform was proposed as a part of this solution. The issue is not transforms in general. Note that the X-C14N transform is required (effectively) and the STR Dereference Transform is endorsed in situations where it applies. If you believe there are other transforms that should be a part of WSS please raise a new issue on this subject. > 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? It is a widely agreed principle that security mechanisms should be as simple as they can be and still meet the requirements. More complex mechanisms are harder to analyze, more likely to have non-obvious properties and more likely to be incorrectly implemented. Historically far more security flaws have been found in complex schemes than simple ones and the relationship is clearly greater than linear. It has been my goal all along to eliminate features which have identified use, have fuzzy semantics or simply provide an alternative way of doing exactly the same thing. I am all for providing the maximum flexibility to implementers, but they will expect us to produce security implementations which interoperate and actually have the advertised security properties. Note that even SOAP limits flexibility in various ways, notably in the rules for processing headers. In the case of the DT, as I noted, it can still be used in payloads or attachments. However, it seems to be unnecessary and not useful in defining the order of operations in WSS. If we leave it in, processing will be more complex, implementations that much larger and the chances of unexpected "gotcha's" greater. Of couse I freely concede this is all based on my assertion that there is no sensible usecase which justifies the additional complexity. A single compelling usecase could completely alter my position. But just saying "somebody might use if for something, sometime" doesn't do it for me. > 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 > verification. Well this may be the intent, but the current core spec by no means makes this clear. In any event, it does not affect my argument about the possession of secrets. I see no value to having two distinct nodes possessing the same secret key that perform the same decryption operation twice. However, perhaps someone else can suggest a case where this is useful. [...] > 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. These comments further convince me that this is a can of worms we are wise not to open. Hal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]