OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Perhaps we are thinking to hard about this issue. I, for one, would be
against including anything but a reference to a secondary resource in a
CAP message. As an implementor, it does not give me the ability to
decide how my implementation deals with potentially large files. That
being said, would the following not be true:

If a resource is static (ie: you do not want it to change), then the
sender of the CAP message MUST include the resource on a server they
control, and can therefore also control the security of that server -
its "trusted." In this case, the URI could be absolute or relative.

If the resource is dynamic (ie: you want to point to the latest and
greatest), then all you really can do is point to it. Let's be honest,
the only person anyone can really trust is themselves, and heck some
people can't do that :)

That being said, maybe the solution is to put in an attribute that
specifies if the resource is external (not in my network/control) or
internal (default, but can explicitly state it is in my
network/control). This allows the implementor to determine if the source
is trusted or not.

Thoughts?

On Mon, 2003-07-07 at 23:34, Nasseam Elkarra wrote:
> > The spec as it stands carries audio files and images as references to
> > the actual files.  While this reduces the size of the alert message,
> it
> > has a disadvantage.  If the message is digitally signed, the
> protection
> > this provides is not extended to the image/audio files.  So a hacker
> > could replace the picture of a missing child with one of Mickey Mouse
> > for example, and the security and validation mechanisms would not
> detect
> > the alteration.
> 
> Digitally signing the document includes the references so that should be
> sufficient. A hacker would have to compromise the server holding the
> multimedia files in order to be effective. A very possible scenario, but
> taking into account that security aware agencies will be issuing CAP
> alerts (hopefully!), we can assume that this scenario is highly
> unlikely. If CAP issuers are pointing to multimedia files on another
> party's server, we should recommend a local copy be made and that the
> CAP alert point to that file instead.
> 
> I am being very optimistic because the truth is that hackers are a
> problem. But CAP should not have to take into account all security
> problems because it could get very bloated. Nonetheless, this topic is
> an important one and I would like to hear what others have to say.
> 
> > I suggest we may want to actually embed the files in the xml document
> > (as Base64 encoded strings perhaps), so that the message integrity can
> > be verified.
> 
> Base64 encoding increases size by 33% plus you have to remember the
> encoding/decoding process. I would prefer some kind of attachments
> scheme similar to email attachments or SOAP with attachments where the
> XML document refers to files that are coming up right behind it using
> MIME/DIME.
> 
> Until next time,
> Nasseam Elkarra
> nelkarra@opensec.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: emergency-msg-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: emergency-msg-help@lists.oasis-open.org
-- 
R. Allen Wyke
Chair, Emergency Management TC
emtc@nc.rr.com
http://www.oasis-open.org/committees/emergency



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]