Signing Things
Design principles:
- no cutting your own {crypto,certificate systems,HSM}
Bad things that can happen:
- build server compromise
- pointyhat compromise
- key compromise
- mirror compromise / middleperson
- interference with revocation
- trojans / vulnerabilities that don't affect infrastructure - basically VuXML
Straw man proposal:
- FreeBSD CA - what about other uses?
- master package set signing key
- long-lived, offline-ish
- used monthly / quarterly
- shorter-life key for weekly / daily package sets (online)
- separate signing server allows the secure expression of policy
- install-time checks of meta-data (SQLite database)
- untrusted mirrors
- reproducible by enterprise / etc.
Ideas:
- link keys to policy
- separate key policy from package policy
- external sources of revocation
Things and ways to revoke:
- a specific package set (builder compromise)
- named by hash of repo.txz
- named by metadata (versions, build servers, build date, toolchain, ...)
- packages
- by name, version ID - ranges?
- specific build
- other meta-data (same as above) ... origin (e.g. KDE)?
- keys
Next steps:
- start signing things (but not distribute yet)
- move to standard infrastructure (get rid of PGP)