linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Jarkko Sakkinen" <jarkko@kernel.org>,
	"James Bottomley" <James.Bottomley@HansenPartnership.com>,
	<linux-integrity@vger.kernel.org>
Cc: <keyrings@vger.kernel.org>,
	"David Woodhouse" <dwmw2@infradead.org>,
	"Eric Biggers" <ebiggers@kernel.org>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Mimi Zohar" <zohar@linux.ibm.com>,
	"David Howells" <dhowells@redhat.com>,
	"Paul Moore" <paul@paul-moore.com>,
	"James Morris" <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"open list:CRYPTO API" <linux-crypto@vger.kernel.org>,
	"open list" <linux-kernel@vger.kernel.org>,
	"open list:SECURITY SUBSYSTEM"
	<linux-security-module@vger.kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>
Subject: Re: [PATCH RESEND] KEYS: trusted: Use ASN.1 encoded OID
Date: Thu, 23 May 2024 20:03:03 +0300	[thread overview]
Message-ID: <D1H6PWDP0EPE.1PD74CKI5KKCP@kernel.org> (raw)
In-Reply-To: <D1H5A2BM6RBM.1RHCXHHO1SKDX@kernel.org>

On Thu May 23, 2024 at 6:55 PM EEST, Jarkko Sakkinen wrote:
> I was already considering do we need the encoder at all but I think
> for dynamic assets like octect strings and variable size integers
> it has its place. Obviously is not very mature at this point.

Also, I've been opening up discussion of opt-in and *experimental*
ASN1_RUST feature.

I think it is inevident that it needs to be done at some point because
for ASN.1 like format this would have benefits, and also given that it
used to process security sensitive data.

So metrics for this would something along the lines:

- Depending on ASN1_RUST setting, the C API's would be implemented
  either C or Rust.
- OID database could be shared from C-side to Rust simply with
  bindgen.
- C API should be streamline and matured a bit to cover mostly
  dynamic assets (integers, octect strings and such). Since the
  number of call sites is small improving should be easy.
- After tpm2_key_rsa is landed as it is now as per how buffer
  processing goes it can be brought to use encoder.
- I'd consider have just a single ASN1 flag instead of a separate
  ASN1_ENCODER flag. It simplifies thing and is not significant
  cost for vmlinux size so not worth it IMHO.

As for sending patches for e.g. improving OID database, I'd like to
land the current tpm2_key_rsa first because then in possible OID
series that can be also applied to it (and encoder). It does stuff
that affects all this work. And as said we need also tpm2_key_ecdsa.

Right, there's also

https://datatracker.ietf.org/doc/draft-woodhouse-cert-best-practice/

I checked from David that this TPM2 asymmetric key work is relevant
for this spec although I readily know some applications for it, and 
he acknowledged that. I should probably link that to the next
version.

Asymmetric keys essentially make TPM2 a peer in x.509 ecosystem,
which has bunch of especially enterprise and data center type
of use cases.

I guess this summarizes the big picture. I've been messing around
mailing lists and developed these thoughts but this along the
lines how I see big picture, including integration to the Rust
ecosystem (in non-intrusive way).

But yeah, tpm2_key_rsa needs to be the first step.

I don't have an employer for kernel development at the moment (probably
at some point I do, my contract researcher sabbatical ends at end of
Sep) no money to come to the plumbers to discuss about all this at the
boot-time security mc so I need to spam my input for that I guess ;-)

BR, Jarkko

  reply	other threads:[~2024-05-23 17:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-23 13:19 [PATCH RESEND] KEYS: trusted: Use ASN.1 encoded OID Jarkko Sakkinen
2024-05-23 13:38 ` James Bottomley
2024-05-23 13:54   ` Jarkko Sakkinen
2024-05-23 15:30     ` James Bottomley
2024-05-23 15:37       ` Jarkko Sakkinen
2024-05-23 15:43         ` James Bottomley
2024-05-23 15:55           ` Jarkko Sakkinen
2024-05-23 17:03             ` Jarkko Sakkinen [this message]
2024-05-23 17:08       ` James Bottomley
2024-05-23 17:24         ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D1H6PWDP0EPE.1PD74CKI5KKCP@kernel.org \
    --to=jarkko@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.gaynor@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jmorris@namei.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).