RE: [emergency-msg] cap:image and cap:audio

["Nasseam Elkarra" <nelkarra@opensec.org>]

> -----Original Message-----
> From: Allen Wyke [mailto:emtc@nc.rr.com]
> Sent: Friday, July 18, 2003 5:34 AM
> Subject: RE: [emergency-msg] cap:image and cap:audio
> 
> The way to resolve the URI issue, which is different than the
encryption
> issue (although related), is simple. It lies in 2 questions:
> 
> 1. What is our potential adoption rate increase/decrease by
including/not
> including attachments?

It has always been my observation (although not always true) that
security and hence the complexity of a technology is directly related to
the adoption rate. This is a very unfortunate relationship and has lead
to an ease-of-use over security model that has led to many preventable
security problems.

Nonetheless, CAP should incorporate simple file integrity elements to
insure some level of security for those interested. 

This:
<cap:image size="16342"
checksum="5AA363330494600AB2A5C77580F49AF3">http://www.dhs.gov/dhspublic
/getAdvisoryImage</cap:image>

Is much easier than this:

MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
        start="<cap.xml@example.com>"

--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <cap.xml@example.com>

<?xml version='1.0' ?>
<cap:alert>
..
<cap:image href="cid:image.gif@example.com"/>
..
</cap:alert>

--MIME_boundary
Content-Type: image/gif
Content-Transfer-Encoding: binary
Content-ID: <image.gif@example.com>

...binary GIF image...
--MIME_boundary--


This is modeled after SOAP with Attachments and you could actually use
SOAP and have a CAP alert in the payload of the SOAP message but to
avoid coupling CAP with SOAP I demonstrated a MIME-only solution.

As you can see, using attachments has a lot of negatives. The biggest
being you lose a pure XML solution and bring an added layer of
complexity to CAP.

> 2. If the adoption rate shows a significant enough increase, then what
is
> the best way to handle the one-way use case?

A good example of a common one-way message is a security advisory. To
solve authentication problems, advisory issuers tend to sign their
advisories with PGP keys. To solve file integrity problems, issuers
provide a checksum and/or file size for you to use for verification.

If system administrators trust these security measures for a patch that
has potential to do much more damage then an image, we should consider
it a good option. The checksum approach also wins for familiarity
amongst the security crowd.

So my final suggestion is:
<cap:image size="16342"
checksum="5AA363330494600AB2A5C77580F49AF3">http://www.dhs.gov/dhspublic
/getAdvisoryImage</cap:image>

Where the size is in bytes and the checksum is created using the MD5
algorithm.

Whether or not to make these optional, that's another story. Here we go
again...

Nasseam Elkarra
nelkarra@opensec.org