[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] SBE Viewpoint
Emphatically yes! It's really a question of what takes us to either of two less than wonderful results: a new review cycle starting with a 60-Day PR; or, CAP 2.0. This large a change would be 2.0 territory in my opinion. But we can already do this optionally, so we don't need to do more until 2.0. Almost anything we do other than accept an approval result if that is what happens, requires a new review in my opinion, but my opinion has been wrong before. I'd go for a resolution that has clear unanimous or near-unanimous support, even if it takes 60-Days, but without that kind of consensus, I'd rather take what we have, urge everyone on to working on CAP 2.0 and put out clear guidance for implementers not to encrypt CAP period, and to use EDXL-DE for signatures and any encryption. Cheers, Rex Ron Lake wrote: > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]