Revert "Use existing kUserKeyPair keys during key creation, if possible."
This reverts commit 657a8c53. Reason for revert: ASAN errors; container overflow Original change's description: > Use existing kUserKeyPair keys during key creation, if possible. > > In CyptAuth v2 Enrollment, the user key pair--also known as > CryptAuthKeyBundle::Name::kUserKeyPair or "PublicKey"--has special > standing in order to 1) accommodate any existing key from v1 Enrollment > and 2) enforce that the key is not rotated. Only one user key pair > should exist in its key bundle, and it should be an active, P-256 key > with handle "device_key". > > It is possible that CryptAuth could request the creation of a new user > key pair even if the client sends information about an existing key in > the SyncKeysRequest. If this happens, the client should re-use the > existing user key pair key material when creating a new key. At the end > of the enrollment flow, the existing key will be replaced with this new > key that has the same public/private keys, but possibly with a new key > directive. > > It might seem more efficient to simply ignore the key-creation request, > but the method outlined above natually fits into the enrollment flow, > the key directive will be updated, and the client will be able to > provide CryptAuth with an EnrollKeys request, which it might be > expected. > > Bug: 899080 > Change-Id: I3a4a63aa902090698ecb619bc7af78ff1e790c23 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1504121 > Commit-Queue: Josh Nohle <nohle@chromium.org> > Reviewed-by: Kyle Horimoto <khorimoto@chromium.org> > Cr-Commit-Position: refs/heads/master@{#638327} TBR=khorimoto@chromium.org,nohle@chromium.org Change-Id: Ida02d62899eecc6a391e05b34bf576ff12e9541f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 899080 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1507279 Commit-Queue: Josh Nohle <nohle@chromium.org> Reviewed-by:James Hawkins <jhawkins@chromium.org> Cr-Commit-Position: refs/heads/master@{#638393}
Showing
This diff is collapsed.
This diff is collapsed.
Please register or sign in to comment