Re: [was] The ID generation issue

["Jeff Williams" <jeff.williams@aspectsecurity.com>]

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.
    http://repository.com/evdl/thinkingstone/protect/123456

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