OASIS Emergency Management TC

All:



After consulting with Sandia Management, I have voted
“No” for the CAP 1.2 committee specification.  The reasons
follow:



First, Sandia presented during the IPAWS program the reasons
for creating a true publish/subscribe capability for public alert and
warning.  This meant both individuals (e.g. subscription services) and
jurisdictions (city, county, tribal) could select the levels of information
they wanted to receive via various communications media.  This implied a
decoupling of the Alert Publisher and the Alert Consumer (e.g. SOA loose
coupling).  It also implied a significant number of redistribution
capabilities managed by both Federal and Commercial entities.  During
discussions with FCC, the issue of non-repudiation and liability for distribution
of misleading or spoofed Alerts was emphasized.



These concerns implied a design which was well suited for
using the OASIS EDXL-DE distribution capability.  Yesterday, I arranged a
technical discussion with Gary Ham and Rex Brooks to explain some of my
concerns with the current schema for CAP 1.2.  There has always been the
capability to “wrap” CAP 1.0 or CAP 1.1 with any appropriate
wrapping metadata (e.g. OASIS EDXL-DE, W3C XML signature or encryption
techniques etc.).  The real question was about the infrastructure to
interpret the wrapping metadata (we have a subcommittee dedicated to this).



Here are some of the issues I presented to Gary and
Rex.  The Emergency Management Technical Committee years ago realized the
need for a publish/subscribe capability for distribution.  They also
realized the need for confidentiality and non-repudiation of critical
information exchanges.  I reminded them of the reason we created the
keyXMLContent element tag.  If there was Law Enforcement (e.g. Radiation
detections) or Health Sensitive (e.g. HAVE messages) content being distributed,
the distribution/re-distribution infrastructure might need selected information
from within the embeddedXMLContent elements about the “Intent” of
the distribution in addition to information extracted from embedded content and
included in other EDXL-DE tags.  It states:

·        
Extracts
must come from the XML document contained within the <embeddedXMLContent>
element within the current <contentObject> block.

·        
All
content within this element MUST be explicitly namespaced as defined in the
enclosing <contentObject> tag.

·        
MUST be a properly formed -escaped if
necessary- XML string.

Since disclosure control is about only exposing
“readable” information to appropriately vetted consumers, there was
a need to not only encrypt the data but ensure the recipient was
“authorized” to receive the decryption capability to read the
information.  This could only be accomplished with PKI or symmetric key
technologies and additional distribution infrastructure (e.g. TSG and
SPORs).  This has significant impacts on the distribution/redistribution
capabilities.  Gary and Rex cautioned me not to go into technical details
but I would be glad to provide selected individuals the reasons why both
symmetric and PKI encryption are bad ideas for distributing CAP messages
without appropriate wrapping metadata and supporting infrastructure.  CAP
1.2 encrypted content could also break OASIS EDXL-DE infrastructure designed to
“automatically” wrap time sensitive distribution like the TSG/SPOR
network used by DNDO.  There are many other reasons.



There is also a misconception about digital signatures and
non-repudiation.  It is true that a digital signature can detect the
tampering of a message after it has routed through various distribution
technologies. However as we have be documenting in the OASIS SOA Reference
Architecture Framework documentation, non-repudiation requires Authenticity of
delivered message, Proof of intent of message, and Authority of sender to
request this intent in a point-to-point transaction and if it uses in a loosely
coupled SOA publish/subscribe distribution capability there must also be a
“Trust” anchor and transmission of trust through the routing
infrastructure.  Digital Signature can only provide authenticity of
delivered message.  The CAP Alert structure provides some proof of intent
which can be strengthen by usage profiles.  But there is no mechanism for
determining that the “Social Structure” has authorized the transmission
of CAP alert.  The OASIS EDXL-DE schema has and SenderRole element but
even this must be used with other technologies to bind it with authenticity and
proof of its authority from the Jurisdiction in the distributed EDXL-DE
message.  This is the reason I don’t even like the signing of CAP
1.2 Alert messages because people assert this provides non-repudiation of the
transmitted message.  I do not believe this could successfully proven in a
court of law.  This could also create potential liabilities for the
distribution/redistribution capabilities if they had some implied
non-repudiation responsibilities.



Please understand that Sandia is only trying to be an honest
broker for development of “international” standards per the OASIS
charter.  We are not trying to block need Emergency Management capability.



Dave









From: Gary Ham
[mailto:gham@grandpaham.com]

Sent: Thursday, February 11, 2010 7:22 AM

To: Gary Ham

Cc: emergency@lists.oasis-open.org; Bryan Field; Mark Lucero; Dean
Rychlik; ARTHUR C III CTR DISA JITC BOTTERELL; Roderick [USA] [USA] Cash; Neil
C Bourgeois

Subject: [emergency] Re: CAP 1.2, Encryption, and DM-OPEN









A clarification on the below tool issues:











Neil and I have been dealing with issues related to the
implementation of CAP 1.2 in DM-OPEN 2.0 using the <any> tag and Oracle 10g SOA Suite.  They are workable
and probably OBE with the next implementation of the Oracle 11g SOA Suite. 











