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, ...?

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

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.


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