Re: [was] The ID generation issue

[Peter Michalek <peter@michalek.org>]

Ivan Ristic wrote:

> Peter Michalek wrote:
>
>>
>>>   Well, I'd really like to see the parts be independent from each
>>>   other. Otherwise I don't see who will adopt them as standard.
>>>   Vulnerability scanner people are not interested in metadata or
>>>   protect. Web application firewall people are not interested in
>>>   anything but Protect. And so on...
>>
>>
>> I think in general all "security domain" providers will be intersted 
>> in the generic parts: profile and metadata.
>
>
>   That's why we must seek their active participation as soon as
>   we come out with a draft of some kind.

Absolutely. I hear OVAL people will participate in an upcoming confcall.

>
>
>> However, we still need to provide a way to reference another instance 
>> by ID - which we already do in the schema (we need to make sure this 
>> sample validates, I just posted it):
>>
>> http://www.evdl.net/latest/examples/example-protect-by-ref-1.xml
>
>
>   Hmm, where is the reference in this example? The ID? Or did you mean
>   the other example:

The reference is by id of the recipe (This is also captured in over doc 
chapter 4.3 "Protect Component Example with Referenced Metadata"):

<recipe id="evdl.net-2-11-2005-2">

>
>   http://www.evdl.net/latest/examples/example-protect-by-ref-url-1.xml
>
>   Either way, Protect (Detect & SCA too) needs a way to reference
>   entries in other vulnerability databases. For example:
>
>   <recipe ...>
>   <references>
>       <reference publisher="bugtraq" id="133" />
>       <reference publisher="cve" id="1999-0060" />
>       <reference publisher="other" 
> id="http://security.e-matters.de/advisories/112004.html"; />
>   </references>
>   ...
>   </recipe>



>
>   (I am aware of the references section in the Profile part, this is
>    just an example.)
>
>   I am struggling with myself to decide whether any of the SCA, Protect,
>   and Detect parts need to include the Profile part. I can see how the
>   Metadata part is needed so that's fine. But the profile part seems to
>   complex. I'll give the schema a good look and we'll talk about this
>   on Wednesday.
>
OK, let's discuss at next confcall.

Yes, it exists in profile, but I don't think it's too complex: it 
contains the basic information appsec tools need to deal with.
If profile is optional, you can avoid using it.
Perhaps what you are after is to have finer granurality with respect to 
optional nodes within profile nodeset, which I think would be fine.

I think this again can be resolved by solving versioning in a more 
comprehensive manner (see my previous email).

Peter