The interesting thing about Passkeys is that they are only ever output in the client create() call, and the platform does not retain them for disclosure after that, so if you don't send them out of the origin boundary, they are treated like a virtually secret value by the platform. It's ironic, because the WebAuthn/Passkey authors (who I know some of) explicitly treat the public key as a sensitive value, and built system assumptions around that, which is what makes this possible. It's a rather gross hack, can't deny it that, but there are a group of use cases for which it is a better fit than any of the far more ugly flows many non-P-256 self-custodied key use cases are accomplished with today.
> they are treated like a virtually secret value by the platform
"virtually" is the problem
for webauthn the public key isn't revealed to everyone for privacy reasons, not cryptographic reasons
the webauthn API is also only part of the cryptosystem
the platform authenticator (yubikey, windows hello, password manager, whatever) may have an API to list stored public keys without any authentication at all
It's a deliberate architectural decision that passkey authenticators not allow any retrieval or enumeration of key pairs - they don't even have internal APIs for it. This holds true for all known implementations, as it is a core principle of the system design.
The underlying CTAP implementations are only used by the platform to facilitate core activities, they are not used to expose key pairs to external parties. Please link to where any API offers up public keys to external userland actors, and any use of said APIs beyond core credential management. If this is assumed insecure/exposed, it would mean the system and its guarantees cannot be trusted as advertised, given both keys are supposed to be handled as a secure, opaque bundle, disclosed to no one beyond the bound origin at create time.
> Given both keys are supposed to be handled as a secure, opaque bundle, disclosed to no one beyond the bound origin at create time.
yes, there is no way to enumerate the public key in the webauthn api, but this is a property of the webauthn api only
the passkey cryptosystem consists of more than the webauthn api
there's the platform and roaming authenticators too
and you can't ignore them because they are the part of the passkeys cryptosystem that actually store the key material
and I have shown you, it is common for the layer below webauthn to support enumeration of the resident public keys
because... it's useful!
million dollar HSMs let you enumerate & see public keys, protected Java keystores let you enumerate & see the public keys, the windows certificate manager lets you enumerate & see public keys
(because surely no-one would be daft enough to try to build a secret key scheme out of the public keys of a pair?)
No need for the "oh dear"-ing before you provide evidence. I'm not aware of any command for fetch or enumeration of public keys in CTAP (was rather confident it doesn't provide any such thing). Care to link to what you were referring to?