[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 DigitalSignatures)
... >Date: Thu, 12 Mar 2009 17:16:07 -0400 >X-Google-Sender-Auth: c8791c1e6de76890 >From: matt hoffman <matthoffman@acm.org> >To: Rex Buddenberg <budden@nps.navy.mil> >Cc: "Hughes, William" <William.Hughes@co.ramsey.mn.us>, > cap-list@lists.incident.com >Subject: Re: [CAP] Then Again... (was Re: CAP Security Using > DigitalSignatures) >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 61% > >Yes, of course. The CAP spec actually requires that signatures, if present, >are "enveloped signatures" within the alert element, which means it would >apply to the whole alert (but be physically present inside it). I used the >snippet only as an example. >I think we're on the same page here, but to clarify: >The difference between XML signatures and email is that email servers >[should] never modify the contents of the email, formatting included, in >transit. XML doesn't have that guarantee; it is not uncommon in practice to >receive an XML message, deserialize it into some type of object structure >native to the application, then re-serialize it into a functionally >equivalent (but formally different) XML message. I.e. formatting is not >protected. > >What Art is suggesting is that we perform no canonicalization and treat the >XML just like an email, with the requirement that message handlers do not >alter the formatting of the message in any way. That is a very valid >suggestion; I think there are pros and cons, but it does put a requirement >on message handlers that did not previously exist. I would be more >comfortable with the decision after a.) more current implementors weigh in >on the feasibility of passing the original message through formatting >intact, and b.) getting some feel on the current state of XML >canonicalization, which apparently has moved forward in the last year. > > > > >On Thu, Mar 12, 2009 at 4:23 PM, Rex Buddenberg <budden@nps.navy.mil> wrote: > >> Matt, >> >> Note that XML sign can be applied to the whole message (making it >> equivalent to a whole-message e-mail signature, MIME this time instead of >> XML). What Art is calling the blob. >> >> But that does not prevent signing subsets of the message too. Individual >> tagged fields or groups of them. >> Order of business. I'd suggest that the greater granularity should be >> pursued only after we get a workable blob authentication working. >> >> >> >> matt hoffman wrote: >> >>> To be clear, the alteration we're talking about here isn't any kind of >>> content modification -- adding or altering fields, for example. It's >>> simply >>> formatting, primarily whitespace. For example, the two XML fragments: >>> <alert> >>> <identifier>MyMessageIdentifier</identifier> >>> <sender>me@mycompany.com</sender> >>> >>> and: >>> >>> <alert><identifier>MyMessageIdentifier</identifier><sender> >>> me@mycompany.com >>> </sender> >>> >>> are functionally identical, but would result in different XML signatures >>> as >>> they are. Thus the question of either altering the whitespace of every XML >>> message coming in to some standard, canonical form before verifying >>> signatures, or agreeing by convention to never alter a single byte of the >>> message whether it affects the content or not. Both methods are fragile >>> in >>> their own way. >>> >>> I assume that the modification that would concern you, as an originator of >>> alerts, would be modifications of content, not necessarily modifications > >> to >>> XML formatting. >>> >>> >>> >>> >>> On Thu, Mar 12, 2009 at 3:05 PM, Hughes, William < >>> William.Hughes@co.ramsey.mn.us> wrote: >>> >>> >>> >>>> Hi time top weigh in on this on the non-technical side. > >>> >>>> Since I may be an originator of CAP alerts, I and I am sure the majority >>>> of >>>> my colleagues would prefer that alerts / warnings be relayed with out >>>> alteration in anyway. >>>> >>>> Subsequent enhancement / modification of the alert by other authorities, >>>> should be a new separate message. >>>> >>>> That would help keep the audit trail clean. >>>> >>>> Thanks >>>> >>>> Bill Hughes, Mobile 651-325-5867 >>>> >>>> ----- Original Message ----- >>>> From: cap-list-bounces@lists.incident.com < >>>> cap-list-bounces@lists.incident.com> >>>> To: Art Botterell <acb@incident.com> >>>> Cc: cap-list@lists.incident.com <cap-list@lists.incident.com> >>>> Sent: Thu Mar 12 13:46:34 2009 >>>> Subject: Re: [CAP] Then Again... (was Re: CAP Security Using >>>> DigitalSignatures) >>>> >>>> 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. >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: < >>>> >>>> >>>>http://lists.incident.com/pipermail/cap-list/attachments/20090312/b5d00ccf/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. >>>> >>>> >>>> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> >>>http://lists.incident.com/pipermail/cap-list/attachments/20090312/9b33f5a2/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 Buddenberg >> Senior Lecturer >> Naval Postgraduate School >> Monterey, Ca 93943 >> 831/656-3576 >> >> >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: ><http://lists.incident.com/pipermail/cap-list/attachments/20090312/1fc8f0e8/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]