Re: [PATCH Strawman] crypto: Handle PEM-encoded x.509 certificates

[Eric Biggers <ebiggers@kernel.org>]

On Sat, Nov 13, 2021 at 07:12:44PM +0000, Chuck Lever III wrote:
> 
> Certainly, the kernel could include a single set of base64 encoders
> and decoders that can be used by all in-kernel consumers. See for
> example net/ceph/armor.c and fs/crypto/fname.c .

Not really, there are many variants of Base64 and different policy decisions
that can be made: the chosen character set, whether to pad or not pad, whether
to allow whitespace, how to handle invalid characters, how to handle invalid
padding, whether to nul-terminate, and so on.  There's lots of room for bugs and
incompatibilities.

> 
> Because PEM decoding does not require any policy decisions, and
> because the kernel already has at least two existing partial
> base64 implementations, I'm not aware of a technical reason a
> system call like add_key(2) should not to accept PEM-encoded
> asymmetric key material.

Adding kernel UAPIs expands the kernel's attack surface, causing security
vulnerabilities.  It also increases the number of UAPIs that need to be
permanently supported.  It makes no sense to add kernel UAPIs for things that
can be easily done in userspace.

They work well as April Fools' jokes, though:
https://lore.kernel.org/r/1459463613-32473-1-git-send-email-richard@nod.at
Perhaps you meant to save your patch for April 1?

- Eric