The point is that they are tool issues. We will work it
out.









On Feb 11, 2010, at 9:09 AM, Gary Ham wrote:










Folks,


As you may or may not know we had some discussions concerning implementation
difficulties with CAP 1.2.  For the most part those issues are
tool-related and can be dealt with (although the work level is still TBD).
 Encryption is, however, a different matter and would be very hard to do
in a CAP 1.2 environment.  Bottom line is this, we support CAP 1.2, but we
will not be handling encrypted traffic on the CAP interfaces.  The
essential story follow:


Here is a message I drafted for all of you to review, but sent to for vetting
to Art Botterell and Mark Lucero (IPAWS):


Neil and I have been dealing with issues related to the implementation of CAP
1.2 in DM-OPEN 2.0 using the <any> tag.  They are workable and
probably OBE with the next implementation of the Oracle SOA Suite. So, the
initial DM-OPEN 2.0 will be CAP 1.1 with CAP 1.2 to be part of the first fully
 IPAWS capable follow-on release.   In looking at the
<any> issue I came across what might be a bigger worry down the line.
 If you choose to encrypt the content of the CAP message in a CAP only network,
every node on the network that the CAP message can be sent to (or through as in
network to network traffic) must be able to decrypt the message in order to
read it or to get the needed information to pass it on. At the number of
network nodes grow in a network of networks, key management will become an NP
hard problem, growing at an exponential rate. This my be the reason so little
encryption of CAP 1.1 messages has occurred.  My point is that encryption
of CAP 1.2 in a CAP only network will be extremely hard to manage. Signatures
can be handled. Encryption; not so well.   Your thoughts are welcome.


Art's response:


But what's the requirement for encryption in a public warning system?


Encryption tends to get confused with authentication because of the Web 1.0
practice of using passwords (or certificates) to authenticate sessions or
connections, and then assuming that anything arriving over the trusted link
must itself be authentic.  


In that case encryption is required to protect the integrity of that individual
link, whether or not there's any requirement for privacy of the actual
communication.  (And of course any compromise at either end of the link
means the whole game's over.)


By applying authentication to the individual messages, rather than to the
links, the question of encryption becomes orthagonal to that of authentication.
 Each message is provably authentic or not, regardless of how it arrived
or where it's been.  And encryption can be evaluated separately and on its
own merits.


Bottom line, I think the reason there's been so little encryption of CAP alerts
is that there's been no particular requirement to keep the contents of public
warnings secret.


Mark Lucero's response:


You're correct, Art.  IPAWS requirements are: Low Confidentiality, High

Integrity, High Availability.  We don't want to encrypt anything, we

only want to ensure the message has not been altered (high integrity).

This infers the need for digital signatures, but there's no need to

encrypt anything.



My Bottom line:


Since we will not be encrypting or accepting encrypted CAP on the DM-OPEN CAP
Interfaces, we can make  CAP1.2 work in its other capacities for public
warning.  If you do need to transport an encrypted CAP message, you can
use the DM-OPEN DE interface with an encrypted CAP payload, but the recipient
systems will have to know how to know how to retrieve DE messages from DM-OPEN
 and decrypt them on their end.


Respectfully,


Gary Ham

Systems Architect

FEMA Disaster Management Program

703-899-6241
















Gary Ham





http://grandpaham.com





703-899-6241

EM-TC Members,

After consultation with members of the organization I represent,
the Society of Broadcast Engineers, I must report that we have serious concerns
with the issues presented this past week regarding CAPv1.2, particularly as it
relates to Digital Signature.  It would seem we as the TC need to take a
step back and reassess the readiness of CAPv1.2 to progress through the
standards process.  Additional testing is perhaps in order to work out
these current issues, so that in short order a more implementable protocol can
be presented for OASIS Standards approval.  Some have advocated for just
approving CAPv1.2 and fixing everything in CAPv2.0.  However, with the
OASIS CAP IPAWS Profile based on CAPv1.2, that does not bode well for unhindered
implementation of CAPv1.2 for the Emergency Alert System and FEMA’s IPAWS
Program.

I just wanted to make SBE’s viewpoint known to my fellow
EM-TC members.



Gary Timm, Society of Broadcast Engineers

EM-TC Voting Member









......................................................................
The information contained in this communication may be confidential or 
legally privileged and is intended only for the recipient named above. 
If the reader of this message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication or its contents is strictly prohibited. If you have 
received this communication in error, please immediately advise the 
sender and delete the original and any copies from your computer system.

Thanks Gary,

I respect your position and opinion every bit as much as I respect Dave 
Ellis positions and opinions, and I work with him quite a lot.

Since I've already made my position clear, I won't repeat that. However, 
I do want to point out a few things.

1. If you go to the voting page, as of the time I'm writing this 
message, 6 voting members have yet to vote, so I'd like to encourage 
whomever has not voted to do so.

2. Even if this version of 1.2 fails to win Committee Specification 
approval and approval to be advanced for OASIS Standard Approval, CAP 
v1.1 allows the same problem that has been identified since CAP v1.1 
Section 3.3.2.1 and 3.3.2.2 allow digital signature and encryption of 
the 

Rex, Gary

I would like to reframe the discussion about infrastructure and not digital
signatures.  The main point about Non-repudiation is not just about the
authenticity of the message but the authority of the message to direct the
action.  Let me use the well know, as portrayed in Movies, example of the
Nuclear release Msg.

1. The authenticators were delivered via a courier to the intended
initiators of the action.  They were created by a secure mechanism which
only authorized personnel were allowed to create the codes, deliver the
codes and authenticate the codes. They were stored in a location with high
security and limit personnel access.

2. The system was a single authority structure with the president/authorized
delegate as the single release authority and specifically designated action
elements.

We have a system which is more complicated than Nuclear Release Authority
with public alert and warning systems.  First, even if we could develop a
acceptable key distribution system we do not have a single authority
structure but many alert generators (jurisdictions) and even more action
redistribution participants.  As you know many federal agencies are
requiring a single certificate generation capability (e.g. HSPD cards, CAC
cards, etc.) which are on devices which are not stored on the computer key
store but accessed via a USB FOB or chip embedded card.  This is because key
stores on computers used by many applications can be accessed and used for
unauthorized processes.  I have heard of no plans for FEMA or another
Federal agency to create this kind of distribution for digital signing
capability on EAS, Cell Phone etc. delivered CAP IPAWS messages.

This is a huge infrastructure issue; however, it is not the most critical
problem.  Currently, there are few systems (some EDXL-DE prototypes) which
actually examine policies of the sender with the actions requested in the
CAP message.  Even if the digital signature infrastructure was perfect, a
sender by mistake or on purpose could specify an area tag like (polygon,
circle, geocode) with some corresponding actions which is outside their
authority to direct.  Since there is no infrastructure to tie a senders role
and authority with sender, distribution, redistribution and/or receiver
policies, it would be possible for anyone to send an alert to evacuation
Washington DC for example.  What would prevent this?

This must be associated with the actual message and compared with policies
as the message transverses the distribution infrastructure.  Even if systems
like DM OPEN would capture the logon information of CAP injectors and
compare them with policy table specified by jurisdictions (COGs), the basic
chain of evidence methods would not be cryptographically tied to the actual
CAP message but potentially be referenced via table links. This would
require the redistribution capability to have significant processes
established to mitigate improper alterations and incorrectly generated CAP
messages from being sent to inappropriate receivers.

This issue is not solved with digital signatures.

Dave         



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com] 
Sent: Monday, February 15, 2010 8:29 AM
To: Gary Timm
Cc: emergency@lists.oasis-open.org
Subject: Re: [emergency] SBE Viewpoint

