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.
Regards
Carl
----- Original Message -----
From: "Bob Wyman" <>
To: "'Kon Wilms'" <>; "'Art Botterell'"
<>
Cc: <>
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.
>
>
