Re: [emergency] SBE Viewpoint

[Rex Brooks <rexb@starbourne.com>]

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