Repository for the Automation Working Group project to develop a registry for CNAs.
Please file an Issue to track new items/problems/concerns so they can be captured.
Data storage considerations:
GDPR, California Privacy, etc.
We may want to ban PII from the CVE user registry, even with informed consent they can still revoke it, potentially years later leaving holes in our data and the relationships.
One possible method to deal with this is to encourage generic organizational contacts, e.g. cve-assign@ or security@ and generic URL's to a security page/etc.
We will also need to ensure that GPG/PGP keys and so on don't include PII in the form of personal emails/etc.
DECISION: Do we ban PII? Do we simply discourage it? Do we allow it and deal with revocation of consent later?
We want data updates to be self service as much as possible.
Data to store and publish:
In light of how organizations are evolving and technology changes do we want to require an email address? Or do we simply require an email address AND/OR a URL that can be used to contact the CVE user in question?
Ideally a generic URL like https://example.org/security/cve-contact/
Ideally a generic URL like https://example.org/security/
Organization/Entity name (optional?)
We should have a name for the organization/entity, e.g. their legal name ("IBM", "IBM F-Force", etc.) but should this be required?
Member of Organization/Entity (optional?)
Should we have entities declare if they are a part of any other entity, e.g. "IBM-Force is a part of IBM")?
PGP/GnuPG key(s) identity
Since the keys quite commonly contain PII (names/etc.) it might be best to simply request the full key ID and then require they load the key into the SKS key servers (so GDPR related requests are not our problem).
Forwarding of email
Some organizations and entities will be individuals and as such may not have the ability or desire to host additional email accounts. Should we investigate offering email forwarding services so an email can be sent but the end users email address be protected? How do we store this data? (E.g. do we have them enter their real email in the data, encrypted to a key used by the service?).
DECISION: Do we support an email forwarding service? Once we provide it we can never take it back until we get everyone off of it and their records updated.
Forwarding of URLs
I do not think we should support URL forwarding as there are numerous services that can be used to provide this.