diff --git a/src/devices/tech/security/images/device_states.png b/src/devices/tech/security/images/device_states.png
deleted file mode 100644
index 319c345..0000000
--- a/src/devices/tech/security/images/device_states.png
+++ /dev/null
Binary files differ
diff --git a/src/devices/tech/security/images/dm-verity_mgmt.png b/src/devices/tech/security/images/dm-verity_mgmt.png
index f67b93f..2c2854e 100644
--- a/src/devices/tech/security/images/dm-verity_mgmt.png
+++ b/src/devices/tech/security/images/dm-verity_mgmt.png
Binary files differ
diff --git a/src/devices/tech/security/images/verified_boot.png b/src/devices/tech/security/images/verified_boot.png
index 592aee8..b1c5cb6 100644
--- a/src/devices/tech/security/images/verified_boot.png
+++ b/src/devices/tech/security/images/verified_boot.png
Binary files differ
diff --git a/src/devices/tech/security/verifiedboot/dm-verity.jd b/src/devices/tech/security/verifiedboot/dm-verity.jd
index f86c1b2..0b03dda 100644
--- a/src/devices/tech/security/verifiedboot/dm-verity.jd
+++ b/src/devices/tech/security/verifiedboot/dm-verity.jd
@@ -189,6 +189,9 @@
 
 <p>And this table describes those metadata fields.</p>
 
+<p class="table-caption" id="table1">
+  <strong>Table 1.</strong> Verity metadata fields</p>
+
 <table>
 <tr>
 <th>Field</th>
@@ -233,3 +236,11 @@
 <td>0</td>
 </tr>
 </table>
+
+<h3 id="optimize">Optimizing dm-verity</h3>
+
+<p>To get the best performance out of dm-verity, you should:</p>
+  <ul>
+    <li>In the kernel, turn on NEON SHA-2 for ARMv7 and the SHA-2 extensions for ARMv8.
+    <li>Experiment with different read-ahead and prefetch_cluster settings to find the best configuration for your device.
+  </ul>
diff --git a/src/devices/tech/security/verifiedboot/verified-boot.jd b/src/devices/tech/security/verifiedboot/verified-boot.jd
index c96d930..1216fec 100644
--- a/src/devices/tech/security/verifiedboot/verified-boot.jd
+++ b/src/devices/tech/security/verifiedboot/verified-boot.jd
@@ -41,6 +41,9 @@
 
 <h2 id=glossary>Glossary</h2>
 
+<p class="table-caption" id="table1">
+  <strong>Table 1.</strong> Glossary of terms related to verified boot</p>
+
 <table>
  <tr>
     <td>
@@ -65,7 +68,7 @@
 </td>
     <td>
 <p>The device state indicates how freely software can be flashed to the device.
-Device states are LOCKED, UNLOCKED, or VERIFIED.</p>
+Device states are LOCKED and UNLOCKED.</p>
 </td>
  </tr>
  <tr>
@@ -94,38 +97,39 @@
 must be used to verify the boot image.</p>
 </td>
  </tr>
- <tr>
-    <td>
-<p>User provided keystore</p>
-</td>
-    <td>
-<p>The user keystore is a keystore flashed to the device via <code>fastboot 
-flash keystore &lt;path&gt;</code>.</p>
-</td>
- </tr>
 </table>
 
 <h2 id=overview>Overview</h2>
 
 <p>In addition to device state - which already exists in devices and controls
 whether the bootloader allows new software to be flashed - we introduce the
-concept of boot state that indicates the state of device integrity. We also
-add a third device state, which allows developers for example, to flash the
-software more frequently without a data wipe while still benefiting from
-verification.</p>
+concept of boot state that indicates the state of device integrity.</p>
+
+<h3 id=classes>Classes</h3>
+
+<p>We define two implementation classes for verified boot depending on how
+fully the device implements this specification, as follows:</p>
+
+<p><strong>Class A</strong>  implements verified boot with full chain of trust
+up to verified partitions. This implementation must support the LOCKED device
+state, and GREEN and RED boot states.</p>
+
+<p><strong>Class B</strong> implements Class A and additionally supports the
+UNLOCKED device state and the ORANGE boot state.</p>
 
 <h3 id=verification_keys>Verification keys</h3>
 
 <p>Bootloader integrity must be verified using a hardware root of trust. For
