[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: Re: [CAP] Then Again... (was Re: CAP Security Using Digital Signatures)
Eleven. Cheers, Rex >Date: Thu, 12 Mar 2009 14:46:34 -0400 >X-Google-Sender-Auth: 8a1c289e188b597b >From: matt hoffman <matthoffman@acm.org> >To: Art Botterell <acb@incident.com> >Cc: cap-list@lists.incident.com >Subject: Re: [CAP] Then Again... (was Re: CAP Security Using Digital > Signatures) >X-BeenThere: cap-list@lists.incident.com >List-Id: Common Alerting Protocol Public Discussion > <cap-list.lists.incident.com> >List-Unsubscribe: <http://lists.incident.com/mailman/options/cap-list>, > <mailto:cap-list-request@lists.incident.com?subject=unsubscribe> >List-Archive: <http://lists.incident.com/pipermail/cap-list> >List-Post: <mailto:cap-list@lists.incident.com> >List-Help: <mailto:cap-list-request@lists.incident.com?subject=help> >List-Subscribe: <http://lists.incident.com/mailman/listinfo/cap-list>, > <mailto:cap-list-request@lists.incident.com?subject=subscribe> >Sender: cap-list-bounces@lists.incident.com >X-Nonspam: Statistical 54% > >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@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@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@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@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@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@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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]