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


Help: OASIS Mailing Lists Help | MarkMail Help

was message

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

Subject: Re: [was] The ID generation issue

I agree with the idea to delete the date from the ID.  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.

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:

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).


----- 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.
> 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.
> -- 
> 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.

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