Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow CNAs to embed data into their CNA listing #20

Open
EvansJonathan opened this issue Jul 25, 2017 · 6 comments
Open

Allow CNAs to embed data into their CNA listing #20

EvansJonathan opened this issue Jul 25, 2017 · 6 comments

Comments

@EvansJonathan
Copy link
Contributor

EvansJonathan commented Jul 25, 2017

Proposer: Kurt Seifried

GOAL:
CHANGE: Should we also allow projects/etc. to simply embed the data into their CNA listing, especially if it is "simple" (e.g. an Open Source project with a single software project, or a project with multiple projects that are well defined (e.g. within their GitHub organization) where they cover "everything" for example
OUTCOME:

@EvansJonathan
Copy link
Contributor Author

I am not entirely sure what "data" this is talking about.

@kurtseifried
Copy link

@dadinolfi
Copy link
Contributor

I'm not sure what the suggestion is here. Right now, we keep a public listing of CNA scopes here:

http://cve.mitre.org/cve/request_id.html#cna_coverage

When you say "CNA Listing", what are you referring to? Already, Root CNAs are required to maintain a public list of their Sub-CNAs and their scopes and make that available to the Primary CNA, per 3.2.2.1. (What you are doing with the DWF satisfies that requirement.)

What more did you have in mind?

@chandanbn
Copy link

FIRST SIG on vulnerability coordination is working on standardizing vendor contact information, mainly as a set of standard key value pairs expressed in YAML or JSON, for eg.,

vendor: vendor name
also-known-as: !!set { alias1, alias2, alias3 } 
email:  !!set { email1, email2, email3 }
max-response-time: business hours/days
PGP: PGP key
advisory-location: 
disclosure-policy-URL: 
escalation-path: alternate contact
updated: 
...

The aim is to help security researchers or vendors to find correct contacts, set expectations about what is in scope and what is not etc., The same format be used here by CNAs to provide information about themselves. Think of this as digital business cards for vendors or CNAs.

@dadinolfi
Copy link
Contributor

Making use of the FIRST SIG's work seems ideal. I would prefer to not explicitly include a reference to their work yet unless it is finalized. But I want to make use of existing standards instead of inventing another one just for us.

From a CNA Rules standpoint, would we need to make a change to make use of this standard, for example, or would it just be the standard used by the Primary, recommended to the Roots, and required for the Sub-CNAs if their Root (or the Primary if they don't have a Root) uses it?

@ghost
Copy link

ghost commented Sep 15, 2017

@dadinolfi assuming the SIG requirements/standard works for us then I would have no problem adopting it for the DWF hierarchy of CNAs. Can someone provide a link to the actual standard/docs (does that exist yet?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants