On Mon, 2 May 2016 16:29:12 -0600
Simon Glass wrote:
Hey Simon, sorry for the delayed response!
> Hi Teddy,
>
> On 2 May 2016 at 02:57, Teddy Reed wrote:
> > On Sun, May 1, 2016 at 11:56 AM, Simon Glass wrote:
> >> Hi Teddy,
> >>
> >> On 27 April 2016 at 11:32, Teddy Reed wrote:
> >>> Hello
Hi Teddy,
On 2 May 2016 at 02:57, Teddy Reed wrote:
> On Sun, May 1, 2016 at 11:56 AM, Simon Glass wrote:
>> Hi Teddy,
>>
>> On 27 April 2016 at 11:32, Teddy Reed wrote:
>>> Hello all,
>>>
>>> I'm looking to support "multiple levels" of keys within u-boot's
>>> verified boot. I need something s
On Sun, May 1, 2016 at 11:56 AM, Simon Glass wrote:
> Hi Teddy,
>
> On 27 April 2016 at 11:32, Teddy Reed wrote:
>> Hello all,
>>
>> I'm looking to support "multiple levels" of keys within u-boot's
>> verified boot. I need something similar to UEFI's key enrollment key
>> (KEK) and db/dbx model s
Hi Teddy,
On 27 April 2016 at 11:32, Teddy Reed wrote:
> Hello all,
>
> I'm looking to support "multiple levels" of keys within u-boot's
> verified boot. I need something similar to UEFI's key enrollment key
> (KEK) and db/dbx model such that I can support on-line signing of new
> kernels/rootfs/
Hello all,
I'm looking to support "multiple levels" of keys within u-boot's
verified boot. I need something similar to UEFI's key enrollment key
(KEK) and db/dbx model such that I can support on-line signing of new
kernels/rootfs/configurations.
To make this work we need a KEK that is not online
5 matches
Mail list logo