Thanks Gary,

I respect your position and opinion every bit as much as I respect Dave 
Ellis positions and opinions, and I work with him quite a lot.

Since I've already made my position clear, I won't repeat that. However, 
I do want to point out a few things.

1. If you go to the voting page, as of the time I'm writing this 
message, 6 voting members have yet to vote, so I'd like to encourage 
whomever has not voted to do so.

2. Even if this version of 1.2 fails to win Committee Specification 
approval and approval to be advanced for OASIS Standard Approval, CAP 
v1.1 allows the same problem that has been identified since CAP v1.1 
Section 3.3.2.1 and 3.3.2.2 allow digital signature and encryption of 
the 

Thanks David,

What Dave is saying is correct. We still have quite a distance to cover 
to develop a robust non-repudiation capability. Dave, many others and I 
are working through Use-Cases in the RIM SC to drive out the 
requirements for such a capability in the ValueListURN which is now 
contained in EDXL-DE, EDXL-RM and EDXL-HAVE. Its not a simple task.

We need to understand the infrastructure needs better than we have in 
the past, but right now we need to get past the current hurdle.

While I agree with what Dave is pointing out, none of the currently 
possible outcomes of the CAP v1.2 ballots will actually solve this set 
of problems. I still haven't seen a compelling reason to change my vote.

Cheers,
Rex

