-
Notifications
You must be signed in to change notification settings - Fork 15
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
Provide CNA membership oracle #17
Comments
Restrict query to someone with a working API key? |
Note, this is the "strict" version of an Oracle, in that it doesn't return an email address -- you must provide one and get the appropriate answer. I think that if you know an email address, you probably already have a guess at the CNA shortname. Though, I suppose, you could learn (or guess) an email address in the context of "Oh so and so said they were a CNA, but didn't say where." This is almost always going to be because of a communication failure, and not intentional secrecy. I don't see a problem with providing shortname as a yes, blank if no. BTW some people (I can think of two, there are probably more) are involved in multiple CNAs. So if the answer is |
The other use case for an oracle would be "Who is the CNA at example.com?" Answer: [email protected] This is far more invasive. It would almost have to be opt-out by default, and opt-out-able at any time, for GDPR reasons (I'm, unfortunately, not a lawyer). It also goes beyond what is provided on the public https://www.cve.org/PartnerInformation/ListofPartners registry, which is filled with non-human email addresses. |
Anyway, you could securify the thing by rate limiting, requiring an active CNA API key, all that. |
Discussed at the Summit on 2023-03-22:
Given an email address, return either 1.) just a boolean that the account is an active user at a known CNA or 2.) the shortname of the CNA.
Should such a query be restricted to certain RSUS roles? Available to the anyone?
Any risk in anyone being able to guess an email address then find out the CNA shortname?
CC @todb
The text was updated successfully, but these errors were encountered: