[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: [CAP] Then Again... (was Re: CAP Security Using DigitalSignatures)
Five. >X-YMail-OSG: >T0xrsPoVM1ky02Vnb4qIly5Z7ZDjJe4aqIlU1Q9ZgG8W_Z_5gKZvMFZk_e2grFD9wxxR4j7jpLQ2yJ.BkQAQEus1H8j5Is6YyRwEKFwQeaqRnaIRq_5lfi8OLQ9xzUBdR1Qmqa_c2qG1VAFvHgNXCv1mlTsLA6.whkJ6z3NwOICDlaHfKfh3.8HXAmfekr4c >X-Yahoo-Newman-Property: ymail-3 >From: Art Botterell <acb@incident.com> >To: cap-list@lists.incident.com >Date: Thu, 12 Mar 2009 09:08:08 -0700 >Subject: [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% > >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. -- 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]