> From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Michael > Ströder via openssl-users > Sent: Sunday, 18 September, 2022 04:27 > > On 9/18/22 06:09, Philip Prindeville wrote: > >> On Sep 15, 2022, at 4:27 PM, Michael Wojcik via openssl-users <openssl- > users@xxxxxxxxxxx> wrote: > >> You still haven't explained your threat model, or what mitigation > >> the application can take if this requirement is violated, or why > >> you think this is a "best practice". > > > The threat model is impersonation, where the legitimate key has been > > replaced by someone else's key, and the ensuing communication is > > neither authentic nor private. > > Maybe I'm ignorant but shouldn't this be prevented by ensuring the > authenticity and correct identity mapping of the public key? Exactly. In most protocols the public key, not the private key, authenticates the peer. Relying on file system metadata (!) as the root of trust for authentication, particularly for an application that may be running with elevated privileges (!!), seems a marvelously poor design. > > Otherwise, the owners of the system can't claim non-repudiation as to > > the genuine provenance of communication. I'm with Peter Gutmann on this. Non-repudiation is essentially meaningless for the vast majority of applications. But in any case, filesystem metadata is a poor foundation for it. > More information is needed about how you're system is working to comment > on this. Indeed. This is far from clear here. -- Michael Wojcik
