Alternative discovery method

[Jan Schneider]

Hi,

I'd like to propose an alternative discovery method for the
vulnerability document.

Instead of (or additionally to) using a meta-tag that requires reading
and parsing of the project's website, we should allow, and IMO even
prefer, to use /.well-known/ URIs.
See https://tools.ietf.org/html/rfc5785 for those that haven't been in
touch with those kind of URIs so far.

This methodology would simplify the automated discovery of
vulnerability databases a lot.

Thoughts?

Jan.


--
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject

[Lukas Kahwe Smith]

> On 22 May 2015, at 13:15, Jan Schneider <j...@horde.org> wrote:
>
> Hi,
>
> I'd like to propose an alternative discovery method for the vulnerability document.
>
> Instead of (or additionally to) using a meta-tag that requires reading and parsing of the project's website, we should allow, and IMO even prefer, to use /.well-known/ URIs.
> See https://tools.ietf.org/html/rfc5785 for those that haven't been in touch with those kind of URIs so far.
>
> This methodology would simplify the automated discovery of vulnerability databases a lot.
>
> Thoughts?

Sounds interesting. The RFC is currently in the state "PROPOSED STANDARD”.
At any rate, the link relations we define in PSR-9/PSR-10 are optional and as such I think we do not disallow any alternative approach. I am not sure if the above standard is sufficiently used yet, so that people will actually realize that such a document/directory may even exist. IMHO the advantage of the link relation is that it follows the REST idea where anything can be found by simply traversing from the root page of a domain.

We could of course define a specific “name” to register for this as part of the PSRs

"For example, if an application registers the name 'example', the
corresponding well-known URI on 'http://www.example.com/' would be
'http://www.example.com/.well-known/example'."

At this point I am however -0.5 on this because I am unsure about the value of adding a little known RFC to this PSR.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

[Jan Schneider]

Zitat von Lukas Kahwe Smith <sm...@pooteeweet.org>:

>> On 22 May 2015, at 13:15, Jan Schneider <j...@horde.org> wrote:
>>
>> Hi,
>>
>> I'd like to propose an alternative discovery method for the
>> vulnerability document.
>>
>> Instead of (or additionally to) using a meta-tag that requires
>> reading and parsing of the project's website, we should allow, and
>> IMO even prefer, to use /.well-known/ URIs.
>> See https://tools.ietf.org/html/rfc5785 for those that haven't been
>> in touch with those kind of URIs so far.
>>
>> This methodology would simplify the automated discovery of
>> vulnerability databases a lot.
>>
>> Thoughts?
>
> Sounds interesting. The RFC is currently in the state "PROPOSED STANDARD”.
> At any rate, the link relations we define in PSR-9/PSR-10 are
> optional and as such I think we do not disallow any alternative
> approach. I am not sure if the above standard is sufficiently used
> yet, so that people will actually realize that such a
> document/directory may even exist. IMHO the advantage of the link
> relation is that it follows the REST idea where anything can be
> found by simply traversing from the root page of a domain.

What does the link tag have to do with REST? Beside that, even if
using this tag, people (or bots) need to know about the meta tag name
too. To document where and how to find the security list is the target
of this PSR, so there's obviously some need for documentation anyway.
And I doubt that anyone will by accident stumble over this link by
accessing the home page and looking at the source code.
So it boils down to automated tools that need to finde the vuln
information, and these tools will follow this PSR. And I still think
that following the /.well-known/ URL with a standard HTTP client that
supports redirection is much easier than parsing the root document of
a website.

> We could of course define a specific “name” to register for this as
> part of the PSRs
>
> "For example, if an application registers the name 'example', the
> corresponding well-known URI on 'http://www.example.com/' would be
> 'http://www.example.com/.well-known/example'."
>
> At this point I am however -0.5 on this because I am unsure about
> the value of adding a little known RFC to this PSR.

This is not little known at all, but in wide use for example in the
CalDAV/CardDAV world.

[Lukas Kahwe Smith]

