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

Interesting discussion. I would like to add that are also a number of Internet standards (IETF) that deal with encryption and are used for encrypting messages, such as e-mail. This includes the work of the IETF S/MIME working group, specifically the S/MIME electronic mail security protocol that is widely implemented in commercial mail agents. If you want something a bit more low-level, I would also check out the work of the IPSEC group, specifically RFC 3686 - Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP). This standard incorporates the NIST standard that defines five modes of operation for AES and other FIPS approved block ciphers [MODES].
As Bob suggests, rather than the EM TC define a new method of encryption, I would opt for a statement of best practices for encrypting a CAP message using existing, well known industry standards.
----- Original Message -----
From: "Bob Wyman" <bob@wyman.us>
To: "'Kon Wilms'" <kon@datacast.biz>; "'Art Botterell'" <acb@incident.com>
Cc: <emergency@lists.oasis-open.org>
Sent: Tuesday, January 25, 2005 12:21 AM
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

> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.

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