David E. Ellis wrote:
> Rex, Gary
>
> I would like to reframe the discussion about infrastructure and not digital
> signatures.  The main point about Non-repudiation is not just about the
> authenticity of the message but the authority of the message to direct the
> action.  Let me use the well know, as portrayed in Movies, example of the
> Nuclear release Msg.
>
> 1. The authenticators were delivered via a courier to the intended
> initiators of the action.  They were created by a secure mechanism which
> only authorized personnel were allowed to create the codes, deliver the
> codes and authenticate the codes. They were stored in a location with high
> security and limit personnel access.
>
> 2. The system was a single authority structure with the president/authorized
> delegate as the single release authority and specifically designated action
> elements.
>
> We have a system which is more complicated than Nuclear Release Authority
> with public alert and warning systems.  First, even if we could develop a
> acceptable key distribution system we do not have a single authority
> structure but many alert generators (jurisdictions) and even more action
> redistribution participants.  As you know many federal agencies are
> requiring a single certificate generation capability (e.g. HSPD cards, CAC
> cards, etc.) which are on devices which are not stored on the computer key
> store but accessed via a USB FOB or chip embedded card.  This is because key
> stores on computers used by many applications can be accessed and used for
> unauthorized processes.  I have heard of no plans for FEMA or another
> Federal agency to create this kind of distribution for digital signing
> capability on EAS, Cell Phone etc. delivered CAP IPAWS messages.
>
> This is a huge infrastructure issue; however, it is not the most critical
> problem.  Currently, there are few systems (some EDXL-DE prototypes) which
> actually examine policies of the sender with the actions requested in the
> CAP message.  Even if the digital signature infrastructure was perfect, a
> sender by mistake or on purpose could specify an area tag like (polygon,
> circle, geocode) with some corresponding actions which is outside their
> authority to direct.  Since there is no infrastructure to tie a senders role
> and authority with sender, distribution, redistribution and/or receiver
> policies, it would be possible for anyone to send an alert to evacuation
> Washington DC for example.  What would prevent this?
>
> This must be associated with the actual message and compared with policies
> as the message transverses the distribution infrastructure.  Even if systems
> like DM OPEN would capture the logon information of CAP injectors and
> compare them with policy table specified by jurisdictions (COGs), the basic
> chain of evidence methods would not be cryptographically tied to the actual
> CAP message but potentially be referenced via table links. This would
> require the redistribution capability to have significant processes
> established to mitigate improper alterations and incorrectly generated CAP
> messages from being sent to inappropriate receivers.
>
> This issue is not solved with digital signatures.
>
> Dave         
>
> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Monday, February 15, 2010 8:29 AM
> To: Gary Timm
> Cc: emergency@lists.oasis-open.org
> Subject: Re: [emergency] SBE Viewpoint
>
> Thanks Gary,
>
> I respect your position and opinion every bit as much as I respect Dave 
> Ellis positions and opinions, and I work with him quite a lot.
>
> Since I've already made my position clear, I won't repeat that. However, 
> I do want to point out a few things.
>
> 1. If you go to the voting page, as of the time I'm writing this 
> message, 6 voting members have yet to vote, so I'd like to encourage 
> whomever has not voted to do so.
>
> 2. Even if this version of 1.2 fails to win Committee Specification 
> approval and approval to be advanced for OASIS Standard Approval, CAP 
> v1.1 allows the same problem that has been identified since CAP v1.1 
> Section 3.3.2.1 and 3.3.2.2 allow digital signature and encryption of 
> the 

Hi,

It sounds to me you are trying to handle non-repudiation within the
message?  Should this not be done at the message envelope level?   

R



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com] 
Sent: February 15, 2010 10:19 AM
To: David E. Ellis
Cc: 'Gary Timm'; emergency@lists.oasis-open.org; 'Oien, Chuck';
'Sanzero, George'; 'Ammerlahn, Heidi'
Subject: Re: [emergency] SBE Viewpoint

Thanks David,

What Dave is saying is correct. We still have quite a distance to cover 
to develop a robust non-repudiation capability. Dave, many others and I 
are working through Use-Cases in the RIM SC to drive out the 
requirements for such a capability in the ValueListURN which is now 
contained in EDXL-DE, EDXL-RM and EDXL-HAVE. Its not a simple task.

We need to understand the infrastructure needs better than we have in 
the past, but right now we need to get past the current hurdle.

While I agree with what Dave is pointing out, none of the currently 
possible outcomes of the CAP v1.2 ballots will actually solve this set 
of problems. I still haven't seen a compelling reason to change my vote.

Cheers,
Rex

