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] Fwd: Re: [emergency-comment] RE: Content ( wasRE: [emergency-comment] RE: [CAP] RE: CAP-list digest...)


Hi Folks,

While you may find this astonishing Art, I don't. Allen has been 
voicing this sort of objection all along, which is his right, and 
being chair does not require agreement with the committee's 
workproducts, nor should it. That is the purpose of providing for a 
Minority Report. Allen speaks for his constituency reliably and well, 
as you do for yours. The point is that we have wide diversity which 
reflects the overall context in which CAP must operate. It would be 
more effective, in terms of securing an approval vote if the chair 
supported the standard, but he doesn't, and can't according to his 
viewpoint. This is fairly unusual, but, as I said, not unexpected.

My own viewpoint is, however, that encouraging this kind of public 
comment during the vote is not helpful, especially when it is being 
brought forward after the public comment period by someone who is not 
in a position to vote and who is hawking his own services, however 
well informed and however much weight one cares to give to this 
person's opinions.

We need to take this in stride, and proceed as best we can. At least 
this is all done up front and out in the clear light of day, so to 
speak, and that is much better than having large players manipulating 
the work and outcomes from behind the scenes, or simply buying up the 
smaller, actively engaged companies with the biggest stake in the new 
standards and technologies in order to prevent a standard from moving 
forward, which is something I have seen happen in other contexts. 
Thanks be that I have not seen this happen in OASIS.

My own position is that this work is just too important to either 
waste time insisting that one's own predilections or that of one's 
constituency carry the day and require that the work be delayed until 
those predilections are satisfied nor that a majority, whether simply 
51 percent or 75 percent or more imply or suggest that the minority 
muzzle itself at any time, no matter whether a vote is underway or 
not.

Please note, one and all, that no one is capable of saying what 
EXACTLY is RIGHT for all concerned the first or twenty-third time an 
issue is addressed, because conditions change as do alliances so we 
can, at best, seek the widest consensus we can at any given time. 
Once we have CAP approved, either this time, next or some time after 
that, it is of overriding importance that we get it established and 
then maintain and adapt it as we are prompted by practice over time. 
Hopefully it will be available the next time we really need it, 
however imperfect it may be.

Ciao,
Rex

At 6:01 PM -0800 3/23/04, Art Botterell wrote:
>Here our Chair tells a public list that "For anyone trying to 
>support CAP messages from various sources, it is impossible, in the 
>current state of CAP, to do so in any kind of standard method"  and 
>"Differently != Standard. Basically, CAP is not a protocol."
>
>Aside from the fact that this statement is demonstrably incorrect, 
>for that sort of negative publicity about the TCs work product to 
>issue from our own Chair, right in the middle of balloting, is 
>nothing short of astonishing to me.
>
>- Art
>
>>From: "R. Allen Wyke" <emergency-tc@earthlink.net>
>>Subject: Re: [emergency-comment] RE: Content ( was RE:
>>   [emergency-comment] RE: [CAP] RE:   CAP-list digest...)
>>To: cap-list@incident.com
>>Date: Tue, 23 Mar 2004 11:20:06 -0500
>>
>>
>>Hate to say it, but Bob is right. For anyone trying to support CAP 
>>messages from various sources, it is impossible, in the current 
>>state of CAP, to do so in any kind of standard method. You have to 
>>build a bunch of one-off connectors to handle the different 
>>implementations. We "stood silent" on so much, that people are all 
>>using it differently. While that may seem like a good thing to some 
>>people, it is not. Differently != Standard. Basically, CAP is not a 
>>protocol. It is a grouping of elements of like purpose to reflect a 
>>format.
>>
>>Allen
>>
>>On Mar 5, 2004, at 8:30 PM, Bob Wyman wrote:
>>
>>>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
>>--
>>R. Allen Wyke
>>Chair, OASIS Emergency Management TC
>>emergency-tc@earthlink.net
>>_______________________________________________
>>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.
>
>
>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.


-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request


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