[liberationtech] Fwd: Firefox OS with built in support for OpenPGP encryption

[Eugen Leitl]

----- Forwarded message from John Sullivan <johns at fsf.org> -----

Date: Fri, 20 Sep 2013 15:04:14 -0400
From: John Sullivan <johns at fsf.org>
To: liberationtech <liberationtech at lists.stanford.edu>
Subject: Re: [liberationtech] Fwd: Firefox OS with built in support for OpenPGP encryption
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
Reply-To: liberationtech <liberationtech at lists.stanford.edu>

Blibbet <blibbet at gmail.com> writes:

>> (We call the bad version of Secure Boot, where the user does not have
>> the ability to modify the set of trusted keys or disable the system,
>> Restricted Boot.)
>>
>> We have discussed the idea of trying to become a root key holder for
>> Secure Boot, working with OEMs to by default trust GNU/Linux distro keys
>> signed by us, but have been told that the cost of complying with the
>> requirements would be in the millions. We're still interested, if anyone
>> has funding.
>
> Can you please point to the source of this "millions" comment? I see
> UEFI Forum membership as being $2500/yr max for an org, and free for
> an individual. The latter can't influence codebase and has a 3 page
> license, the former can impact codebase and has a 9 page license.
> http://www.uefi.org/join
>

Those are the costs for being just a member of UEFI -- what you were
suggesting originally was being a root key holder, able to sign
developer keys which can then be used to sign operating systems to boot
under Secure Boot equipped firmwares that ship recognizing that root
key. This would be nice, because then people wouldn't be so dependent on
Microsoft's Certificate Authority. But, this comes with the kinds of
costs you might expect from a secure operation to keep certs safe --
insurance, audits, running the process of signing developer keys, etc. I
don't know where all of the costs come from but I can see how they build
up quickly. 

> So, has FSF looked at working with an IBV or a PC OEM, about doing a
> proper UEFI-based system with a proper Secure Boot feature that works
> with Linux?
>

Some -- resources for all of this are an issue. Also depends if by
"proper" you mean that it comes enabled and preloaded with trusted keys,
in which case see above.

>> In the meantime, we would love to receive any reports of x86 systems
>> purchased with Secure Boot that actually have Restricted Boot.
>
> BTW, here's latest status from Intel UEFI w/r/t Linux, a talk from
> last week's IDF:
>
> http://uefi.blogspot.com/2013/09/uefi-at-idf13-part-2-uefi-secure-boot.html
>
> The speaker of that talk will be at a UEFI training event at a local
> hackerspace, answering questions on UEFI. If anyone has some good
> questions to ask him, I'll be happy to relay.

One thing that would make this whole mess better would be if drivers
could effectively be signed by more than one key. That would help lessen
some of the dependency on Microsoft, because drivers could be signed by
smaller party keys without having to drop Microsoft. I think this is
allowed for by policy and signing format but is not being implemented.

-john

-- 
John Sullivan | Executive Director, Free Software Foundation
GPG Key: 61A0963B | http://status.fsf.org/johns | http://fsf.org/blogs/RSS

Do you use free software? Donate to join the FSF and support freedom at
<http://www.fsf.org/register_form?referrer=8096>.
-- 
Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys at stanford.edu.

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B  47EE F46E 3489 AC89 4EC5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20130921/6869a7d4/attachment-0001.sig>