Linux-Integrity Archive on lore.kernel.org
 help / color / Atom feed
From: James Prestwood <prestwoj@gmail.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	linux-integrity@vger.kernel.org
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	David Woodhouse <dwmw2@infradead.org>,
	keyrings@vger.kernel.org
Subject: Re: [PATCH v5 4/6] security: keys: trusted: use ASN.1 TPM2 key format for the blobs
Date: Mon, 03 Feb 2020 08:54:40 -0800
Message-ID: <5c593b6f23ae41e90e6b3799141ea68944bb4034.camel@gmail.com> (raw)
In-Reply-To: <20200130101812.6271-5-James.Bottomley@HansenPartnership.com>

Hi James,

<snip>

> diff --git a/security/keys/trusted-keys/tpm2key.asn1
> b/security/keys/trusted-keys/tpm2key.asn1
> new file mode 100644
> index 000000000000..f930fd812db3
> --- /dev/null
> +++ b/security/keys/trusted-keys/tpm2key.asn1
> @@ -0,0 +1,23 @@
> +---
> +--- Note: This isn't quite the definition in the standard
> +---       However, the Linux asn.1 parser doesn't understand
> +---       [2] EXPLICIT SEQUENCE OF OPTIONAL
> +---       So there's an extra intermediate TPMPolicySequence
> +---       definition to work around this
> +
> +TPMKey ::= SEQUENCE {
> +	type		OBJECT IDENTIFIER ({tpmkey_type}),
> +	emptyAuth	[0] EXPLICIT BOOLEAN OPTIONAL,
> +	policy		[1] EXPLICIT TPMPolicySequence OPTIONAL,
> +	secret		[2] EXPLICIT OCTET STRING OPTIONAL,
> +	parent		INTEGER ({tpmkey_parent}),
> +	pubkey		OCTET STRING ({tpmkey_pub}),
> +	privkey		OCTET STRING ({tpmkey_priv})
> +	}
> +
> +TPMPolicySequence ::= SEQUENCE OF TPMPolicy
> +
> +TPMPolicy ::= SEQUENCE {
> +	commandCode		[0] EXPLICIT INTEGER ({tpmkey_code}),
> +	commandPolicy		[1] EXPLICIT OCTET STRING
> ({tpmkey_policy})
> +	}

I have been using your set of patches in order to get this ASN.1
parser/definition. I am implementing an asymmetric key parser/type TPM2
keys for enc/dec/sign/verify using keyctl. Note that this
implementation goes in crypto/asymmetric_keys/, and your patches sit in
security/keys/trusted-keys/.

Currently I am just including "../../security/keys/trusted-
keys/{tpm2key.asn1.h,tpm2-policy.h}" in order to use the ASN.1 parser
to verify my keys, but this obviously isn't going to fly.

Do you (or anyone) have any ideas as to how both trusted keys and
asymmetric keys could share this ASN.1 parser/definition? Some common
area that both security and crypto could include? Or maybe there is
some common way the kernel does things like this?

Thanks,
James



  reply index

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-30 10:18 [PATCH v5 0/6] TPM 2.0 trusted keys with attached policy James Bottomley
2020-01-30 10:18 ` [PATCH v5 1/6] lib: add ASN.1 encoder James Bottomley
2020-01-30 10:18 ` [PATCH v5 2/6] oid_registry: Add TCG defined OIDS for TPM keys James Bottomley
2020-01-30 10:18 ` [PATCH v5 3/6] security: keys: trusted fix tpm2 authorizations James Bottomley
2020-02-25 16:48   ` Jarkko Sakkinen
2020-02-26 15:15     ` Jarkko Sakkinen
2020-02-27  0:58     ` James Bottomley
2020-02-27 16:19       ` Jarkko Sakkinen
2020-02-27 16:21         ` James Bottomley
2020-02-27 17:49           ` James Bottomley
2020-03-02 11:08             ` Jarkko Sakkinen
2020-01-30 10:18 ` [PATCH v5 4/6] security: keys: trusted: use ASN.1 TPM2 key format for the blobs James Bottomley
2020-02-03 16:54   ` James Prestwood [this message]
2020-02-27  0:02     ` James Bottomley
2020-02-27  0:20       ` James Prestwood
2020-02-27  0:54         ` James Bottomley
2020-02-27 17:19           ` James Prestwood
2020-02-27 20:19             ` James Bottomley
2020-02-27 20:26               ` James Bottomley
2020-02-27 20:44                 ` James Prestwood
2020-02-27 20:57               ` James Prestwood
2020-03-02 19:00               ` James Prestwood
2020-01-30 10:18 ` [PATCH v5 5/6] security: keys: trusted: add ability to specify arbitrary policy James Bottomley
2020-01-30 10:18 ` [PATCH v5 6/6] security: keys: trusted: implement counter/timer policy James Bottomley
2020-02-20 20:17 ` [PATCH v5 0/6] TPM 2.0 trusted keys with attached policy 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=5c593b6f23ae41e90e6b3799141ea68944bb4034.camel@gmail.com \
    --to=prestwoj@gmail.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dwmw2@infradead.org \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --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

Linux-Integrity Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-integrity/0 linux-integrity/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-integrity linux-integrity/ https://lore.kernel.org/linux-integrity \
		linux-integrity@vger.kernel.org
	public-inbox-index linux-integrity

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-integrity


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git