David E. Ellis wrote:
> Rex, Gary
>
> I would like to reframe the discussion about infrastructure and not
digital
> signatures.  The main point about Non-repudiation is not just about
the
> authenticity of the message but the authority of the message to direct
the
> action.  Let me use the well know, as portrayed in Movies, example of
the
> Nuclear release Msg.
>
> 1. The authenticators were delivered via a courier to the intended
> initiators of the action.  They were created by a secure mechanism
which
> only authorized personnel were allowed to create the codes, deliver
the
> codes and authenticate the codes. They were stored in a location with
high
> security and limit personnel access.
>
> 2. The system was a single authority structure with the
president/authorized
> delegate as the single release authority and specifically designated
action
> elements.
>
> We have a system which is more complicated than Nuclear Release
Authority
> with public alert and warning systems.  First, even if we could
develop a
> acceptable key distribution system we do not have a single authority
> structure but many alert generators (jurisdictions) and even more
action
> redistribution participants.  As you know many federal agencies are
> requiring a single certificate generation capability (e.g. HSPD cards,
CAC
> cards, etc.) which are on devices which are not stored on the computer
key
> store but accessed via a USB FOB or chip embedded card.  This is
because key
> stores on computers used by many applications can be accessed and used
for
> unauthorized processes.  I have heard of no plans for FEMA or another
> Federal agency to create this kind of distribution for digital signing
> capability on EAS, Cell Phone etc. delivered CAP IPAWS messages.
>
> This is a huge infrastructure issue; however, it is not the most
critical
> problem.  Currently, there are few systems (some EDXL-DE prototypes)
which
> actually examine policies of the sender with the actions requested in
the
> CAP message.  Even if the digital signature infrastructure was
perfect, a
> sender by mistake or on purpose could specify an area tag like
(polygon,
> circle, geocode) with some corresponding actions which is outside
their
> authority to direct.  Since there is no infrastructure to tie a
senders role
> and authority with sender, distribution, redistribution and/or
receiver
> policies, it would be possible for anyone to send an alert to
evacuation
> Washington DC for example.  What would prevent this?
>
> This must be associated with the actual message and compared with
policies
> as the message transverses the distribution infrastructure.  Even if
systems
> like DM OPEN would capture the logon information of CAP injectors and
> compare them with policy table specified by jurisdictions (COGs), the
basic
> chain of evidence methods would not be cryptographically tied to the
actual
> CAP message but potentially be referenced via table links. This would
> require the redistribution capability to have significant processes
> established to mitigate improper alterations and incorrectly generated
CAP
> messages from being sent to inappropriate receivers.
>
> This issue is not solved with digital signatures.
>
> Dave         
>
> 
Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Monday, February 15, 2010 8:29 AM
> To: Gary Timm
> Cc: emergency@lists.oasis-open.org
> Subject: Re: [emergency] SBE Viewpoint
>
> Thanks Gary,
>
> I respect your position and opinion every bit as much as I respect
Dave 
> Ellis positions and opinions, and I work with him quite a lot.
>
> Since I've already made my position clear, I won't repeat that.
However, 
> I do want to point out a few things.
>
> 1. If you go to the voting page, as of the time I'm writing this 
> message, 6 voting members have yet to vote, so I'd like to encourage 
> whomever has not voted to do so.
>
> 2. Even if this version of 1.2 fails to win Committee Specification 
> approval and approval to be advanced for OASIS Standard Approval, CAP 
> v1.1 allows the same problem that has been identified since CAP v1.1 
> Section 3.3.2.1 and 3.3.2.2 allow digital signature and encryption of 
> the 

Hmmm - Methinks this bolsters the thought I was trying to promote of using
the DE for this....I'm glad to see that someone else "gets" that!

Thanks!
Lee

Better to write for yourself and have no public, than to write for the
public and have no self.  - Cyril Connolly




                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Ron Lake [mailto:rlake@galdosinc.com] 
Sent: Monday, February 15, 2010 4:16 PM
To: rexb@starbourne.com; David E. Ellis
Cc: Gary Timm; emergency@lists.oasis-open.org; Oien, Chuck; Sanzero, George;
Ammerlahn, Heidi
Subject: RE: [emergency] SBE Viewpoint

Hi,

It sounds to me you are trying to handle non-repudiation within the
message?  Should this not be done at the message envelope level?   

R


Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com] 
Sent: February 15, 2010 10:19 AM
To: David E. Ellis
Cc: 'Gary Timm'; emergency@lists.oasis-open.org; 'Oien, Chuck';
'Sanzero, George'; 'Ammerlahn, Heidi'
Subject: Re: [emergency] SBE Viewpoint

Thanks David,

What Dave is saying is correct. We still have quite a distance to cover 
to develop a robust non-repudiation capability. Dave, many others and I 
are working through Use-Cases in the RIM SC to drive out the 
requirements for such a capability in the ValueListURN which is now 
contained in EDXL-DE, EDXL-RM and EDXL-HAVE. Its not a simple task.

We need to understand the infrastructure needs better than we have in 
the past, but right now we need to get past the current hurdle.

While I agree with what Dave is pointing out, none of the currently 
possible outcomes of the CAP v1.2 ballots will actually solve this set 
of problems. I still haven't seen a compelling reason to change my vote.

Cheers,
Rex