-verifying boot and recovery images, the bootloader must have a fixed OEM key
-available to it. It must always attempt to verify the boot image using the OEM
-key and only try other possible keys if this verification fails.</p>
+verifying boot and recovery partitions, the bootloader must have a fixed OEM key
+available to it. It must always attempt to verify the boot partition using the OEM
+key first and try other possible keys only if this verification fails.</p>
 
-<p>It must be possible for the user to flash alternative image verification keys
-to the device, and the bootloader must try verification using these keys if
-verification using the OEM key fails. However, using an image signed with the
-user-provided keystore must result in a notification to be shown, as described
-below.</p>
+<p>In Class B implementations, it must be possible for the user to flash
+software signed with other keys when the device is UNLOCKED. If the device is
+then LOCKED and verification using the OEM key fails, the bootloader must try
+verification using the certificate embedded in the partition signature.
+However, using a partition signed with anything other than the OEM key must
+result in a notification or a warning, as described below.</p>
 
 <h3 id=boot_state>Boot state</h3>
 
@@ -133,103 +137,62 @@
 attempt:</p>
 
 <ul>
-  <li> GREEN, indicating a full chain of trust extending from the bootloader to the
-system partition, including the bootloader, boot partition, and system
-partition.
+  <li>GREEN, indicating a full chain of trust extending from the bootloader to
+verified partitions, including the bootloader, boot partition, and all verified
+partitions.
+
+  <li>YELLOW, indicating the boot partition has been verified using the
+embedded certificate, and the signature is valid. The bootloader is required to
+display a notification and the fingerprint of the public key during boot.
+
+  <li>ORANGE, indicating a device may be freely modified. Device integrity is
+left to the user to verify out-of-band. The bootloader must display a warning
+to the user before allowing the boot process to continue.
+
+  <li>RED, indicating the device has failed verification. The bootloader must
+display a warning to the user before allowing the boot process to continue.
 </ul>
 
-<ul>
-  <li> YELLOW, indicating a chain of trust starting from a user-provided keystore
-and extending up. To enable users to acquire trust in their keystore,
-bootloaders are required to display a partial hash of the verifying keystore
-during boot.
-</ul>
+<p>The recovery partition must also be verified in the exact same way.</p>
 
-<ul>
-  <li> ORANGE, indicating a device may be freely modified. Device integrity is
-left to the user to verify out-of-band.
-</ul>
+<h3 id=device_state>Device state</h3>
 
-<ul>
-  <li> RED, indicating the device has failed verification. This must display a
-warning to the user before allowing the boot process to continue.
-</ul>
+<p>The device is required to be in one of two states at all times:</p>
 
-<p>The recovery partition must also be verified and should be verified in the
-exact same way.</p>
+<ol>
+  <li>LOCKED, indicating the device cannot be flashed. A LOCKED device must
+boot into the GREEN, YELLOW, or RED states during any attempted boot.
+
+  <li>UNLOCKED, indicating the device may be flashed freely and is not intended
+to be verified. An UNLOCKED device must always boot to the ORANGE boot state.
+</ol>
 
 <img src="../images/verified_boot.png" alt="Verified boot flow" id="figure1" />
 <p class="img-caption"><strong>Figure 1.</strong> Verified boot flow</p>
 
