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: [emergency-comment] Schema constraint on digital signatures


Is this a formal comment requesting that this requirement be added to 
the CAPv1.1-IPAWS Profile above and beyond what Art submitted?

This is not a reaction, just a request for clarification.

Cheers,
Rex

At 3:01 PM -0400 3/17/09, Billy Pitts wrote:
>I support your effort Art.
>I was also thinking about the digital signature implications of CMAS,
>because as you know the Trust Model for authentication (under Section 8.1.1)
>requires dual digital signatures:
>
>* Countersigned - A public alert and warning message must be 
>digitally signed by two
>credentialed personnel for acceptance into the CMAS.
>
>
>On Mar 17, 2009, at 2:39 PM, Art Botterell wrote:
>
>>In the past week it's come to my attention that the XML schema in 
>>the OASIS CAP 1.1 specification may not adequately support the use 
>>of digital signatures as provided in Section 3.3.2.1 of that same 
>>specification document.
>>
>>Digital signatures are a well-established mechanism for ensuring 
>>the authenticity of XML messages in complex "system of systems" 
>>operating environments such as IPAWS. The original intent that 
>>support for digital signatures be mandatory is made clear in 
>>Section 3.3.2.1 of the OASIS CAP 1.1 specification, which reads in 
>>part "Processors MUST NOT reject a CAP Alert Message containing 
>>such a signature simply because they are not capable of verifying 
>>it; they MUST continue processing and MAY inform the user of their 
>>failure to validate the signature."
>>
>>Ideally this oversight could be addressed in the next version of 
>>the CAP specification. However, in view of the stated intent of 
>>FEMA to proceed with IPAWS implementations based on the IPAWS 
>>Profile, this problem gains greater urgency.
>>
>>Therefore I would respectfully suggest that the IPAWS Profile 
>>include a profile-specific version of the XML Schema that provides 
>>any needed support for inclusion of digital signatures as specified 
>>in the CAP 1.1 specification.
>>
>>
>>
>>Art Botterell, Manager
>>Community Warning System
>>Contra Costa County Office of the Sheriff
>>50 Glacier Drive
>>Martinez, California 94553
>>(925) 313-9603
>>fax (925) 646-1120
>>
>>
>>--
>>This publicly archived list offers a means to provide input to the
>>OASIS Emergency Management TC.
>>
>>In order to verify user consent to the Feedback License terms and
>>to minimize spam in the list archive, subscription is required
>>before posting.
>>
>>Subscribe: 
>><mailto:emergency-comment-subscribe@lists.oasis-open.org>emergency-comment-subscribe@lists.oasis-open.org
>>Unsubscribe: 
>><mailto:emergency-comment-unsubscribe@lists.oasis-open.org>emergency-comment-unsubscribe@lists.oasis-open.org
>>List help: 
>><mailto:emergency-comment-help@lists.oasis-open.org>emergency-comment-help@lists.oasis-open.org
>>List archive: 
>><http://lists.oasis-open.org/archives/emergency-comment/>http://lists.oasis-open.org/archives/emergency-comment/
>>Feedback License: 
>><http://www.oasis-open.org/who/ipr/feedback_license.pdf>http://www.oasis-open.org/who/ipr/feedback_license.pdf
>>List Guidelines: 
>><http://www.oasis-open.org/maillists/guidelines.php>http://www.oasis-open.org/maillists/guidelines.php
>>Committee: 
>><http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency>http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670


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