David E. Ellis wrote:
> Rex, Gary
>
> I would like to reframe the discussion about infrastructure and not
digital
> signatures.  The main point about Non-repudiation is not just about
the
> authenticity of the message but the authority of the message to direct
the
> action.  Let me use the well know, as portrayed in Movies, example of
the
> Nuclear release Msg.
>
> 1. The authenticators were delivered via a courier to the intended
> initiators of the action.  They were created by a secure mechanism
which
> only authorized personnel were allowed to create the codes, deliver
the
> codes and authenticate the codes. They were stored in a location with
high
> security and limit personnel access.
>
> 2. The system was a single authority structure with the
president/authorized
> delegate as the single release authority and specifically designated
action
> elements.
>
> We have a system which is more complicated than Nuclear Release
Authority
> with public alert and warning systems.  First, even if we could
develop a
> acceptable key distribution system we do not have a single authority
> structure but many alert generators (jurisdictions) and even more
action
> redistribution participants.  As you know many federal agencies are
> requiring a single certificate generation capability (e.g. HSPD cards,
CAC
> cards, etc.) which are on devices which are not stored on the computer
key
> store but accessed via a USB FOB or chip embedded card.  This is
because key
> stores on computers used by many applications can be accessed and used
for
> unauthorized processes.  I have heard of no plans for FEMA or another
> Federal agency to create this kind of distribution for digital signing
> capability on EAS, Cell Phone etc. delivered CAP IPAWS messages.
>
> This is a huge infrastructure issue; however, it is not the most
critical
> problem.  Currently, there are few systems (some EDXL-DE prototypes)
which
> actually examine policies of the sender with the actions requested in
the
> CAP message.  Even if the digital signature infrastructure was
perfect, a
> sender by mistake or on purpose could specify an area tag like
(polygon,
> circle, geocode) with some corresponding actions which is outside
their
> authority to direct.  Since there is no infrastructure to tie a
senders role
> and authority with sender, distribution, redistribution and/or
receiver
> policies, it would be possible for anyone to send an alert to
evacuation
> Washington DC for example.  What would prevent this?
>
> This must be associated with the actual message and compared with
policies
> as the message transverses the distribution infrastructure.  Even if
systems
> like DM OPEN would capture the logon information of CAP injectors and
> compare them with policy table specified by jurisdictions (COGs), the
basic
> chain of evidence methods would not be cryptographically tied to the
actual
> CAP message but potentially be referenced via table links. This would
> require the redistribution capability to have significant processes
> established to mitigate improper alterations and incorrectly generated
CAP
> messages from being sent to inappropriate receivers.
>
> This issue is not solved with digital signatures.
>
> Dave         
>
> 
Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Monday, February 15, 2010 8:29 AM
> To: Gary Timm
> Cc: emergency@lists.oasis-open.org
> Subject: Re: [emergency] SBE Viewpoint
>
> Thanks Gary,
>
> I respect your position and opinion every bit as much as I respect
Dave 
> Ellis positions and opinions, and I work with him quite a lot.
>
> Since I've already made my position clear, I won't repeat that.
However, 
> I do want to point out a few things.
>
> 1. If you go to the voting page, as of the time I'm writing this 
> message, 6 voting members have yet to vote, so I'd like to encourage 
> whomever has not voted to do so.
>
> 2. Even if this version of 1.2 fails to win Committee Specification 
> approval and approval to be advanced for OASIS Standard Approval, CAP 
> v1.1 allows the same problem that has been identified since CAP v1.1 
> Section 3.3.2.1 and 3.3.2.2 allow digital signature and encryption of 
> the 

Hi,

I would also expect that one can do this using existing specifications
for messaging such as XML Signatures (W3C) (as part of the solution).
In XML Signatures, one mulches the message being sent using an
appropriate mulching or digestion algorithm (analogous to computing a
CRC) and gets an encrypted string (containing also the sender's
credentials)) that is sent with the message. The receiver uses the
encrypted string to run the received message through the same mulching
algorithm and compares the result with the received string. If they
match, the content MUST have come from the indicated sender (they cannot
deny it) and it must have not been tampered with.

For a better description of this see
http://java.sun.com/developer/technicalArticles/xml/dig_signatures/

The main point is that it has nothing to do with the content of the
message.

R



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Lee Tincher [mailto:ltincher@evotecinc.com] 
Sent: February 15, 2010 1:39 PM
To: Ron Lake; rexb@starbourne.com; 'David E. Ellis'
Cc: 'Gary Timm'; emergency@lists.oasis-open.org; 'Oien, Chuck';
'Sanzero, George'; 'Ammerlahn, Heidi'
Subject: RE: [emergency] SBE Viewpoint

Hmmm - Methinks this bolsters the thought I was trying to promote of
using
the DE for this....I'm glad to see that someone else "gets" that!

Thanks!
Lee

Better to write for yourself and have no public, than to write for the
public and have no self.  - Cyril Connolly



Original Message-----
From: Ron Lake [mailto:rlake@galdosinc.com] 
Sent: Monday, February 15, 2010 4:16 PM
To: rexb@starbourne.com; David E. Ellis
Cc: Gary Timm; emergency@lists.oasis-open.org; Oien, Chuck; Sanzero,
George;
Ammerlahn, Heidi
Subject: RE: [emergency] SBE Viewpoint

Hi,

It sounds to me you are trying to handle non-repudiation within the
message?  Should this not be done at the message envelope level?   

R


Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com] 
Sent: February 15, 2010 10:19 AM
To: David E. Ellis
Cc: 'Gary Timm'; emergency@lists.oasis-open.org; 'Oien, Chuck';
'Sanzero, George'; 'Ammerlahn, Heidi'
Subject: Re: [emergency] SBE Viewpoint

Thanks David,

What Dave is saying is correct. We still have quite a distance to cover 
to develop a robust non-repudiation capability. Dave, many others and I 
are working through Use-Cases in the RIM SC to drive out the 
requirements for such a capability in the ValueListURN which is now 
contained in EDXL-DE, EDXL-RM and EDXL-HAVE. Its not a simple task.

We need to understand the infrastructure needs better than we have in 
the past, but right now we need to get past the current hurdle.

While I agree with what Dave is pointing out, none of the currently 
possible outcomes of the CAP v1.2 ballots will actually solve this set 
of problems. I still haven't seen a compelling reason to change my vote.

