[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] SBE Viewpoint
Hmmm - Methinks this bolsters the thought I was trying to promote of using the DE for this....I'm glad to see that someone else "gets" that! Thanks! Lee Better to write for yourself and have no public, than to write for the public and have no self. - Cyril Connolly -----Original Message----- From: Ron Lake [mailto:rlake@galdosinc.com] Sent: Monday, February 15, 2010 4:16 PM To: rexb@starbourne.com; David E. Ellis Cc: Gary Timm; emergency@lists.oasis-open.org; Oien, Chuck; Sanzero, George; Ammerlahn, Heidi 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 --------------------------------------------------------------------- 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]