[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] CAP and Signatures/Encryption
Kon Wilms wrote: > For certain network delivery mechanisms, other XML encryption > mechanisms are the *only* way to secure the data. I think the key to your comment is the phrase "certain network delivery mechanisms." You appear to be addressing issues concerning the channel through which CAP messages pass rather than the issue of the format of a CAP message itself. We should be careful to distinguish between encryption which is provided within the body of a CAP message and encryption which is provided by the channel through which the CAP message passes. i.e. are we talking about an encrypted message passing through a potentially unencrypted channel or a potentially unencrypted message passing through an encrypted channel. My proposal, since it addresses in-message encryption, is intended to address the requirement for channel independent encryption -- providing for encryption even when the channel or "delivery mechanisms" may not have encryption capabilities. Given that CAP is simply a format, not a protocol, this is, I think, appropriate. Channel-based encryption is appropriately dealt with in other documents. A significant reason for writing standards is to limit implementation options in favor of commonality of implementation and thus interoperability. A standard that doesn't provide such limitations can hardly be called a "standard" but is probably more appropriately referred to as a cookbook or application note. If the CAP standard was to include words which allowed for an open ended set of encryption mechanisms, then it would be hard to see how the goals of interoperability would be accomplished. We would find that message producers would be able to pick from a large number of mutually incompatible options and message receivers would be forced to implement an equally large number of encryption mechanisms in order to ensure that they could receive and process all possible CAP messages. The requirement to implement such a large or open-ended number of mechanisms will, inevitably, result in CAP users creating profiles external to the standard which limit the range of implementation choices in specific networks. In other words, individual networks of CAP message producers and consumers will have to finish for themselves the work not done by the CAP Standards committee. The result of that, of course, will be inter-network incompatibility -- precisely what standards are intended to prevent. My personal guess is that while there will be a very great requirement for CAP messages to be signed, there will be much less of a requirement to provide encryption within the body of a CAP message. Frankly, if it wasn't for the text in the CAP specification that erroneously claims that CAP *provides* a facility for encryption, I would have argued that while signatures should be handled within CAP, encryption should be left to the channel. Thus, I would have argued that CAP should not provide a facility for encryption. However, given that the claim is there and given that the group has refused on repeated occasions to remove the claim, I think we need to do the best we can. That is: Adopt what appears to be the industry standard, W3C-blessed, mechanism for in-message encryption for use in those cases when channel-based encryption is not the most appropriate or workable solution. I would appreciate it greatly if you could provide a scenario that describes a specific, reasonably common case in which an alternative to the W3C standards for in-message encryption would be preferred. bob wyman
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]