RE: [emergency] SBE Viewpoint

["Ron Lake" <rlake@galdosinc.com>]

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-----
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 <alert> with almost exactly the same language as CAP v1.2 Section 
> 3.4.2.1 and 3.4.2.2 .
>
> The other main difference wrt this particular issue is that the CAP
v1.2 
> Schema explicitly carries the namespaces for xmldsig and xmlenc for
two 
> <any> tags.
>
> We could delete the <any> tags from the schema, but it would not 
> disallow anyone from signing and/or encrypting the CAP message, as
they 
> can now.
>
> 3. I have yet to hear a suggestion to eliminate this problem in CAP
v1.2 
> that doesn't require a new Review Process or moving to CAP 2.0.
>
> The idea of taking a deep breath and a step back to re-evaluate has
its 
> costs, and those costs compound as the clock ticks. This problem has
not 
> crippled CAP yet. Is it likely to do so between now and when the TC 
> completes CAP 2.0? If so, then, by all means, lets withdraw this
version 
> and get to work. However, my own available time is now fully committed

> or over committed.
>
> Cheers,
> Rex
>
>
> Gary Timm wrote:
>   
>> 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.
>>
>>   
>>     
>
>   

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


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