Cheers,
Rex

David E. Ellis wrote:
> Rex, Gary
>
> I would like to reframe the discussion about infrastructure and not
digital
> signatures.  The main point about Non-repudiation is not just about
the
> authenticity of the message but the authority of the message to direct
the
> action.  Let me use the well know, as portrayed in Movies, example of
the
> Nuclear release Msg.
>
> 1. The authenticators were delivered via a courier to the intended
> initiators of the action.  They were created by a secure mechanism
which
> only authorized personnel were allowed to create the codes, deliver
the
> codes and authenticate the codes. They were stored in a location with
high
> security and limit personnel access.
>
> 2. The system was a single authority structure with the
president/authorized
> delegate as the single release authority and specifically designated
action
> elements.
>
> We have a system which is more complicated than Nuclear Release
Authority
> with public alert and warning systems.  First, even if we could
develop a
> acceptable key distribution system we do not have a single authority
> structure but many alert generators (jurisdictions) and even more
action
> redistribution participants.  As you know many federal agencies are
> requiring a single certificate generation capability (e.g. HSPD cards,
CAC
> cards, etc.) which are on devices which are not stored on the computer
key
> store but accessed via a USB FOB or chip embedded card.  This is
because key
> stores on computers used by many applications can be accessed and used
for
> unauthorized processes.  I have heard of no plans for FEMA or another
> Federal agency to create this kind of distribution for digital signing
> capability on EAS, Cell Phone etc. delivered CAP IPAWS messages.
>
> This is a huge infrastructure issue; however, it is not the most
critical
> problem.  Currently, there are few systems (some EDXL-DE prototypes)
which
> actually examine policies of the sender with the actions requested in
the
> CAP message.  Even if the digital signature infrastructure was
perfect, a
> sender by mistake or on purpose could specify an area tag like
(polygon,
> circle, geocode) with some corresponding actions which is outside
their
> authority to direct.  Since there is no infrastructure to tie a
senders role
> and authority with sender, distribution, redistribution and/or
receiver
> policies, it would be possible for anyone to send an alert to
evacuation
> Washington DC for example.  What would prevent this?
>
> This must be associated with the actual message and compared with
policies
> as the message transverses the distribution infrastructure.  Even if
systems
> like DM OPEN would capture the logon information of CAP injectors and
> compare them with policy table specified by jurisdictions (COGs), the
basic
> chain of evidence methods would not be cryptographically tied to the
actual
> CAP message but potentially be referenced via table links. This would
> require the redistribution capability to have significant processes
> established to mitigate improper alterations and incorrectly generated
CAP
> messages from being sent to inappropriate receivers.
>
> This issue is not solved with digital signatures.
>
> Dave         
>
> 
Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Monday, February 15, 2010 8:29 AM
> To: Gary Timm
> Cc: emergency@lists.oasis-open.org
> Subject: Re: [emergency] SBE Viewpoint
>
> Thanks Gary,
>
> I respect your position and opinion every bit as much as I respect
Dave 
> Ellis positions and opinions, and I work with him quite a lot.
>
> Since I've already made my position clear, I won't repeat that.
However, 
> I do want to point out a few things.
>
> 1. If you go to the voting page, as of the time I'm writing this 
> message, 6 voting members have yet to vote, so I'd like to encourage 
> whomever has not voted to do so.
>
> 2. Even if this version of 1.2 fails to win Committee Specification 
> approval and approval to be advanced for OASIS Standard Approval, CAP 
> v1.1 allows the same problem that has been identified since CAP v1.1 
> Section 3.3.2.1 and 3.3.2.2 allow digital signature and encryption of 
> the 

Emphatically yes!  It's really a question of what takes us to either of 
two less than wonderful results: a new review cycle starting with a 
60-Day PR; or, CAP 2.0. This large a change would be 2.0 territory in my 
opinion. But we can already do this optionally, so we don't need to do 
more until 2.0.

Almost anything we do other than accept an approval result if that is 
what happens, requires a new review in my opinion, but my opinion has 
been wrong before. I'd go for a resolution that has clear unanimous or 
near-unanimous support, even if it takes 60-Days, but without that kind 
of consensus, I'd rather take what we have, urge everyone on to working 
on CAP 2.0 and put out clear guidance for implementers not to encrypt 
CAP period, and to use EDXL-DE for signatures and any encryption.


Cheers,
Rex

