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 ??

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:element name="contentDescription" type="xsd:string" 
                 <xsd:element name="contentKeyword" type="valueListType" 
minOccurs="0" maxOccurs="unbounded"/>
                 <xsd:element name="incidentID" type="xsd:string" 
                 <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" 
                    <xsd:element name="nonXMLContent" 
                    <xsd:element name="xmlContent" type="xmlContentType"/>

            _*<xsd:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded" />*_


 In EDXL-DE there is also a separate <xsd:complexType name="anyXMLType"> 
that also uses the "##other" namespace:

<xsd:complexType name="anyXMLType">
              _*<xsd:any namespace="##other" processContents="lax" 

            <xsd:anyAttribute namespace="##other" processContents="lax"/>

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.


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]