[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: Re: [was] The ID generation issue]
--- Begin Message ---
- From: Robin Cover <robin@oasis-open.org>
- To: Peter Michalek <peter@michalek.org>
- Date: Tue, 8 Feb 2005 18:08:49 -0500 (EST)
FYI just in case: W3C spec on xml:id now a CR http://www.w3.org/TR/2005/CR-xml-id-20050208/ -rcc --------- On Tue, 8 Feb 2005, Peter Michalek wrote: > Jeff, Ivan, > excellent observations and suggestions. > -- > In order to analyze and understand what exactly we are solving here and > what might be the scope of a comprehensive solution, here is my > interpretation and comment. > > The original post and response deal with these issues: > > 1 - ID uniqueness and creation > a - make sure they are unique > b - make sure they are not confusing (e.g because of wasteful redundancy) > c - ID and vuln instance versioning - i.e. ID evolution, if any, > through modification of a vulnerability instance > caused by auditing process and addition of new domain > descriptions, e.g. adding detect to analysis > 2 - access of EVDL databases > a - access to vulnerability document identified by an ID and URL > b - access to individual security domain components, such as protect, > detect, analysis > > Other issues that are not addressed here but whose resolution may drive > decision making to resolve 1 and 2: > > 3 - what's going to be a typical storage model of EVDL at an enterprise? > a - will the company want to store multiple security domains in one > document instance or separate document instances? > - this will influence if they'd prefer 1c to be solved > > My inline comments and questions are marked by "PM>" and accompanies by > issue number. > > > > I agree with the idea to delete the date from the ID. > > PM> Date: Issues 2b, date could be deleted (but it doesn't improve > anything). > Another approach would be to change the wording of ID creation to > suggest that date is optional. > {company-specific-prefix}-foundstone.com-0001 > or foundstone.com-0001-{optional-date}-{company-specific-data} > > I think the reasoning behind the original ID formula and inclusion of > date was similarity with CVE ids which I think contains dates to make > IDS more human-readable. > > > I also like the idea behind the URI approach to ID's. But I think > > that the ID should be separate from the location of the repository > > where the evdl entries are stored. > > http://repository.com/evdl/thinkingstone/protect/123456 > > > > > > Issue 1c and 2b > As far as having different IDs for different components, keeping it > simple would be nice. > > Another way of accessing security domain specific part within a EVDL > instance is using XPATH expression, e.g.: > $repositoryURL?id=123456#evdl/protect > (see more on 1c below) > > > Your point about different parts of the EVDL having different IDs is > > interesting. Personally, I would like to make sure that all the EVDL > > parts related to a single vulnerability can be correlated somehow. So > > if there's an analyze element, a protect element, and two different > > protect elements that all are related to the same problem, I want to > > find them all. But I think there may be many-to-one relationships > > among these different pieces. That leads me to something like: > > http://repository.com/evdl/123456/protect/thinkingstone > > http://repository.com/evdl/123456/analyze/aspectsecurity > > http://repository.com/evdl/123456/detect/webkreator > > > > > Essentially the 123456 becomes the reference to the underlying problem > > being discussed. I do not know how to solve the problem of dealing > > with related issues (other than listing them in the schema somewhere > > -- which I seem to recall we already do). > > > > > > --Jeff > > > > ----- Original Message ----- From: "Ivan Ristic" <ivanr@webkreator.com> > > To: <was@lists.oasis-open.org> > > Sent: Friday, February 04, 2005 5:46 AM > > Subject: [was] The ID generation issue > > > > > >> > >> Here are my thoughts on this issue: > >> > >> I don't think the current algorithm is satisfactory because it uses > >> the release date as part of the ID. As a reminder here's what the > >> schema says about this: > >> > >> --- > >> The ID element provides a mechanism to declare uniquely identifiable > >> attributes for cataloging and referencing. > >> > >> The provider, author and vendor IDs allow cross referencing and trust > >> models to be developed based on the source of the test case. > >> > >> Note: Need to define the XML:DigSig for these attributes and provide > >> for a mechanism to sign an entire file (ie provide authenticity and > >> integrity of the file outside of transport security). > >> > >> The ID Element should be derived from the following pieces of > >> information: > >> > >> 1. Organization Label / Name - ex: Foundstone, in the case of large > >> organization it is their responsibility to maintain organization > >> level uniqueness. ... TODO: Define legal characters. > >> > >> 2. Current date - YYYY-MM-DD TODO: > >> > >> Thus a sample ID is: 2004-03-31-foundstone.com-0001 > >> > >> The id part after the company name should be unique within the > >> company (i.e. last part of id namespace needs to be managed by the > >> company. > >> --- > >> > >> What happens when there is a revision? Is the ID supposed to change > >> to incorporate the date of the revision release or not? In any case, > >> I don't see a strong point for having the date as part of the ID. > > > PM> Issue 1c: > Versioning as proposed in this version doesn't change the original ID. > The "history" tag is intended to allow modifications to an instance > while keeping ID the same. > See http://www.evdl.net/latest/examples/example-sca-1.xml > > > >> > >> > >> 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 (as an ID): > > > > >> > >> 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 probably better to use the following format: > >> > >> 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 an ID is all > >> a device needs to retrieve the XML data. > >> > PM> > Issues 1c > Ivan in 3.: What happens if the same instance if stored in a different > location? > > We could treat individual security domains / components as revision to > the primary instance. > Then we could first solve approach to revision identification which > would automatically include being able to identify component. > > To access a particular component within an instance, given a repository > location and the vulnID, we could use XPATH. > > > For those of you who haven't seen the EVDL Overview doc, please note > that defining how vulnerabilities are stored is a chapter (currently > empty) we are working on in the EVDL overview document: > http://www.oasis-open.org/apps/org/workgroup/was/download.php/11288/EVDL-0.1-draft.doc > > > > > > >> -- > >> Ivan Ristic (http://www.modsecurity.org) > >> > > > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/was/members/leave_workgroup.php. > > ----- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]