[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: Re: EVDL]
--- 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 ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]