-<h3 id=device_state>Device state</h3>
-
-<p>The device is required to be in one of three states at all times:</p>
-
-<ol>
-  <li>LOCKED, indicating the device cannot currently be flashed. In the image
-above, a LOCKED device must boot into the GREEN state, YELLOW state, or RED
-state during any attempted boot. It must not be possible to alter the user
-keystore in the LOCKED state.
-
-  <li>VERIFIED, indicating someone in physical control of the device may perform
-limited actions intended to change the state of the device but may not break
-its current chain of trust. In the image above, a VERIFIED device must boot
-into the GREEN state, YELLOW state, or RED state during each attempted boot. It
-must not be possible to alter the user keystore in the VERIFIED state. It must
-be possible to:
-   <ol>
-    <li> Flash the following partitions:
-    <ol>
-      <li> bootloader
-      <li> boot partition
-      <li> system partition
-      <li> vendor partition
-      <li> recovery partition
-    </ol>
-    <li> Erase the following partitions:
-    <ol>
-      <li> userdata
-      <li> cache
-    </ol>
-   </ol>
-
-<p>Boot and recovery image signatures may be verified during the flashing process,
-and the bootloader may reject images that do not validate against the OEM key
-or the user-provided keystore at this point. However, signatures must also be
-verified again at every boot.
-
-  <li>UNLOCKED, indicating the device may be flashed freely and is not intended
-to be verified.
-</ol>
-
 <h2 id=detailed_design>Detailed design</h2>
 
 <p>Achieving full chain of trust requires support from both the bootloader and the
-software on the boot partition, specifically <code>init</code>, which is responsible for
-mounting additional partitions. Verification metadata must also be appended to the
-system partition and any additional partitions whose integrity should be
-verified.</p>
+software on the boot partition, which is responsible for mounting further
+partitions. Verification metadata must also be appended to the system partition
+and any additional partitions whose integrity should be verified.</p>
 
 <h3 id=bootloader_requirements>Bootloader requirements</h3>
 
-<p>The bootloader is the guardian of the device state, manages the user-provided
-keystore, and is responsible for initializing the TEE and binding its root of
-trust.</p>
+<p>The bootloader is the guardian of the device state and is responsible for
+initializing the TEE and binding its root of trust.</p>
 
 <p>Most importantly, the bootloader must verify the integrity of the boot and/or
 recovery partition before moving execution to the kernel and display the
-warnings or notifications in the section <a href="#boot_state">Boot state</a>.</p>
+warnings specified in the section <a href="#boot_state">Boot state</a>.</p>
 
-<h4 id=changing_device_state><strong>Changing device state</strong></h4>
+<h4 id=changing_device_state>Changing device state</h4>
 
 <p>State changes are performed using the <code>fastboot flashing [unlock |
-verified | lock]</code> command. And to protect user data, <strong>all</strong>
+lock]</code> command. And to protect user data, <strong>all</strong>
 state transitions require a data wipe. Note the user must be asked for
 confirmation before data is deleted.</p>
 
-<img src="../images/device_states.png" alt="Changing device states" id="figure2" />
-<p class="img-caption"><strong>Figure 2.</strong> Changing device states</p>
-
 <ol>
   <li>The UNLOCKED to LOCKED transition is anticipated when a user buys a used
 development device. As a result of locking the device, the user should have
@@ -237,20 +200,13 @@
 
   <li>The LOCKED to UNLOCKED transition is expected in the case where a developer
 wishes to disable verification on the device.
-
-  <li>The LOCKED to VERIFIED transition is expected in the case where a developer
-wishes to do development on the device and doesn’t want to wipe data frequently.
-
-  <li>The VERIFIED to LOCKED transition is idempotent with the above.
-
-  <li>The UNLOCKED to VERIFIED transition is anticipated when a user wishes to put a
-development device in a more secure state but may not want to prevent
-themselves from flashing new system images.
-
-  <li> The VERIFIED to UNLOCKED transition is idempotent with the above.
 </ol>
 
 <p>Requirements for <code>fastboot</code> commands that alter device state are listed in the table below:</p>
+
+<p class="table-caption" id="table2">
+  <strong>Table 2.</strong> <code>fastboot</code> commands</p>
+
 <table>
  <tr>
     <td>
@@ -268,7 +224,6 @@
 <ul>
   <li>Wipe data after asking the user for confirmation     
   <li>Clear a write-protected bit indicating the device is unlocked
-  <li>Clear a write-protected bit indicating the device is verified
 </ul>
 </td>
  </tr>
@@ -280,19 +235,6 @@
 <ul>
   <li>Wipe data after asking the user for confirmation     
   <li>Set a write-protected bit indicating the device is unlocked
-  <li>Clear a write-protected bit indicating the device is verified
-</ul>
-</td>
- </tr>
- <tr>
-    <td>
-<code>
-flashing verified</code></td>
-    <td>
-<ul>
-  <li>Wipe data after asking the user for confirmation     
-  <li>Clear a write-protected bit indicating the device is unlocked
-  <li>Set a write-protected bit indicating the device is verified
 </ul>
 </td>
  </tr>
@@ -300,6 +242,10 @@
 
 <p>When altering partition contents, the bootloader must check the bits set by
 the above commands as described in the following table:</p>
+
+<p class="table-caption" id="table3">
+  <strong>Table 3.</strong> <code>fastboot</code> command requirements</p>
+
 <table>
  <tr>
     <td>
@@ -314,128 +260,110 @@
 <code>
 flash &lt;partition&gt;</code></td>
     <td>
-<ul>
-  <li>If the bit set by <code>flashing unlock</code> is set, flash the partition as normal    
-  <li>If this bit is not set, check the bit set by <code>flashing verified</code>
-    <ul>
-      <li>If this bit is not set, exit with an error
-      <li>If this bit is set and &lt;partition&gt; is on the list provided in
-          the section <a href="#device_state">Device state</a>, flash the partition as normal.
-   </ul>
-</ul>
+    <p>If the bit set by <code>flashing unlock</code> is set, flash the
+      partition. Otherwise, do not allow flashing.<p>
     </td>
  </tr>
 </table>
 
-<p>The same checks should be performed for any <code>fastboot</code> command that can be used to change the contents of partitions.</p>
+<p>The same checks should be performed for any <code>fastboot</code> command
+that can be used to change the contents of partitions.</p>
 
-<h4 id=managing_user_provided_keystore><strong>Managing user-provided keystore</strong></h4>
+<p class="note"><strong>Note</strong>: Class B implementations must support
+changing device state.</p>
 
-<p>Users can flash their own verification keys to the device, which must be
-used to verify the integrity of boot and recovery images if verification
-against the OEM key fails. This allows a developer to change the system
-software frequently, for example,  while still keeping verified boot enabled.</p>
+<h4 id=binding_tee_root_of_trust>Binding TEE root of trust</h4>
 
-<p>The bootloader is responsible for maintaining the integrity of the user
-keystore. It must not be possible to change the contents of the keystore unless
-the device is UNLOCKED. When the user flashes a new keystore to the device, the
-bootloader must sign it using the TEE and store the signed keystore. Before
-using keys from the keystore, the bootloader must use the TEE to verify the
-signature.</p>
-
-<p>Requirements for <code>fastboot</code> commands used to manage the user-provided keystore are listed in the table
-below:</p>
-<table>
- <tr>
-    <td>
-<p><strong><code>fastboot</code> command</strong></p>
-</td>
-    <td>
-<p>Requirements</p>
-</td>
- </tr>
- <tr>
-    <td>
-<code>
-flash keystore &lt;filename&gt;</code></td>
-    <td>
-<ul>
-  <li>Check the bit set by <code>flashing unlock</code>; if not set, exit with an error 
-  <li>Validate the given keystore against the format provided in section <a href="#keystore_format">Keystore format</a>
-  <li>Pass the keystore to the TEE for signing
-  <li>Write the signed keystore to the write-protected user keystore storage
-      area (location to be determined by the OEM)
-</ul>
-</td>
- </tr>
- <tr>
-    <td>
-<code>
-erase keystore</code></td>
-    <td>
-<ul>
-  <li>Check the bit set by <code>flashing unlock</code>; if not set, exit with an error
-  <li>Erase the keystore stored in the write-protected user keystore storage area
-</ul>
-    </td>
- </tr>
-</table>
-
-<h4 id=binding_tee_root_of_trust><strong>Binding TEE root of trust</strong></h4>
-
-<p>After the bootloader has initialized the TEE and performed boot image
-verification steps, it must pass the following information to the TEE Keymaster
-as the root of trust:</p>
+<p>If TEE is available, the bootloader should pass the following information to
+the TEE to bind the Keymaster root of trust, after partition verification and
+TEE initialization:</p>
 
 <ol>
