fastmail.com doesn't accept generic U2F certificates |
|||||
Issue descriptionfastmail.com expects to be able to parse a valid ECDSA signature out of the self-signed part of a U2F certificate. Thus we should give it one. Bug filed for tracking merge into M66.
,
Mar 14 2018
Requesting merge to M66 for the change linked to this bug. The change has been on Canary for a day without issues. Risks: This change makes our synthesised attestation certificates look more like a real one, so the compatibility risks are minimal. Additionally, it fixes one user of U2F (fastmail.com) and hasn't affected any of the other sites that I've tested.
,
Mar 14 2018
Approving merge for M66. Branch:3359
,
Mar 14 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3bc138f85d63a1873113357006f325d8ceeeb1ef commit 3bc138f85d63a1873113357006f325d8ceeeb1ef Author: Adam Langley <agl@chromium.org> Date: Wed Mar 14 20:21:08 2018 cryptotoken: provide parsable certificate signature. The replacement attestation certificates didn't provide a self-signature because nobody can validate our certificates. However, fastmail.com expects to be able to parse an ECDSA signature even if they don't check it. Therefore this change provides a syntactically valid signature in the certificate and fixes enrollment on fastmail.com Bug: 821099 Change-Id: I332e078227eb36ba81e4cb089bd1f63ceb0bcbea Reviewed-on: https://chromium-review.googlesource.com/959304 Reviewed-by: David Benjamin <davidben@chromium.org> Commit-Queue: Adam Langley <agl@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/963229 Reviewed-by: Adam Langley <agl@chromium.org> Cr-Commit-Position: refs/branch-heads/3359@{#246} Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276} [modify] https://crrev.com/3bc138f85d63a1873113357006f325d8ceeeb1ef/chrome/browser/resources/cryptotoken/enroller.js
,
Mar 14 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by bugdroid1@chromium.org
, Mar 12 2018