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:]
Sent: February 15, 2010 10:19 AM
To: David E. Ellis
Cc: 'Gary Timm'; ; '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:]
> Sent: Monday, February 15, 2010 8:29 AM
> To: Gary Timm
> Cc:
> 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