-  <li>The public key that was used to sign the boot image
-  <li>The current device state (LOCKED, VERIFIED, or UNLOCKED)
+  <li>the public key that was used to sign the boot partition
+  <li>the current device state (LOCKED or UNLOCKED)
 </ol>
 
-<p>This changes the keys derived by the TEE. For disk encryption, for example,
-this prevents user data from being decrypted when the device is booted using a
-potentially untrusted image signed with a different key.</p>
+<p>This changes the keys derived by the TEE. Taking disk encryption as an example,
+this prevents user data from being decrypted when the device state changes.</p>
 
 <p class="note"><strong>Note:</strong> This means if the system software or the
 device state changes, encrypted user data will no longer be accessible as the
 TEE will attempt to use a different key to decrypt the data.</p>
 
-<h4 id=booting_into_recovery><strong>Booting into recovery</strong></h4>
+<h4 id=booting_into_recovery>Booting into recovery</h4>
 
-<p>The recovery image should be verified in exactly the same manner as the boot
-image.</p>
+<p>The recovery partition should be verified in exactly the same manner as the
+boot partition.</p>
+
+<h4 id=comm_boot_state>Communicating boot state</h4>
+
+<p>System software needs to be able to determine the verification status of
+previous stages. The bootloader must specify the current boot state as a
+parameter on the kernel command line (or through the device tree under
+<code>firmware/android/verifiedbootstate</code>) as described in the table
+below:</p>
+
+<p class="table-caption" id="table4">
+  <strong>Table 4.</strong> Kernel command line parameters</p>
+
+<table>
+  <tr>
+    <th>Kernel command line parameter</th>
+    <th>Description</th>
+  </tr>
+  <tr>
+    <td><code>androidboot.verifiedbootstate=green</code></td>
+    <td>Device has booted into GREEN boot state.<br>
+        Boot partition has been verified using the OEM key and it’s valid.</td>
+  </tr>
+  <tr>
+    <td><code>androidboot.verifiedbootstate=yellow</code></td>
+    <td>Device has booted into YELLOW boot state.<br>
+	Boot partition has been verified using the certificate embedded into
+        the signature and it’s valid.</td>
+  </tr>
+  <tr>
+    <td><code>androidboot.verifiedbootstate=orange</code></td>
+    <td>Device has booted into ORANGE boot state.<br>
+        The device is unlocked and no verification has been performed.</td>
+  </tr>
+  <tr>
+    <td><code>androidboot.verifiedbootstate=red</code></td>
+    <td>Device has booted into RED boot state.<br>
+        The device has failed verification.</td>
+  </tr>
+</table>
 
 <h3 id=boot_partition>Boot partition</h3>
 
-<p>Once execution has moved to the boot and/or recovery image, <code>init</code> is responsible
-for setting up verification for further partitions. Due to its large size, the
-system partition cannot be verified similarly to previous parts but must be
-verified in real time as it’s being accessed by using the dm-verity kernel
-driver.</p>
+<p>Once execution has moved to the boot partition, the software there is responsible
+for setting up verification of further partitions. Due to its large size, the
+system partition typically cannot be verified similarly to previous parts but must be
+verified as it’s being accessed instead using the dm-verity kernel driver or a
+similar solution.</p>
 
-<p>When <code>fs_mgr</code> flags in the device’s <code>fstab</code> indicate a partition should be
-verified, <code>init</code> will verify the signed verity metadata appended to the partition
-before mounting it and set up the dm-verity device for the partition.</p>
+<p>If dm-verity is used to verify large partitions, the signature of the verity
+metadata appended to each verified partition must be verified before the
+partition is mounted and dm-verity is set up for it.</p>
 
-<h4 id=managing_dm-verity><strong>Managing dm-verity</strong></h4>
+<h4 id=managing_dm-verity>Managing dm-verity</h4>
 
-<p>By default, dm-verity operates in verifying mode and verifies each block read
-from the device against a hash tree passed to it by <code>init</code> during set up. If it
+<p>By default, dm-verity operates in enforcing mode and verifies each block read
+from the partition against a hash tree passed to it during setup. If it
 comes across a block that fails to verify, it returns an I/O error and makes
 the block with unexpected contents inaccessible to user space. Depending on
 which block is corrupted, this may cause some of the programs that reside on
 the partition to malfunction.</p>
 
