OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[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]