[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)
Seven. >X-Provags-ID: V01U2FsdGVkX1+nTa0SMWunwbKZg3z04qK4omcaBeq3v4UhJskqDe > hI6KejzeEoFRYv >From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> >To: "'Art Botterell'" <acb@incident.com>, > <cap-list@lists.incident.com> >Date: Thu, 12 Mar 2009 18:42:52 +0200 >Thread-Index: AcmjLS9ZcWptp+/aRvO8/uPRITWwcgABCPFg >X-Y-GMX-Trusted: 0 >X-FuHaFi: 0.48 >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% > >The W3C is currently working on a revision of their XML security standards, >see my post here: >http://www.tschofenig.priv.at/wp/?p=550 > >This should fix some of the problems. You might want to check their latest >drafts and, if you find problems, report back to them. I am sure they would >appreciate your input. > >Ciao >Hannes > > >>-----Original Message----- >>From: cap-list-bounces@lists.incident.com >>[mailto:cap-list-bounces@lists.incident.com] On Behalf Of Art Botterell >>Sent: 12 March, 2009 18:08 >>To: cap-list@lists.incident.com >>Subject: [CAP] Then Again... (was Re: CAP Security Using >>Digital Signatures) >> >>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=emer >>>> gency >>>> 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=emerg >>> ency >>> 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_abbre >>v=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]