-<p>Using a persistent flag, dm-verity can also be configured to function in
-logging mode. This flag is read by <code>init</code> when setting up dm-verity. And if the
-mode flag is set to logging or verity metadata cannot be verified, a warning
-must be displayed to the user, similar to the warning the bootloader shows
-before booting into RED state.</p>
+<p>Using an optional verity table parameter, dm-verity can be configured to
+function in logging mode. If dm-verity is not started in enforcing mode for any
+reason, or verity metadata cannot be verified, a warning must be displayed to
+the user, similar to the one shown before booting into the RED state.</p>
 
-<img src="../images/dm-verity_mgmt.png" alt="dm-verity management" id="figure3" />
-<p class="img-caption"><strong>Figure 3.</strong> dm-verity management</p>
+<img src="../images/dm-verity_mgmt.png" alt="dm-verity management" id="figure2" />
+<p class="img-caption"><strong>Figure 2.</strong> dm-verity management</p>
 
-<h4 id=recovering_from_dm-verity_errors><strong>Recovering from dm-verity errors</strong></h4>
+<h4 id=recovering_from_dm-verity_errors>Recovering from dm-verity errors</h4>
 
 <p>Since the system partition is by far larger than the boot partition, the
 probability of verification errors is also higher. Specifically, there is a
@@ -445,31 +373,32 @@
 
 <p>It’s generally not possible to distinguish disk corruption from malicious
 changes, so any change to the system partition must result in the user being
-notified, and no unverified data must leak to user space until a warning has
+notified; and no unverified data must leak to user space until a warning has
 been shown. However, we must also assume most verification failures are
 not the result of malicious behavior; so the user must also have an option to
 continue using the device without verification.</p>
 
-<p>If dm-verity is in verifying mode and a block of a partition fails to verify,
-it will send a <code>uevent</code> to notify user space of the error. This event must be
-handled by software in the boot partition as potentially any program residing
-on the verified partition may not function anymore. When the event is received,
-the persistent dm-verity state must be updated to set the mode flag to logging
-mode, and the device must be rebooted. When the device restarts,
-<code>init</code> will warn the user of changes to the partition before mounting it.</p>
+<p>When a dm-verity error is detected, the device must be rebooted and
+dm-verity must be started in logging mode during all subsequent restarts until
+any of the verified partitions is reflashed or changed by an OTA update. This
+means dm-verity state should be stored in a persistent flag. When a verified
+partition has been changed, the flag must be cleared and dm-verity must again
+be started in enforcing mode. Anytime dm-verity is not started in enforcing
+mode, a warning must be shown to the user before any of the verified partitions
+are mounted.</p>
 
 <h3 id=verified_partition>Verified partition</h3>
 
 <p>In a verified device, the system partition must always be verified. But any
-other read-only partition can also be set to be verified, as well. Specifically,
-any read-only partition that contains executable code must be verified on a
-verified device. This include the vendor partition, if one exists, for example.</p>
+other read-only partition should also be set to be verified, as well. Any
+read-only partition that contains executable code must be verified on a
+verified device. This includes vendor and OEM partitions, if they exist, for example.</p>
 
 <p>In order for a partition to be verified, signed verity metadata must be
 appended to it. The metadata consists of a hash tree of the partition contents
 and a verity table containing signed parameters and the root of the hash tree.
-If this information is missing or invalid when <code>init</code> attempts to
-mount the device, the user must be warned.</p>
+If this information is missing or invalid when dm-verity is set up for the
+partition, the user must be warned.</p>
 
 <h2 id=implementation_details>Implementation details</h2>
 
@@ -481,7 +410,6 @@
 
 <h3 id=signature_format>Signature format</h3>
 
-
 <p>The signature on an Android verifiable boot image is an ASN.1 DER-encoded
 message, which can be parsed with a decoder similar to the one found at: <a
 href="https://android.googlesource.com/platform/bootable/recovery/+/f4a6ab27b335b69fbc419a9c1ef263004b561265/asn1_decoder.cpp">platform/bootable/recovery/asn1_decoder.cpp</a><br/>
