On 04/18/18 15:06, Gerd Hoffmann wrote:
>> Other question: Do we want allow to specify which certs/keys
are
>> enrolled? Which would probably mean to drop "enrolled-keys" from
>> features and make it an optional string instead,
>
> Not an enum? "Microsoft" below should be an enum constant, shouldn't
it?
I don't think so. If we want allow other certificate providers (not
sure it makes sense as all physical hardware actually runs with the
microsoft certificates), then we don't want a fixed list here. So any
CA can be listed, be it microsoft, redhat, canonical, verisign or
kraxel.org ;)
I agree (obviously), but then, at what detail do we stop?
Because, if we go for full flexibility, then we should formalize:
- the certificate that goes into PK,
- the list of certificates that go into KEK,
- the list of certificates that go into db,
and we should likely formalize "certificate" itself as the following pair:
- human-readable description (possibly the Common Name of the Subject),
- SHA256 digest (fingerprint) of the certificate.
I do think this would totally be overkill, but I don't know where to
draw the line
- between the currently proposed @enrolled-keys (or similar enums that
stand for well-defined "constellations")
- and the full details as described above.
A simple string like "Microsoft" doesn't seem to me helpful for either
the user or management software -- the former won't know what
"Microsoft" stands for, and the latter won't want to look for free-form
strings. (Same issue as with @tags vs. @features.)
Thanks
Laszlo