[anonymars]

Strawman? We are talking about this link, right, the one that says:

> I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).

> The reason we're having a conversation about providers being blocked is because the FIDO Alliance is considering extending attestation to cover roaming keys.

> From this conversation it sounds like the FIDO Alliance is leaning towards making it possible for services to block roaming keys from specific providers.

[eddythompson80]

Yes, read the quotes you took again. Attestation is not a thing currently. There is legitimate discussion about how to handle shitty password managers. If LastPass shits the bed again, it would be great to have a mechanism for others to block it or at least know that due to a major incident, keys from that tool are week. Debian OpenSSL keys were vulnerable for a long time and being able to know and alert or block private keys generated on a Debian machine is reasonable if not desirable. If KeepassXC is insecure or promote insecure practices who's fault is that and what do you suggest we do?

The entire issue is about doing the minimum possible of not exporting it in plaintext. Nothing is stopping you from decrypting it and posting it on your Twitter if you so wish. Just don't have the password manager encourage bad practices. How it that unreasonable?

[anonymars]

> If LastPass shits the bed again, it would be great to have a mechanism for others to block it

And by the way, if and when something like that does happen, what's the user supposed to do if they suddenly find their passkey provider has been blocked?

[reginald78]

Yes, we've seen you repeat that we have to read it again. I reread this morning before the post, but really just found more things supporting my position.

> To be very honest here, you risk having KeePassXC blocked by relying parties (similar to #10406).

From the linked https://github.com/keepassxreboot/keepassxc/issues/10406 > | no signed stamp of approval from on high > see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers.

> | RP's blocking arbitrary AAGUIDs doesn't seem like a thing that's going to happen or that can even make a difference > It does happen and will continue to happen because of non-spec compliant implementations and authenticators with poor security posture.

Is your argument that despite being doused with gasoline I can't complain because I'm not currently on fire?

[eddythompson80]

So you’re just not gonna respond to any of the points explaining your straw man. Yeah you should read it again, and read my explanation again and let me know if you have any questions or responses. Dont douse yourself in gasoline and you won’t have to worry about being on fire.

(You have every right do douse yourself in gasoline. No one is taking that way from you. Just say away from everyone else)

[anonymars]

Maybe you can let us know what definition of "strawman" you are using in this context?

KeePassXC is at risk of being blocked for making it easy to back up the passkeys. I don't see where that's been disproven or explained, other than saying "well attestation isn't enforced yet" -- that is, the metaphorical gasoline (provider AAGUIDs) hasn't yet been ignited (blocking of provider AAGUIDs)

> The entire issue is about doing the minimum possible of not exporting it in plaintext. Nothing is stopping you from decrypting it and posting it on your Twitter if you so wish. Just don't have the password manager encourage bad practices.

I don't disagree with this in principle, but it does warn you and realistically, what is the threat model here? It seems more like a defense-in-depth measure rather than a 5-alarm fire worthy of threatening to blacklist a provider. Maybe focus energy instead on this? (3+ year workstream now I guess?)

>> Sounds like the minimal export standard for portability needs to be defined as well.

> This is all part of the 2+ year workstream.

--

The more I get exposed to this topic, the less I'm convinced it was designed around people in the real world, e.g. https://news.ycombinator.com/item?id=44821601. Sure is convenient that it's so so easy to get locked into a particular provider, though!