> On 26 May 2015, at 12:57, Jan Schneider <j...@horde.org> wrote:
>
>
> Zitat von Lukas Kahwe Smith <sm...@pooteeweet.org>:
>
>>> On 22 May 2015, at 13:15, Jan Schneider <j...@horde.org> wrote:
>>>
>>> Hi,
>>>
>>> I'd like to propose an alternative discovery method for the vulnerability document.
>>>
>>> Instead of (or additionally to) using a meta-tag that requires reading and parsing of the project's website, we should allow, and IMO even prefer, to use /.well-known/ URIs.
>>> See https://tools.ietf.org/html/rfc5785 for those that haven't been in touch with those kind of URIs so far.
>>>
>>> This methodology would simplify the automated discovery of vulnerability databases a lot.
>>>
>>> Thoughts?
>>
>> Sounds interesting. The RFC is currently in the state "PROPOSED STANDARD”.
>> At any rate, the link relations we define in PSR-9/PSR-10 are optional and as such I think we do not disallow any alternative approach. I am not sure if the above standard is sufficiently used yet, so that people will actually realize that such a document/directory may even exist. IMHO the advantage of the link relation is that it follows the REST idea where anything can be found by simply traversing from the root page of a domain.
>
> What does the link tag have to do with REST? Beside that, even if using this tag, people (or bots) need to know about the meta tag name

everything .. REST is about machines (and users) to discover all resources by traversing from the root.

ie. I go to www.example.org, I find a link relation, I follow that.

> too. To document where and how to find the security list is the target of this PSR, so there's obviously some need for documentation anyway. And I doubt that anyone will by accident stumble over this link by accessing the home page and looking at the source code.
> So it boils down to automated tools that need to finde the vuln information, and these tools will follow this PSR. And I still think that following the /.well-known/ URL with a standard HTTP client that supports redirection is much easier than parsing the root document of a website.

yes .. people need to understand the semantics of the link relations. but this is also the case with the .well-known URL .. the only difference is that you do not know about .well-known you will not even know to look for it, where are a link relation will be discovered by examining the content of the root page and if you do not know what the link relation means, you can go look it up.

anyway .. the two can of course be complementary, ie. you can use a .well-known URL in your link relation.

>> We could of course define a specific “name” to register for this as part of the PSRs
>>
>> "For example, if an application registers the name 'example', the
>> corresponding well-known URI on 'http://www.example.com/' would be
>> 'http://www.example.com/.well-known/example'."
>>
>> At this point I am however -0.5 on this because I am unsure about the value of adding a little known RFC to this PSR.
>
> This is not little known at all, but in wide use for example in the CalDAV/CardDAV world.

ok .. wasn’t aware of that.

[enygma]

In just some casual searching, I didn't really come across much outside of the CalDAV/CardDAV world that's using this format. Most of the resources around it are several years old in fact. I'm not saying it's not a good standard, I just don't know if it's a good fit for what we're going for here. I wonder if we should possibly amend the proposal and enforce a common name/location rather than just allowing them to specify. From what I've seen with other projects/companies, they provide a single source (usually an RSS feed though) of vulnerability information.

The kind of aggregation we're talking about here isn't really something there's much of a precedent for, even in the security community. Normally it's a single body, like with the CVEs, that's reporting on behalf of other projects. Even things like the WP Vulnerability DB (https://wpvulndb.com) just have an RSS feed and vulnerability notices usually just come in the form of blog posts or mailing list announcements. 

If we're going to go the ".well-known" route, we'd still have to define a common place (ex: "/.well-known/vulns") so they know where to look. If we're going to do that, then why use "well-known" at all, other than the fact that it's a standard used in some places?

[Lukas Kahwe Smith]

This was kind of my idea with:
https://github.com/php-fig/fig-standards/pull/562/files#diff-90c9cfb955d18a543b5447692c1544f8R66

ie. we the standard would be less strict about specific locations etc but with the “defaults” we nudge people to one approach. the end result could then be people saying:
we follow PSR-9 defaults except for A and B where we do X and Y