From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "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>
Subject: Re: [PATCH RESEND] KEYS: trusted: Use ASN.1 encoded OID
Date: Thu, 23 May 2024 20:24:04 +0300 [thread overview]
Message-ID: <D1H75ZOA69LC.3OO4RAW8JBNHY@kernel.org> (raw)
In-Reply-To: <cb7510433c13aaaa9bc64d624331f1a3a958fcf3.camel@HansenPartnership.com>
On Thu May 23, 2024 at 8:08 PM EEST, James Bottomley wrote:
> On Thu, 2024-05-23 at 11:30 -0400, James Bottomley wrote:
> > On Thu, 2024-05-23 at 16:54 +0300, Jarkko Sakkinen wrote:
> > > On Thu May 23, 2024 at 4:38 PM EEST, James Bottomley wrote:
> > > > On Thu, 2024-05-23 at 16:19 +0300, Jarkko Sakkinen wrote:
> > > > > There's no reason to encode OID_TPMSealedData at run-time, as
> > > > > it
> > > > > never changes.
> > > > >
> > > > > Replace it with the encoded version, which has exactly the same
> > > > > size:
> > > > >
> > > > > 67 81 05 0A 01 05
> > > > >
> > > > > Include OBJECT IDENTIFIER (0x06) tag and length as the epilogue
> > > > > so
> > > > > that the OID can be simply copied to the blob.
> > > >
> > > > This is true, but if we're going to do this, we should expand the
> > > > OID
> > > > registry functions (in lib/oid_registry.c) to do something like
> > > > encode_OID. The registry already contains the hex above minus
> > > > the
> > > > two
> > > > prefixes (which are easy to add).
> > >
> > > Yes, I do agree with this idea, and I named variable the I named
> > > it to make it obvious that generation is possible.
> > >
> > > It would be best to have a single source, which could be just
> > > a CSV file with entries like:
> > >
> > > <Name>,<OID number>
> > >
> > > And then in scripts/ there should be a script that takes this
> > > source and generates oid_registry.gen.{h,c}. The existing
> > > oid_registry.h should really just include oid_registry.gen.h
> > > then to make this transparent change.
> > >
> > > And then in the series where OID's are encoded per-subsystem
> > > patch that takes pre-encoded OID into use.
> > >
> > > Happy to review such patch set if it is pushed forward.
> >
> > Heh, OK, since I'm the one who thinks it's quite easy, I'll give it a
> > go.
>
> Turns out it's actually really simple. This would go as three patches:
> adding the feature to lib/oid_registry.c using it in trusted keys and
> removing the now unused OID encode from lib/asn1_encode.c but I'm
> attaching here (minus the removal) to give an idea.
This looks pretty good to me at least in this level. I could repeal
and replace the patch I did today with this if it plays out well.
BR, Jarkko
prev parent reply other threads:[~2024-05-23 17:24 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
2024-05-23 17:08 ` James Bottomley
2024-05-23 17:24 ` Jarkko Sakkinen [this message]
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=D1H75ZOA69LC.3OO4RAW8JBNHY@kernel.org \
--to=jarkko@kernel.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.