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] SBE Viewpoint

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

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.


-----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 and allow digital signature and encryption of 
the <alert> with almost exactly the same language as CAP v1.2 Section and .

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.


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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]