blockchain for CVE (was re: Notice of Pilot Activity in CVE Auto WG)

[Art Manion <amanion@cert.org>]

On 5/9/17 3:41 PM, Kurt Seifried wrote:
>     I won't claim to be a blockchain expert, but I've talked with 
> colleagues
>     at CERT/CC about a model to sign assertions about vulnerabilities 
> (e.g.,
>     Red Hat claims a blob of vulnerability information is correct, 
> CERT/CC
>     agrees and signs, somebody else disagrees and signs...).
>
> So without getting to in depth there's a bunch of different properties
> you can have in blockchains for various use cases (e.g. a currency 
> vs. a
> land title vs. an insurance records blockchain). The main thing would 
> be
> defining what we want with respect to CVE, do we want to be able to 
> roll
> back transactions and "delete" data? or do we make it inviolate? how
> many entities have to vote/what weighting is used? do we want side
> chains for privacy (e.g. embargoed issues)? and so on. Part of my
> current goal is to get operational experience sharing the data so we 
> can
> figure out what properties we actually need (e.g. in picking git one
> aspect is we can get rid of stuff, but it's not "deleted", but I think
> this is ok because once you publish stuff on the Internet, well, you
> can't really scrub it off any ways). 

I'd say keep all the transactions, there's value in saying that
something was assigned/claimed and later revoked or changed.

And CVE should stay out of embargos/non-public vulnerability
coordination.  There might be a state for "CVE assigned but not public
yet," or perhaps just a little more, to support CNAs that do work with
emgbargos, but that's about it.  Vulnerability identification is a big
enough problem :)

 - Art