On Wed, 2014-12-31 at 09:21 +0000, David Woodhouse wrote: > > This unfortunately had the issues summarized in David's email above. A > > certificate has signed and unsigned parts, meaning it can be modified so > > different fingerprints can refer to the same certificate, and a renewed > > certificate will have a different fingerprint by design. > > But that's not a problem in this case. We are only talking about using the > full sha1 in the UI for comparison with what the sysadmin wrote on a > post-it note, or what Firefox on a different machine shows in its > certificate info UI after it accepted the cert properly through the CA > that *is* installed there (remember, Kevin's focus is Android where > installing a new CA is a PITA and now seems to produce constant > "reminders" that your device is insecure and can be MITM-ed). > We are still going to actually *store* the new pubkey hash, and use that > for later connections. I think it will be confusing to use a different ID for the software to detect a changed certificate and another for a human. It would also raise questions why the human is not prompted even if the SHA1 fingerprint changed (e.g., in a certificate change). In addition it would not solve different openconnect clients printing different fingerprints. Maybe we could use both in the UIs to avoid such issues, but I'd strongly suggest to move to Key IDs. regards, Nikos
