qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json"


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json"
Date: Wed, 18 Apr 2018 15:30:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]