[CAP] Then Again... (was Re: CAP Security Using Digital Signatures)
Rex Brooks
rexb at starbourne.com
Thu Mar 12 12:00:56 PDT 2009
Just wanted to let you all know that I have forwarded this thread to
the Messages and Notification Subcommittee of the OASIS EM TC because
I think it is significant, and I wanted them to be aware of the
conversation.
Thanks,
Rex
At 2:46 PM -0400 3/12/09, matt hoffman wrote:
>Sorry, didn't see this post before replying to the other.
>Whether we specify it or not (and, it could be that canonicalization
>standards have reached a point that we no longer need to -- I don't want to
>be too hopeful, but it is certainly possible) there are certainly
>performance benefits in forwarding the message as you received it, if there
>were no local changes.
>At least, in my implementation experiences. Saves one serialization step,
>and one set of possible compatibility issues.
>
>Now, whether we want to mandate sign-the-blob... I agree that, from a
>signature point of view, it simplifies things considerably (or seems to -- I
>haven't tried it with the Java toolkits, but it makes sense that it would
>work as you're suggesting). But other implementers might want to speak up
>there about the feasibility of ALWAYS passing exactly what they received if
>there is a digital signature included. That's mandating a particular
>implementation step that might not be trivial for all users.
>
>
>
>On Thu, Mar 12, 2009 at 12:08 PM, Art Botterell <acb at incident.com> wrote:
>
>> Thinking about it a bit more... am I mistaken, or wouldn't a simple way to
>> implement a "sign the blob" approach be just to use a "null"
>> canonicalization in otherwise-normal XMLSIG?
>>
>> As I understand it, the reason for C14N is to deal with variations in
>> whitespace, attribute order and such that can occur when XML is parsed and
>> then re-serialized. So we try to factor out every possible change that
>> might occur in those processes... with, it appears, limited success.
>>
>> But to simply forward/publish someone else's CAP alert, seems like passing
>> it along precisely, byte-for-byte, would be relatively simple... and (as the
>> Gutmann paper points out) much more auditable. Of course that wouldn't
>> prevent any node from parsing the alert and acting on the basis of the
>> contents. It would only mean that if that node decides to pass the alert to
>> other nodes, it must give them the precise version it received.
>>
>> In other words, if C14N is murky bathwater, maybe we could dispense with it
>> without needing to toss the baby too. All we'd need would be a
>> clarification in the OASIS spec (and an implementers' convention till then)
>> that canonicalization SHALL NOT be applied during signing. (And to fix the
>> schema, of course.)
>>
>> Or am I missing something here?
>>
>> - Art
>>
>>
>> On Mar 12, 2009, at 3/12/09 8:32 AM, Art Botterell wrote:
>>
>> Interesting link, Matt. Sounds like an object lesson on why we should
>>> resist the temptation to standardize what we don't yet understand.
>>>
>>> I was thinking we might wind up proposing an erratum to OASIS to fix the
>>> schema issue, but hadn't appreciated that cannonicalization was still
>>> proving so intractable. Although that article is from 2004, I take it the
>>> C14N situation hasn't improved. So maybe it would make more sense to
>>> identify (and demonstrate!) alternate approaches that could be
>>>fed back into
>>> the standard.
>>>
>>> My concern is that if we don't address the end-to-end signature problem as
>>> a community there might not be a business incentive for any particular
>>> implementer to design for that level of interoperability. And while the
> >> OASIS process usually does a good job of refining and ratifying
>contributed
>>> designs, it seems not to be as effective as a framework for
>>>developing those
>>> designs in the first place.
>>>
>>> - Art
>>>
>>>
>>>
>>> On Mar 12, 2009, at 3/12/09 5:59 AM, matt hoffman wrote:
>>>
>>> I did a proof-of-concept implementation of this on a previous DHS system.
>>>> Although, as you say, there was no way of verifying it with
>>>>other providers
> >>> or consumers at the time.
>>>> However, a couple of points that I recall:
>>>>
>>>> a.) The document mentions that the signature element can be a child of
>>>> "alert", but unless I'm mistaken it is not specified in the schema. So
>>>> messages containing signatures fail schema validation ... I had to
>>>> explicitly add it to the schema.
>>>>
>>>> b.) The signatures are delicate, and tricky:
>>>> http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt
>>>>
>>>> Unfortunately I no longer have access to that code, but I'd be happy to
>>>> help others if they're looking into it.
>>>>
>>>>
>>>> - matt
>>>>
>>>> On Wed, Mar 11, 2009 at 11:20 PM, Art Botterell <acb at incident.com>
>>>> wrote:
>>>> Friends -
>>>>
>>>> We're moving rapidly toward an important threshold in CAP
>>>> implementations. So far, most CAP-based systems have been self-contained,
>>>> single vendor/implementer arrangements. But soon we're going to need to
>>>> "federate" CAP traffic among multiple interoperable systems. And that has
>>>> important implications for security.
>>>>
>>>> Most current systems use a trusted-link/trusted-host mode based on
>>>> encrypted network links and password access control at a central server.
>>>> That's a familiar Web 1.0 approach and it works fine for "single-hop"
>>>> implementations. But it has a major drawback: As soon as messages are
>>>> forwarded from one server to another, a security compromise anywhere can
>>>> compromise the authentication and integrity of all CAP messages
>>>>downstream.
>>>>
>>>> The alternative, of course, is to apply digital signatures to CAP
>>>> messages at their origin, and to verify them at receiving
>>>>points. That way,
>>>> it doesn't matter if the links or intervening nodes are secure or not; any
>>>> recipient can verify independently that the message is a) from who it says
>>>> it's from, and b) hasn't been modified in transit.
>>>>
>>>> There's a standard way of doing this for XML, as cited in the CAP
>>>> Specification:
>>>>
>>>> >3.3.2.1 Digital Signatures
>>>> >The alert element of a CAP Alert Message MAY have an Enveloped
>>>> Signature, as described by XML Signature and
>>>> >Syntax Processing [XMLSIG]. Other XML signature mechanisms MUST NOT be
>>>> used in CAP Alert Messages. Processors
>>>> >MUST NOT reject a CAP Alert Message containing such a signature simply
>>>> because they are not capable of verifying
>>>> >it; they MUST continue processing and MAY inform the user of their
>>>> failure to validate the signature.
>>>>
>>>> But I'm not aware of anyone that's implemented it yet... partly because
>>>> it hasn't been necessary in stand-alone systems, and partly because it
>>>> involves a type of programming a lot of folks haven't had occasion to
>>>> explore yet.
>>>>
>>>> But ultimately, it's going to be essential for interoperability. So I'd
>>>> be interested in hearing, has anyone implemented XMLSIG on CAP yet? And
>>>> would anyone be interested in doing some interoperability
>>>>experiments? The
>>>> standard is there, the technology is there (in Java and a number of other
>>>> languages) and I see the requirement bearing down on us quickly.
>>>>
>>>> What say?
>>>>
>>>> - Art
>>>>
>>>>
>>>> _______________________________________________
>>>> This list is for public discussion of the Common Alerting Protocol. This
>>>> list is NOT part of the formal record of the OASIS Emergency
>>>>Management TC.
>>>> Comments for the OASIS record should be posted using the form at
>>>> http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency
>>>> CAP-list mailing list
>>>> CAP-list at lists.incident.com
>>>> http://lists.incident.com/mailman/listinfo/cap-list
>>>>
>>>> This list is not for announcements, advertising or advocacy of any
> >>> particular program or product other than the CAP itself.
>>>>
>>>>
>>> _______________________________________________
>>> This list is for public discussion of the Common Alerting Protocol. This
>>> list is NOT part of the formal record of the OASIS Emergency Management TC.
>>> Comments for the OASIS record should be posted using the form at
>>> http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency
> >> CAP-list mailing list
>>> CAP-list at lists.incident.com
>>> http://lists.incident.com/mailman/listinfo/cap-list
>>>
>>> This list is not for announcements, advertising or advocacy of any
>>> particular program or product other than the CAP itself.
>>>
>>
>> _______________________________________________
>> This list is for public discussion of the Common Alerting Protocol. This
>> list is NOT part of the formal record of the OASIS Emergency Management TC.
>> Comments for the OASIS record should be posted using the form at
>> http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency
>> CAP-list mailing list
>> CAP-list at lists.incident.com
>> http://lists.incident.com/mailman/listinfo/cap-list
>>
>> This list is not for announcements, advertising or advocacy of any
>> particular program or product other than the CAP itself.
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><http://lists.incident.com/pipermail/cap-list/attachments/20090312/29909d94/attachment.htm>
>_______________________________________________
>This list is for public discussion of the Common Alerting Protocol.
>This list is NOT part of the formal record of the OASIS Emergency
>Management TC. Comments for the OASIS record should be posted using
>the form at
>http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency
>CAP-list mailing list
>CAP-list at lists.incident.com
>http://lists.incident.com/mailman/listinfo/cap-list
>
>This list is not for announcements, advertising or advocacy of any
>particular program or product other than the CAP itself.
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670
More information about the CAP-list
mailing list