On Tue, 2015-07-28 at 12:31 -0700, Andy Lutomirski wrote:
> On Tue, Jul 28, 2015 at 12:19 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> > On Tue, 2015-07-28 at 10:03 -0700, Andy Lutomirski wrote:
> > > 
> > > This will require that we take any firmware vendor's key and rewrap it
> > > somehow into a new X.509 blob with a key usage constraint.
> > 
> > There are established ways of handling those constraints as external
> > objects (see how NSS does it in its trust tokens, and thus p11-kit
> > -trust does too).
> 
> Wow, I thought X.509 was bad.  Now we get PKCS#11, too?  Ick.

$DEITY no, we don't need that in the kernel (although I'm seriously
looking at a PKCS#11 module in userspace which interacts with the
kernel keyring).

I was merely pointing out that there are established methods of
matching *separate* trust objects (including non-standard usage fields)
with existing X.509 certificates. Which *don't* involve needing to
'rewrap it somehow into a new X.509 blob with a key usage constraint'.

> Heck, with the X.509 variant, if Megasoft has an existing key signed
> by SketchyTrust, and we want to trust SketchyTrust to sign firmware
> for SketchyUSB devices (and to delegate to Megasoft using the
> *existing* key), are we supposed to enforce transitive constraints?
> Where are they rooted?  I think this way lies madness.  Let's just
> throw SketchyTrust's key in the "SketchyUSB only" pile and be done
> with it rather than fiddling with OpenSSL to re-wrap SketchyTrust's
> self-signed (?).

Yes, absolutely. That's what I've been saying all along. It's an extra
argument to the request_firmware() call.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation