[CAP] Then Again... (was Re: CAP Security Using Digital Signatures)

Thu Mar 12 09:42:52 PDT 2009

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 at lists.incident.com 
>[mailto:cap-list-bounces at lists.incident.com] On Behalf Of Art Botterell
>Sent: 12 March, 2009 18:08
>To: cap-list at 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 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=emer
>>> gency
>>> 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=emerg
>> ency
>> 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_abbre
>v=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.
>