*countable infinities only
jays at panix.com
Thu Jun 14 19:46:59 UTC 2012
Please forgive this top posting.
I will not answer now your radical defense of Microsoft, except to
say two things:
1. Your defense would apply also to the decades long fraud of
Microsoft saying in their EULA that, if you do not run the
Microsoft OS installed at point of sale of the hardware, you get
a refund for the OS. But Microsoft and the hardware vendors
systematically refused refunds.
2. Does your defense apply to the case of Microsoft certified devices?
Your long careful post deserves a careful answer. I hope to make
one before one week has gone by.
Adam, thank you for your clear presentation!
On Thu, 14 Jun 2012, Adam Williamson <awilliam at redhat.com> wrote:
> On Thu, 2012-06-14 at 15:03 -0400, Jay Sulzberger wrote:
> On Thu, 14 Jun 2012, Peter Jones <pjones at redhat.com> wrote:
> > On 06/14/2012 01:56 PM, Jay Sulzberger wrote:
> >> If Fedora appears to accept that Microsoft should have the
> >> Hardware Root Key, our side's arguments, in several arenas, are
> >> weakened.
> > Okay, first off, quit hijacking fedora-devel-list for your unrelated DMCA
> > stuff. It's entirely the wrong place for that.
> No. You intend to grant to Microsoft the power to impede
> installation of Fedora. The DMCA can today be used to threaten
> those who go around the impediment with jail time.
This is, at minimum, arguable. It would require Secure Boot to meet the
definition of a 'technological protection measure'. According to
chillingeffects.org, these are defined as:
a measure which "in the ordinary course of its operation, requires the
application of information, or a process or a treatment, with the
authority of the copyright owner, to gain access to the work."
I don't immediately see how this can be held to apply to secure boot, as
it is not intended as a copy protection measure and, as I understand it,
is not necessarily or indeed often deployed by a copyright holder.
Especially as the secure boot specification explicitly allows for the
deployment of user keys, and the disabling (not circumvention) of secure
> > Aside from that, you've still got the facts wrong. What you call the
> > "Hardware Root Key" the specification calls the "Platform Key" or "PK". PK
> > serves a couple of functions - it is the ultimate arbiter of what can and
> > can't add keys to the system, and it is the determining factor as to whether
> > the Secure Boot feature is enabled. PK will probably not ever be Microsoft's
> > key on any system. It'll be a unique to each hardware vendor, or possibly
> > even unique to various business units within a hardware vendor, or anything
> > else they happen to choose. It's completely their decision as to how they
> > ship this, and nothing we can do will ever change that.
> The specification's words are carefully designed to mislead. As
> pointed out, if Microsoft has the Hardware Root Key, then
> "SecureBoot" is not a method of securely booting the hardware you
> You agree that the key in question is the Hardware Root Key. You
> just wrote:
> > [the PK] is the ultimate arbiter of what can and can't add keys
> > to the system, and it is the determining factor as to whether
> > the Secure Boot feature is enabled.
> > The contents of PK are not and have not ever been the question in this
> > thread.
> Yes, of course, who has the Hardware Root Key is the issue here.
No, it isn't. You are fundamentally misunderstanding secure boot. Peter
specifically stated that the "hardware root key" (as you call it; the
platform key, as it is correctly called) is not the key that Microsoft
will control. As Peter said, hardware manufacturers will control the
hardware root key for their hardware. What Microsoft is pushing for (and
requiring for compliance with its certification scheme) is that systems
are shipped with Microsoft's signing key - not platform key.
Microsoft do not require that Microsoft's be the _only_ signing key. Per
their certification, it'd be perfectly fine to ship a system with
Microsoft's key and 500 others. Signing keys are not a 'There Can Be
Only One' proposition. It's therefore hard to argue that the setup is
giving Microsoft any kind of exclusive control over anything. There is
in theory nothing to stop any other organization from acting as a
signing authority and persuading hardware vendors to install their
signing key in addition to Microsoft's. The problems with this approach
are discussed in mjg59's blog post. None of the problems with it is
'Microsoft don't want it to happen', because that isn't the case.
> If there is no issue as to who has the Hardware Root Key, why do
> you propose having Microsoft sign a Fedora key which allows for
> more convenient installation of Fedora?
Read the initial blog post. Because in practice, no-one else besides
Microsoft actually wants to go to the considerable trouble and expense
of acting as a signing authority. _In theory_ any number of bodies could
do so. _In practice_, no-one has yet showed up with the will and ability
to do so, and apparently (I am not privy to any private planning in this
regard) Red Hat doesn't want to either act as one in itself or lead a
consortium to do so. Given that only Microsoft has committed to being a
signing authority, and we aren't going to do so ourselves (either 'we'
as in Red Hat or 'we' as in Fedora), the choices for secure boot boil
down to either 'don't support it' or 'get our code signed by Microsoft'.
But it's hard to blame Microsoft, exactly, for no-one else wanting to be
a signing authority. Microsoft have certainly not done anything to
preclude the possibility of any other body acting as a signing authority
and getting their keys on hardware. The only thing you can fairly
'blame' Microsoft for is using their influence to effectively enforce
the default activation of Secure Boot with _indifference_ - but not
active malice - to the effects on other operating systems. I think
Microsoft would have had to have tried much harder to preclude other
people from acting as signing authorities to justify a charge of active
malice on their part.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
devel mailing list
devel at lists.fedoraproject.org
More information about the devel