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


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


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


David E. Ellis wrote:
> Rex, Gary
> I would like to reframe the discussion about infrastructure and not
> signatures.  The main point about Non-repudiation is not just about
> authenticity of the message but the authority of the message to direct
> action.  Let me use the well know, as portrayed in Movies, example of
> 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
> only authorized personnel were allowed to create the codes, deliver
> codes and authenticate the codes. They were stored in a location with
> security and limit personnel access.
> 2. The system was a single authority structure with the
> delegate as the single release authority and specifically designated
> elements.
> We have a system which is more complicated than Nuclear Release
> 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
> redistribution participants.  As you know many federal agencies are
> requiring a single certificate generation capability (e.g. HSPD cards,
> cards, etc.) which are on devices which are not stored on the computer
> 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
> 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
> problem.  Currently, there are few systems (some EDXL-DE prototypes)
> actually examine policies of the sender with the actions requested in
> CAP message.  Even if the digital signature infrastructure was
perfect, a
> sender by mistake or on purpose could specify an area tag like
> circle, geocode) with some corresponding actions which is outside
> authority to direct.  Since there is no infrastructure to tie a
senders role
> and authority with sender, distribution, redistribution and/or
> policies, it would be possible for anyone to send an alert to
> Washington DC for example.  What would prevent this?
> This must be associated with the actual message and compared with
> as the message transverses the distribution infrastructure.  Even if
> like DM OPEN would capture the logon information of CAP injectors and
> compare them with policy table specified by jurisdictions (COGs), the
> chain of evidence methods would not be cryptographically tied to the
> 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
> 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
> 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.
> 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
> Schema explicitly carries the namespaces for xmldsig and xmlenc for
> <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
> can now.
> 3. I have yet to hear a suggestion to eliminate this problem in CAP
> 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
> costs, and those costs compound as the clock ticks. This problem has
> 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
> 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
>> 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
>> Gary Timm, Society of Broadcast Engineers
>> EM-TC Voting Member
>> The information contained in this communication may be confidential
>> legally privileged and is intended only for the recipient named
>> If the reader of this message is not the intended recipient, you are 
>> hereby notified that any dissemination, distribution or copying of
>> 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

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]