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 1.2 Vote for CS and OS ??

Oops, forgot to note that I'll vote for approval as a Committee 
Specification. And push to get the 2.0 efforts moving forward more 

Note: it has been possible to do all this since EDXL-DE was first 
approved, and it hasn't turned into a nightmare yet. The difference is 
that now people are just beginning to understand systems of systems and 
networks of networks for real and there are going to be many bumps in 
the road as move toward a robust emergency messaging capability.

I'd be happier if we had funding to create the kind of guidance 
documentation we really need, and keep it up to date on a regular basis.

Hint hint.


Rex Brooks wrote:
> Hi Everyone,
> Just got off the phone.
> Some questions I can answer, some I can only give my opinion. Number 3 
> is looooonnnnnnggggggg, so read the short summary at the start.
> 1. My opinion: It's better to do a work-around. I don't want to spend 
> any more time on CAP v1.anything. This is just my opinion. Even though 
> I don't want to chair or, perhaps, do much more than monitor the 
> efforts and add my $0.02, we need to be getting CAP 2.0 and EDXL-DE 
> 2.0 moving forward in lock-step.
> 2. My understanding is that ASN.1 is a binary encoding, so adding a 
> new element, i.e. <avoid> , breaks previous versions, therefore they 
> consider it  a major (new-numeral) version. I spoke with Alessandro in 
> December, and got the impression that there was a way to treat it more 
> like an errata that did not actually require a new-numeral version, 
> but I didn't have time for it to sink in. In any event, whether or not 
> they choose to issue a new version of the ASN.1 representation, that's 
> their business. We should definitely get into synch with them as we go 
> forward with CAP 2.0.
> 3. My opinion: it depends on what you mean by actual. I don't know if 
> all or most of the actual implementations will have a problem with the 
> two <any> tags in CAP v1.2 and the two <any> tags in EDXL-DE v1.0.
> Note: I expect Gary to give you the much shorter version and Dave to 
> give you the much longer version.
> Summary As of now it is possible to use EDXL-DE 1.0 to wrap a CAP v1.2 
> message and sign and encrypt both the DE wrapper and the CAP payload 
> putting one namespaced object inside another of the same 
> namespace=Hell on Wheels. Whether you consider this actual is up to you.
> To do this one would use the "other" subelement of the EDXL-DE 
> <contentObject> element expressed as part of the <xsd:complexType 
> name="contentObjectType> (shown below):
> <xsd:complexType name="contentObjectType">
>            <xsd:sequence>
>              <xsd:element name="contentDescription" type="xsd:string" 
> minOccurs="0"/>
>                 <xsd:element name="contentKeyword" 
> type="valueListType" minOccurs="0" maxOccurs="unbounded"/>
>                 <xsd:element name="incidentID" type="xsd:string" 
> minOccurs="0"/>
>                 <xsd:element name="incidentDescription" 
> type="xsd:string" minOccurs="0"/>
>                 <xsd:element name="originatorRole" 
> type="valueListType" minOccurs="0" maxOccurs="unbounded"/>
>                 <xsd:element name="consumerRole" type="valueListType" 
> minOccurs="0" maxOccurs="unbounded"/>
>                 <xsd:element name="confidentiality" type="xsd:string" 
> minOccurs="0"/>
>                           <xsd:choice>
>                    <xsd:element name="nonXMLContent" 
> type="nonXMLContentType"/>
>                    <xsd:element name="xmlContent" type="xmlContentType"/>
>              </xsd:choice>
>            _*<xsd:any namespace="##other" processContents="lax" 
> minOccurs="0" maxOccurs="unbounded" />*_
>            </xsd:sequence>
>      </xsd:complexType>
> In EDXL-DE there is also a separate <xsd:complexType 
> name="anyXMLType"> that also uses the "##other" namespace:
> <xsd:complexType name="anyXMLType">
>            <xsd:sequence>
>              _*<xsd:any namespace="##other" processContents="lax" 
> maxOccurs="unbounded"/>*_
>            </xsd:sequence>
>            <xsd:anyAttribute namespace="##other" processContents="lax"/>
>      </xsd:complexType>
> You can see the examples in the EDXL-DE v1.0 Specification, which 
> actually cite the
> _*"http://www.w3.org/2000/09/xmldsig#"*_ (signature) and _*
> "http://www.w3.org/2001/04/xmlenc#"; *_(ecryption) namespaces,
> which are, in my opinion,  the most likely "actual" uses of the 
> EDXL-DE <any> tags
> Now, it is also possible for the CAP v1.2 message payload to be both 
> digitally signed and encrypted using the CAP v1.2 <any> tags:
>        _*<any minOccurs = "0" maxOccurs = "unbounded" namespace = 
> "http://www.w3.org/2000/09/xmldsig#"; processContents = "lax"/>
>        <any minOccurs = "0" namespace = 
> "http://www.w3.org/2000/09/xmlenc#"; processContents = "lax"/>*_ (Note 
> different dates between EDXL-DE v1.0 "xmlenc#" and CAP v1.2 "xmlenc#")
> This is the case where one namespaced object is wrapped by another 
> object of the same namespace (except maybe it slips through due to the 
> slight difference in dates in the namespace for encryption--but I 
> wouldn't bet the farm on it)
> Because both CAP v1.2 <any>s are optional, we can just say that 
> problems are implementation-specific, e.g. not our concern. However, 
> that's not really feasible when our goal is to encourage adoption and 
> listen to the needs of our constituencies. So the problem with DM-OPEN 
> needs to be considered, hence if the workaround works, I'd just go 
> with that and suggest that DM-OPEN and other major implementors USE 
> EDXL-DE and not use the optional signatures or encryption in the CAP 
> message itself.
> However, the real problem, again this is just my opinion, is the fact 
> that we allow the following to be possible:
> Any standalone CAP message that you encrypt requires that all 
> nodes/endpoints to which it is sent for redistribution to have the key 
> to decrypt it or else it can't be redistributed with any assurance 
> that it is genuine. I believe that allowing attachments like images 
> with recognizable people or objects like Driver's Licenses to be 
> viewed by the public, even inadvertently, is not acceptable, so these 
> need to be encryptable, and can be, using EDXL-DE, but having that 
> capability for a standalone CAP v1.2 message is debateable.
> We can't write a specfication for good common sense.
> Cheers,
> Rex
> McGarry, Donald P. wrote:
>> My questions to the TC are this:
>> 1. Is it better for DM-OPEN to just implement the workaround or for 
>> us to make changes to the 1.2 spec?
>> 2. What are the specific technical concerns from ITU?
>> 3. Regarding concerns with regards to non-repudiation, authorization 
>> and authentication: what are the specific technical shortfalls in 
>> this revision as it relates to actual implementations of a system?  
>> Are those with concerns ok with tabling them until 2.0?
>> -Don
>> Office: 315-838-2669
>> Cell: 315-383-1197
>> dmcgarry@mitre.org
>> -----Original Message-----
>> From: Elysa Jones [mailto:ejones@warningsystems.com] Sent: Wednesday, 
>> February 10, 2010 2:15 PM
>> To: emergency@lists.oasis-open.org
>> Subject: [emergency] CAP 1.2 Vote for CS and OS ??
>> Friends,
>> As you probably know there is a ballot open now for EM-TC members to 
>> vote for the CAP 1.2 Committee Specification and to ask OASIS Staff 
>> to begin the OASIS-wide vote to be held to promote this work to an 
>> OASIS Standard.  These are two separate ballots open now on our site.
>> As you may also know, Gary Ham ran into some problems with digital 
>> signatures and their use in OPEN using JAXB and the Oracle 10G SOA 
>> Suite.  There have been discussion on the list in the past few days 
>> about the issue.  Gary has stated the problem he (and Neil) has seen 
>> for which he has found an available work around.  Don McGary and 
>> Jocob Westfall have provided proof that the XML is correct and 
>> validates.  The three companies who made statements of use for CAP
>> 1.2 have not seen a problem with their implementations.
>> So, here we are needing to get a vote approved to allow CAP 1.2 to go 
>> forward - or not.  I wanted to give a brief history of this work and 
>> begin any discussion the members have for discussion on this list.
>> The CAP 1.2 was required for the IPAWS profile to accommodate the 
>> CMAS program need for an "avoid" response type.  DMOPEN is the 
>> program that will be used to exchange CAP messages for CMAS as well 
>> as EAS and HazCollect specifically for IPAWS.
>> Our ITU friends have expressed concern with CAP 1.2 as they have 
>> members that see this as a major released and not a minor.  Update 
>> for CAP 1.2 is not likely right away from that community.
>> Our members that have expressed concern over CAP 1.2 with regard to 
>> non-repudiation, authorization and authentication anticipate these to 
>> be covered in the CAP 2.0 spec that will be aligned with the DE 2.0.
>> Please post any concerns you have about voting on the list so we can 
>> discuss them openly.  If you do not have concerns and are a voting 
>> member of the TC, cast your vote so that we will know where we 
>> stand.  Votes can always be changed until the cut-off on the 15th.
>> Regards,
>> Elysa Jones, Chair
>> CTO, Warning Systems, Inc.
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that 
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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]