[CAP] Then Again... (was Re: CAP SecurityUsingDigitalSignatures)

[Mick Jagger]

> Hardly keeping up on this, but I would assume the serial approach would 
> be the faster of the two in most instances.

	No the serializing approach would be slower.  I'm going to assume 3 basic roles for using CAP messages, producer, consumer and intermediary (aggregator/gateway/etc).  I think that all 3 would benefit from storing the serialized/ORM/internal representation of the CAP message to aid processing of the message.  This offers a performance benefit because you do the DSig check only once along with other XML processing and get the XML into a form that may be more suitable/native for your application.  Its wise to store this for future reference to save duplication of "input" effort.  
	In the case of the consumer though, they don't have any need to share this alert with anyone else, its the end of the line.  The others do have to share, and its not suitable to share this serialized format with others, it needs to be in XML.  Its much more efficient to "output" this XML once and save it either to a file or a blob in your DB, then when someone asks for the XML, you don't go through the process of serializing, adding DSig, etc each and every time.  It also allows you to cache the XML and perhaps not even hit your database at all.  For the intermediary it reduces the reliance on c14n and the chance of altering the message, breaking the DSig.

	With regards to "sign the blob", the CAP spec is relatively clear on enveloped XML signatures.  Other blob signing methods would mean additional wrapping that would cause schema incompatibility problems.  However there is an interesting, if not standard, method to accomplish this,
<?xml version="1.0"  encoding="UTF-8"?>
<!--
=====BEGIN PGP SIGNED MESSAGE=====
=====END PGP SIGNATURE=====
-->
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
...

	With regards to the CAP schema validation problems of XML signatures.  The spec is pretty clear on how XML sigs are to processed by both DSig aware and not aware clients.  However its probably safe to assume that may implementers who don't intend to implement DSig, skip over this section and just go straight to using the schema for validation.  So when a message comes along with an XML sig, their system is going to choke on it.  It might be prudent to add the following lines to the CAP schema in future versions to accomodate this. Thoughts??

<any minOccurs="0" maxOccurs="1" namespace="http://www.w3.org/2000/09/xmldsig#" processContents="lax"/>
<any minOccurs="0" maxOccurs="1" namespace="http://www.w3.org/2001/04/xmlenc#" processContents="lax"/>

-- 
lists at jpw.biz
--