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: Comments on Encrypted Header Proposal


Thoughts and discussions arising from the Encrypted Header proposal have touched on many aspects of Web Services, including the implications of diverse specifications for each other, the design of distributed systems infrastructure, the goals of schema checking and the composing of distinct services. I will confine my comments narrowly to the proposal at this time. However my response has been delayed longer than it should have been. I apologize for any inconvenience that this causes.

Part of the proposal reads:
"The SOAP processing model requires that a SOAP processor MUST examine all mandatory headers targeted at the role of the processor and determine that they can be understood before it can commence processing any of the headers"

What SOAP 1.1 actually says is:

"If a header element is tagged with a SOAP mustUnderstand attribute with a value of "1", the recipient of that header entry either MUST obey the semantics (as conveyed by the fully qualified name of the element) and process correctly to those semantics, or MUST fail processing the message (see section 4.4)."

SOAP 1.2 says:
"Therefore, for every mandatory SOAP header block targeted to a node, that node MUST either process the header block or not process the SOAP message at all, and instead generate a fault (see 2.6 Processing SOAP Messages and 5.4 SOAP Fault)."

As far as I can see, an implementation which simply processed each header in some order and if it found one that could not process, generated a fault, ceased processing the message and did not pass the message to the application would comply with both of these. I do not interpret either of them as saying that all intermediate results must be rolled back to the point before the message was received. I feel confident that the mustUnderstand feature was not intended to mandate some kind of atomic, all or nothing behavior on the part of infrastructure services. I know its purpose is to facilitate future evolution primarily in the normal case when the default value of "False" is in force.

It seems clear at least that the relationship between the application and infrastructure services should not be atomic. Aside from the cost of implementation (paid over every routine interaction) there are benefits in partitioning the error models. For example, in TCP a message that generates an HTTP error can still update a window counter kept at a lower layer. To pick a WSS example, a message that failed processing might bear a Token that was referenced in a future message, eliminating the need to retransmit it.

Therefore as far as I can see, the desire to scan the headers for the mustUnderstand attribute is at best an optimization. But is a standard rule of thumb that you don't optimize error cases. The reason is simple. In a debugged, production system (where performance matters) the ratio of errors to total messages will be 3 or 4 orders of magnitude at least. There is not much benefit even if a gain is found.

Further, I believe that the case of encrypted headers will itself be rare. In fact, assuming that headers are generated and consumed by infrastructure elements, such as routing, reliability and security, I have not been able to think of a plausible usecase for encryption of a header. I can see lots of reasons for integrity protection, but few for confidentiality. In most cases, an infrastructure header will in effect be known plaintext, so encrypting it would be positively undesirable.

Also notice that the only benefit will be in abandoning the processing immediately when an unsupported mandatory header is found. Once it is discovered that the message can be processed, it is necessary to perform all the cryptographic operations specified in the security header in the correct sequence, because of the possibility of overlapping signatures or encryptions.

The proposal in essence is to encrypt the entire header, wrap it in a new element and decorate that with plaintext copies of the actor(role) and mustUndertand attributes. But this does not meet the stated requirement. As Corinna Witt (BEA) pointed out to me, in order to decide if you can process a header, mandatory or not, you must know the name of the header (outermost) element. Under this proposal you must decrypt the message anyway to find this out. Thus at the most basic level the proposal does not meet its own requirement.

Perhaps this could be rectified also by echoing the name of the header in the surrounding wrapper. However this raises new questions. Suppose it is a requirement to keep the name of the header secret? Since I have not been able to think of any encryption uescases, I do not feel confident asserting this will never be the case. Then this scheme will not be allowed.

Meanwhile we have to implement a complex scheme with many unspecified details. Now we have two processing models, one for body and one for headers. Actually since this scheme is not mandatory, three models, since headers can be done two ways. We also  have duplicated information (header name, actor/role & mustUnderstand). What if the copies differ? Is it an error or does one control?

This does not seem worth it to optimize a rare case.

Perhaps there is a case we should worry about. What if a SOAP node fails to detect a header directed to its role and marked mandatory, because it is decrypted by a role that operates later on as by virtue of the order the message is routed. This might cause it to violate the rules quoted above.

One view is that since SOAP explicitly says there is no way to assure or determine the order a message will reach a node supporting a given role (except for the ultimate recipient) that this problem does not need to be addressed. Certainly covering all the cases would be difficult, but perhaps we can prevent a few common errors. 

For example, we could create a rule that the node supporting the ultimate recipient role generate a fault if an unprocessed security header is left in the message. It might also be possible to add a rule saying that a sender must never encrypt a header directed at a different role from the security header controlling the encryption. Correspondingly the receiver would be required to generate a fault if such a case was detected in a received message. However, perhaps some would view the latter rule (or even both of them) as unduly restrictive to MEP choice.

It is entirely possible that I have failed to understand some aspects of the proposal or properly interpret the requirements. I hope that others will be able to clarify my thinking. For me the most useful information would be for someone to give an example of a receiver's processing model, showing how the steps would be facilitated by new features.

I will add a final thought on schema checking. Different alternative approaches are discussed in the proposal in terms of whether or not the final (encrypted) form of the message was schema valid. I think it is important to keep in mind the purpose behind schema checking. It is to determine if the thing you are processing is at least roughly the sort of object you expect. I don't see the point of having every schema point here and there and say there might be encrypted data here, but not really checking if after decryption, you got what you expected. There is no real benefit in terms of catching errors early.

Some people believe the XML Encryption WG should have solved the problem of encrypted data not being schema valid. Since they did not, perhaps XML or Schema or SOAP should adopt the formal or informal rule that encrypted data is a special case and is valid anywhere. That would be no worse than current solutions and would eliminate the need to do it individually in each spec. In any case I do not think this is a problem WSS is responsible for solving.

Hal


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