[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-msg] cap:image and cap:audio
> -----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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]