diff --git a/specs/stein/approved/add-emulated-virtual-tpm.rst b/specs/stein/approved/add-emulated-virtual-tpm.rst
new file mode 100644
index 000000000..85e4f7d2b
--- /dev/null
+++ b/specs/stein/approved/add-emulated-virtual-tpm.rst
@@ -0,0 +1,261 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+==========================================
+Add support for emulated virtual TPM
+==========================================
+
+Include the URL of your launchpad blueprint:
+
+https://blueprints.launchpad.net/nova/+spec/add-emulated-virtual-tpm
+
+There are a class of applications which expect to use a TPM device to store
+secrets. In order to run these applications in a virtual machine, it would be
+useful to expose a virtual TPM device within the guest. Accordingly, the
+suggestion is to add a placement trait which could be requested in the
+flavor or image which would cause such a device to be added to the VM by the
+relevent virt driver.
+
+
+Problem description
+===================
+
+Currently there is no way to create virtual machines within nova that provide
+a virtual TPM device to the guest.
+
+Use Cases
+---------
+
+Support the virtualizing of existing applications and operating systems which
+expect to make use of physical TPM devices. At least one hypervisor
+(libvirt/qemu) currently supports the creation of an emulated TPM device which
+is associated with a per-VM "swtpm" process on the host, but there is no way to
+tell nova to enable it.
+
+Proposed change
+===============
+
+In recent libvirt and qemu (and possibly other hypervisors as well) there is
+support for an emulated vTPM device. We propose to modify nova to make use
+of this capability.
+
+For the libvirt virt driver in particular, there is support for vTPM as of
+libvirt 4.5. The desired libvirt XML arguments are something like this::
+
+ ...
+
+
+
+
+
+
+ ...
+
+Support for emulated TPM requires qemu 2.11 at a minimum, though qemu 2.12 is
+recommended by the author. The virt driver code should add suitable version
+checks (in the case of LibvirtDriver, this would include checks for both
+libvirt and qemu). Currently emulated TPM is only supported for x86, though
+this is an implementation detail rather than an architectural limitation.
+
+Support for emulated TPM also requires the "swtpm" binary and libraries to be
+available on the host. If there is no way to check whether this is available
+from the hypervisor, we may need to add a hypervisor-specific nova.conf flag
+indicating that we want to enable emulated TPM support. This would presumably
+default to `false` for minimal surprise on upgrades.
+
+In order to request this functionality (and to allow scheduling to nodes that
+provide this functionality) we propose to define two new traits,
+`COMPUTE_SECURITY_TPM_1_2` and `COMPUTE_SECURITY_TPM_2_0`.
+(The emulated TPM is just a process running on the host, so the concept of
+inventory doesn't apply.) The two traits represent the two different versions
+of the TPM spec that are currently supported. (A summary of the differences
+between the two versions is currently available here_.) The flavor extra-specs
+or image properties could then specify something like
+`trait:COMPUTE_SECURITY_TPM_1_2=required` to indicate that they wish to have
+access to a TPM. Virt drivers which could provide a TPM to their instances
+would be responsible for setting either (or both) of the two traits on the
+compute nodes. If an instance has specified one of the traits in the flavor
+or image, the virt driver will do whatever is needed to provide a TPM to the
+instance. If for any reason this is not possible, the instance creation will
+fail.
+
+When using `COMPUTE_SECURITY_TPM_2_0`, there are two possible device models for
+the emulated TPM device, `TIS` and `CRB`. By default the `TIS` model will be
+used, but it can also be explicitly specified by setting
+`hw:tpm_model=TIS` in the image or `hw_tpm_model=TIS` in
+the image properties. The CRB option can be specified by setting
+`hw:tpm_model=CRB` in the flavor (or via the equivalent image
+property). In the case of libvirt/qemu, the version of libvirt that supports
+TPM 2.0 (v4.5.0) also supports the `CRB` device model.
+
+If both the flavor and the image specify a TPM trait or device model and the
+two values do not match, an exception will be raised. If the CRB model is
+specified with `COMPUTE_SECURITY_TPM_1_2` the hypervisor will fail to create
+the instance.
+
+As a future enhancement beyond the scope of the immediate work, it would be
+possible to extend this to support physical TPM passthrough. In this case the
+virt driver would also advertise an inventory with a resource class of ``PTPM``
+with ``total=1`` (since current hardware only has a single TPM), and the image
+or flavor could request it by specifying `resources:PTPM=1`. The trait would
+not be necessary in this case, as the desire for a TPM in the instance is
+implied by the resource request. Also, for TPM passthrough the device model
+is controlled by the actual hardware device.
+
+As part of implementing the this feature, the nova cold migration code will
+need to copy over the directory containing the emulated TPM files. For
+libvirt this would mean copying the file under
+/var/lib/libvirt/swtpm/ from within
+LibvirtDriver.migrate_disk_and_power_off().
+
+Shelve/unshelve could be supported by saving the persistent TPM data as a
+glance image during the shelve operation, and recreating it (and deleting
+the image) during unshelve.
+
+Resizing will result in a reschedule, so shouldn't be a problem. If the admin
+resizes from a flavor with TPM to a flavor without TPM nova won't care, but it
+might cause problems in the guest.
+
+Rebuilding to a new image is problematic if the new image specifies a TPM
+trait and the current host cannot provide TPM support. This will cause the
+rebuild to fail. In this case, the user would need to rebuild with a suitable
+image.
+
+It should be noted that if a compute node goes down and the VM has to be
+rebuilt on another compute node then we're going to lose any emulated TPM data.
+In the shared-storage case this is exactly analogous to taking the hard drive
+out of one physical machine and putting it into another physical machine.
+
+.. _here: https://en.wikipedia.org/wiki/Trusted_Platform_Module#TPM_1.2_vs_TPM_2.0
+
+Alternatives
+------------
+
+Rather than using a trait, we could instead use a resource with a large
+inventory.
+
+
+Data model impact
+-----------------
+
+None
+
+REST API impact
+---------------
+
+None
+
+Security impact
+---------------
+
+The guest will be able to use the emulated TPM for all the security enhancing
+functionality that a physical TPM provides, in order to protect itself against
+attacks from within the guest. The guest must still trust the host.
+
+Notifications impact
+--------------------
+
+None
+
+Other end user impact
+---------------------
+
+There are no immediate plans to make emulated TPM work over shelve/unshelve.
+To make this work reliably would require saving the persistent TPM data file
+to a glance image or swift object on "shelve" and then recover the data on
+"unshelve".
+
+Instances which use UEFI NVRAM are currently in a similar position, as the
+NVRAM is not persisted over shelve/unshelve.
+
+Performance Impact
+------------------
+
+Negligible.
+
+Other deployer impact
+---------------------
+
+None
+
+Developer impact
+----------------
+
+The various virt drivers would be able to implement the emulated vTPM as
+desired.
+
+Upgrade impact
+--------------
+
+If a config option is needed to opt-in to emulated TPM support, the operator
+would need to set the config option appropriately after an upgrade.
+
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Primary assignee:
+ cfriesen
+
+Other contributors:
+ None
+
+Work Items
+----------
+
+* Support for new placement traits
+
+* Libvirt driver changes to report traits to placement
+
+* Libvirt driver changes to enable specifying libvirt XML
+
+* Libvirt driver changes to copy vTPM files on cold migration.
+
+
+Dependencies
+============
+
+* Up-to-date qemu/libvirt
+
+* "swtpm" binary and libraries
+
+
+Testing
+=======
+
+Unit and functional testing will be added.
+
+
+Documentation Impact
+====================
+
+Operations Guide and End User Guide will be updated appropriately.
+Feature support matrix will be updated.
+
+
+References
+==========
+
+* Qemu docs on tpm:
+ https://github.com/qemu/qemu/blob/master/docs/specs/tpm.txt
+
+* Libvirt XML to request emulated TPM device:
+ https://libvirt.org/formatdomain.html#elementsTpm
+
+
+History
+=======
+
+.. list-table:: Revisions
+ :header-rows: 1
+
+ * - Release Name
+ - Description
+ * - Stein
+ - Introduced