[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]