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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