Ron Lake wrote:
> Hi,
>
> It sounds to me you are trying to handle non-repudiation within the
> message?  Should this not be done at the message envelope level?   
>
> R
>
> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: February 15, 2010 10:19 AM
> To: David E. Ellis
> Cc: 'Gary Timm'; emergency@lists.oasis-open.org; 'Oien, Chuck';
> 'Sanzero, George'; 'Ammerlahn, Heidi'
> Subject: Re: [emergency] SBE Viewpoint
>
> Thanks David,
>
> What Dave is saying is correct. We still have quite a distance to cover 
> to develop a robust non-repudiation capability. Dave, many others and I 
> are working through Use-Cases in the RIM SC to drive out the 
> requirements for such a capability in the ValueListURN which is now 
> contained in EDXL-DE, EDXL-RM and EDXL-HAVE. Its not a simple task.
>
> We need to understand the infrastructure needs better than we have in 
> the past, but right now we need to get past the current hurdle.
>
> While I agree with what Dave is pointing out, none of the currently 
> possible outcomes of the CAP v1.2 ballots will actually solve this set 
> of problems. I still haven't seen a compelling reason to change my vote.
>
> Cheers,
> Rex
>
> David E. Ellis wrote:
>   
>> Rex, Gary
>>
>> I would like to reframe the discussion about infrastructure and not
>>     
> digital
>   
>> signatures.  The main point about Non-repudiation is not just about
>>     
> the
>   
>> authenticity of the message but the authority of the message to direct
>>     
> the
>   
>> action.  Let me use the well know, as portrayed in Movies, example of
>>     
> the
>   
>> Nuclear release Msg.
>>
>> 1. The authenticators were delivered via a courier to the intended
>> initiators of the action.  They were created by a secure mechanism
>>     
> which
>   
>> only authorized personnel were allowed to create the codes, deliver
>>     
> the
>   
>> codes and authenticate the codes. They were stored in a location with
>>     
> high
>   
>> security and limit personnel access.
>>
>> 2. The system was a single authority structure with the
>>     
> president/authorized
>   
>> delegate as the single release authority and specifically designated
>>     
> action
>   
>> elements.
>>
>> We have a system which is more complicated than Nuclear Release
>>     
> Authority
>   
>> with public alert and warning systems.  First, even if we could
>>     
> develop a
>   
>> acceptable key distribution system we do not have a single authority
>> structure but many alert generators (jurisdictions) and even more
>>     
> action
>   
>> redistribution participants.  As you know many federal agencies are
>> requiring a single certificate generation capability (e.g. HSPD cards,
>>     
> CAC
>   
>> cards, etc.) which are on devices which are not stored on the computer
>>     
> key
>   
>> store but accessed via a USB FOB or chip embedded card.  This is
>>     
> because key
>   
>> stores on computers used by many applications can be accessed and used
>>     
> for
>   
>> unauthorized processes.  I have heard of no plans for FEMA or another
>> Federal agency to create this kind of distribution for digital signing
>> capability on EAS, Cell Phone etc. delivered CAP IPAWS messages.
>>
>> This is a huge infrastructure issue; however, it is not the most
>>     
> critical
>   
>> problem.  Currently, there are few systems (some EDXL-DE prototypes)
>>     
> which
>   
>> actually examine policies of the sender with the actions requested in
>>     
> the
>   
>> CAP message.  Even if the digital signature infrastructure was
>>     
> perfect, a
>   
>> sender by mistake or on purpose could specify an area tag like
>>     
> (polygon,
>   
>> circle, geocode) with some corresponding actions which is outside
>>     
> their
>   
>> authority to direct.  Since there is no infrastructure to tie a
>>     
> senders role
>   
>> and authority with sender, distribution, redistribution and/or
>>     
> receiver
>   
>> policies, it would be possible for anyone to send an alert to
>>     
> evacuation
>   
>> Washington DC for example.  What would prevent this?
>>
>> This must be associated with the actual message and compared with
>>     
> policies
>   
>> as the message transverses the distribution infrastructure.  Even if
>>     
> systems
>   
>> like DM OPEN would capture the logon information of CAP injectors and
>> compare them with policy table specified by jurisdictions (COGs), the
>>     
> basic
>   
>> chain of evidence methods would not be cryptographically tied to the
>>     
> actual
>   
>> CAP message but potentially be referenced via table links. This would
>> require the redistribution capability to have significant processes
>> established to mitigate improper alterations and incorrectly generated
>>     
> CAP
>   
>> messages from being sent to inappropriate receivers.
>>
>> This issue is not solved with digital signatures.
>>
>> Dave         
>>
>> 
Original Message-----
>> From: Rex Brooks [mailto:rexb@starbourne.com] 
>> Sent: Monday, February 15, 2010 8:29 AM
>> To: Gary Timm
>> Cc: emergency@lists.oasis-open.org
>> Subject: Re: [emergency] SBE Viewpoint
>>
>> Thanks Gary,
>>
>> I respect your position and opinion every bit as much as I respect
>>     
> Dave 
>   
>> Ellis positions and opinions, and I work with him quite a lot.
>>
>> Since I've already made my position clear, I won't repeat that.
>>     
> However, 
>   
>> I do want to point out a few things.
>>
>> 1. If you go to the voting page, as of the time I'm writing this 
>> message, 6 voting members have yet to vote, so I'd like to encourage 
>> whomever has not voted to do so.
>>
>> 2. Even if this version of 1.2 fails to win Committee Specification 
>> approval and approval to be advanced for OASIS Standard Approval, CAP 
>> v1.1 allows the same problem that has been identified since CAP v1.1 
>> Section 3.3.2.1 and 3.3.2.2 allow digital signature and encryption of 
>> the