On Wed, May 20, 2015 at 9:21 AM, Petko Manolov <pet...@mip-labs.com> wrote: > On 15-05-20 08:56:21, Andy Lutomirski wrote: >> >> Would it make more sense to permit X.509 chains to be loaded into the keyring >> instead if we actually need that feature? IOW, let userspace (or early >> initramfs stuff) extend our keyring trust to intermediate certs that validly >> chain to already-trusted things? I think that a reasonable design goal would >> be that everything overcomplicated that's involved should be optional, and >> moving toward embedding PKCS#7 signatures in the modules themselves does the >> other direction? > > This is similar to what i am doing right now - create CA hierarchy so we can > have something like: > > +-> KeyB > | > RootCA ---> CertA ---> CertB ---> CertC ---> KeyC > | > +-> CertA' ---> KeyA" > > The RootCA may be the one whose private key was used to sign the modules and > all > downstream certificates are either directly signed by it or one of the others. > Not all of the infrastructure is in the mainline kernel, but this can easily > be > rectified.
Right. I guess that I can imagine some uses for this, but I don't see why those intermediate certs would be embedded with the signatures being verified as opposed to being loaded beforehand. > > Now, as Mimi pointed out this scheme is flawed and should be used with care if > at all. Revoking certificates is always a PITA. Being valid for one year > only > adds to the fun. > Valid for only one year is worse than that. We might be verifying the signature on our clock driver :) I think that, at best, we could reject certificates that expired before the running kernel was built. > > Petko -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
