[Fwd: Re: EVDL]

[Peter Michalek <peter@michalek.org>]

--- Begin Message ---

• From: Ivan Ristic <ivanr@webkreator.com>
• To: Peter Michalek <peter@michalek.org>
• Date: Wed, 19 Jan 2005 14:39:52 +0000

Hi Peter,

I won't be able to make it for the conference call today. I seem to be 
desperately busy these days. I will make sure I attend the next time. It 
would be great if we would to start using email to get things done.

I did make some effort to do what I was supposed to do:

1. I got in touch with Dinis. He appeared to be interested to attend the 
today's conference. Please forward him an email with the conference details.

2. I made an effort to use the Protect schema for several real-life 
vulnerabilities. I haven't prepared anything in writing but I didn't 
notice any problems. I did encounter some vulnerabilities the Protect 
schema could not protect from but those were application logic problems 
- I doubt anything much can be done on the outside to guard those.

3. I reviewed the ID generation issue. I don't think the current 
algorithm is satisfactory because it uses the release date as part of 
the ID. What happens when there is a revision? Will the ID change to 
incorporate the date of the revision release or not? In any case, I 
don't see a point of having the date as part of the ID.

Furthermore, we need to consider the requirement of every EVDL part to 
have an ID of its own. Personally I would like to see something like this:

http://www.thinkingstone.com/evdl/protect/123456

or

  * http://www.thinkingstone.com/evdl = unique ID of the publisher
  * 123456 - instance ID (unique on the publisher level)
  * protect - EVDL part name

In fact, maybe it's more correct to use:

http://www.thinkingstone.com/evdl/123456/protect
http://www.thinkingstone.com/evdl/123456/protect

Using an ID of this form would achieve the following:

  1. Assign a unique ID to a schema instance
  2. Allow different parts to have different IDs but
     related parts to have a common base
  3. Allow a device to retrieve an instance from a publisher's
     web site just by accessing the URL. Therefore it won't be
     necessary to maintain a map (uniquePublisherId -> URL).

4. I looked at all the EVDL parts again. I am a little concerned the 
standard is getting too complex. I don't think there will be any single 
company interested to implement all of it. Therefore I think we should 
increase the effort to break it into independent parts.

Please forward my email to the list. Thanks!

-- 
Ivan Ristic (http://www.modsecurity.org)

--- End Message ---