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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-comment message

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


Subject: RE: Content ( was RE: [emergency-comment] RE: [CAP] RE: CAP-list digest...)


Art Botterell wrote:
>>At 5:29 PM -0500 3/5/04, Bob Wyman wrote:
>>  ... the CAP specification *DOES NOT* tell me where to put them if
I
>>am trying to pass a CAP message without SOAP.
> That's right, it doesn't.... And after discussing this very 
> question at some length a number of months ago, the members 
> of the TC decided that it lay outside the scope of the CAP 
> spec and more properly in the scope of specifications for 
> a particular transport context.
	So, what you're saying is that CAP *does not* provide any
mechanism or facility for doing authentication of messages in a manner
which is independent of the transport mechanism. If you want signed
messages, you must use a transport, like SOAP, that supports signed
messages. Thus, the odd mention of WSSE in the specification is really
just a non-normative hint to users of SOAP which reminds them that
they can use SOAP to transport and sign CAP bodies. CAP itself,
doesn't deal with the issue of signing CAP messages nor does it deal
with encryption.
	This sounds a bit odd since in Section 1.1 of the CAP
specification it is explicitly stated that CAP capabilities include:
"Facility for digital encryption and signature capability". In fact,
it appears that encryption and signatures can only be had by using
facilities that are *not* provided by CAP. If anything, the most CAP
does is avoid interference with these non-CAP facilities. Given this,
it would seem to make sense to remove the statements in Section 1.1
that promise encryption and signatures... CAP doesn't deliver on these
promises.
	Am I reading this correctly?

> But in the meantime I've yet to hear of any actual 
> attempt at implementation that's failed for lack of 
> this feature, and there have been a number of implementations,
>  so I think it might be premature to cast the discussion
> in catastrophic tones.
	As I've mentioned in earlier messages, I am prepared to
provide an Internet-Scale facility for the collection of and
distribution of CAP messages. However, given that the content of CAP
messages is very sensitive (i.e. it involves folk's lives), I'm
finding it hard to understand how such a facility can be provided
*without* a mechanism for authenticating messages and providing for
non-repudiation. The issue is not one of technology -- it relates to
ethics, law, risk management, and the methods of hackers and
terrorists...
	If the "actual" author of a message can't be reliably
established (i.e. via signatures), then whoever was "last in the
chain" for handling the message ends up being responsible for its
content... Given that we're an intermediary, we would end up "owning"
every message that passes through us. We would also become an obvious
target for anyone wanting to insert forged data into the system. That
is not a good thing.
	Authentication is not only useful to the end users of the
system. It is also useful to the intermediaries since authentication
allows them to wave off responsibility for the content of messages
passed and it makes them a less useful focal point for malicious
attacks. (Note: Pay attention to this last point... The network, the
channel, is *less likely to be attacked* if signatures are
supported...)
	In Section 1.2 of the CAP spec it is indicated that CAP was at
least partially motivated by a desire to deliver on the recommendation
of the National Science and Technology Council which urged that "a
standard method should be developed to collect and *relay*
instantaneously and automatically all types of hazard warnings ...
into a wide variety of dissemination systems". The key to my issue is
the word "relay." For a relay to be deployable with this sort of data,
there *must* be mechanisms for establishing the true source of CAP
messages in a manner which cannot be repudiated.

> Nonetheless, it sounds like what you're saying boils down 
> to a suggestion that CAP would be stronger if it provided 
> an explicit internal mechanism for digital signatures.  
> That's certainly a question the TC could revisit.
	If CAP is to provide a transport-mechanism-independent format
for Alerts and also provide for "encryption and signatures" then it
*MUST* explicitly deal with the question of authentication,
encryption, etc. in a channel independent manner. Thus, I'm not
suggesting this as a way to make CAP "stronger" (even though that
would be the case) rather, I'm suggesting that the professed goals of
CAP can only be achieved by taking this step.

		bob wyman

(Note: This message is cc'd to emergency-comment not as a solicitation
for input but rather as a comment. I understand that comments will
travel over other channels...)

-----Original Message-----
From: cap-list-admin@incident.com [mailto:cap-list-admin@incident.com]
On Behalf Of Art Botterell
Sent: Friday, March 05, 2004 6:26 PM
To: cap-list@incident.com
Subject: RE: Content ( was RE: [emergency-comment] RE: [CAP] RE:
CAP-list digest...)


At 5:29 PM -0500 3/5/04, Bob Wyman wrote:
>  ... the CAP specification *DOES NOT* tell me where to put them if I
>am trying to
>pass a CAP message without SOAP.

That's right, it doesn't.  Again I'll point out that CAP does not 
specify any particular transport arrangement.  And after discussing 
this very question at some length a number of months ago, the members 
of the TC decided that it lay outside the scope of the CAP spec and 
more properly in the scope of specifications for a particular 
transport context.

In the SOAP case, for example, the security design was the output of 
a standards process.   In the DMIS case it was a "designer's choice" 
(albeit still standards-based and open) by that network's 
implementer... as was also the case for the MyStateUSA and Hormann 
America implementations and the earlier ComCARE/Orillion deployments.

Nonetheless, it sounds like what you're saying boils down to a 
suggestion that CAP would be stronger if it provided an explicit 
internal mechanism for digital signatures.  That's certainly a 
question the TC could revisit.

But in the meantime I've yet to hear of any actual attempt at 
implementation that's failed for lack of this feature, and there have 
been a number of implementations, so I think it might be premature to 
cast the discussion in catastrophic tones.

- Art
_______________________________________________
CAP-list mailing list
CAP-list@incident.com
http://www.incident.com/mailman/listinfo/cap-list

This list is not for announcements, advertising or advocacy of any
particular program or product other than the CAP itself.



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