@@ -508,9 +436,9 @@
 <p>The <code>Certificate</code> field is the full X.509 certificate containing
 the public key used for signing, as defined by <a
 href="http://tools.ietf.org/html/rfc5280#section-4.1.1.2">RFC5280</a> section
-4.1. The bootloader must ignore this field and must NOT use the key
-specified in the certificate to verify the signature. Signatures must always be
-verified against the OEM key or the user-provided keystore only.</p>
+4.1. When LOCKED, the bootloader must always use the OEM key for verification
+first, and only boot to YELLOW or RED states if the embedded certificate is
+used for verification instead.</p>
 
 <p>The remaining structure is similar to that defined by <a
 href="http://tools.ietf.org/html/rfc5280#section-4.1.1.2">RFC5280</a> sections
@@ -526,7 +454,8 @@
   <li>Generate the unsigned image.
   <li>0-pad the image to the next page size boundary (omit this step if already
 aligned).
-  <li>Populate the fields of the <code>AuthenticatedAttributes</code> section above based on the padded image and desired target partition.
+  <li>Populate the fields of the <code>AuthenticatedAttributes</code> section
+      above based on the padded image and desired target partition.
   <li>Append the <code>AuthenticatedAttributes</code> structure above to the image.
   <li>Sign the image.
 </ol>
@@ -537,55 +466,23 @@
 a header).
   <li>Read the signature located at the offset above.
   <li>Validate the contents of the <code>AuthenticatedAttributes</code> field.
-If these values do not validate, treat it as a signature validation error.
+      If these values do not validate, treat it as a signature validation error.
   <li>Verify the image and <code>AuthenticatedAttributes</code> sections.
 </ol>
 
-<h3 id=keystore_format>Keystore format</h3>
-
-<p>The Android verified boot keystore format is an ASN.1 DER-encoded document. Its
- specification follows:</p>
-
-<pre>
-AndroidVerifiedBootKeystore DEFINITIONS ::=
-     BEGIN
-          FormatVersion ::= INTEGER
-          KeyBag ::= SEQUENCE {
-               Key  ::= SEQUENCE {
-                    AlgorithmIdentifier  ::=  SEQUENCE {
-                         algorithm OBJECT IDENTIFIER,
-                         parameters ANY DEFINED BY algorithm
-                    OPTIONAL
-                    }
-                    KeyMaterial ::= RSAPublicKey
-               }
-          }
-          Signature ::= AndroidVerifiedBootSignature OPTIONAL
-     END
-</pre>
-
-<p>Where <code>RSAPublicKey</code>, <code>AlgorithmIdentifier</code>, and
-parameters are as specified in <a
-href="http://tools.ietf.org/html/rfc3279#section-2.3.1">RFC3279</a>. Other key
-types specified in RFC3279 section 2.3 may optionally be supported,
-in which case the appropriate type for <code>Key</code> must be used.</p>
-
-<h3 id=keystore_location>Keystore location</h3>
-
-<p>The location of the keystore is not specified here, but that location must be
-known to the bootloader and both readable and writable by it. Reading should
-happen as per the above; writing a new keystore should be accomplished through
-<code>fastboot flash keystore &lt;path&gt;</code>. Sufficient storage must be
-provided for at least one key, with storage for additional keys recommended.</p>
-
 <h3 id=user_experience>User experience</h3>
 
 <p>A user in the GREEN boot state should see no additional user interaction besides that
-required by normal device boot. In other boot states, the user should see a
+required by normal device boot. In other boot states, the user must see a
 warning for at least five seconds. Should the user interact with the device during
-this time, the warning should remain visible until the user agrees to continue.</p>
+this time, the warning must remain visible at least 30 seconds longer, or until
+the user dismisses the warning.</p>
 
 <p>Sample user interaction screens for other states are shown in the following table:</p>
+
+<p class="table-caption" id="table5">
+  <strong>Table 5.</strong> Sample user interaction screens</p>
+
 <table>
  <tr>
     <td>