Provide escape hatch for currently-unsupported attestation #69
Comments
Firehed
added a commit
that referenced
this issue
Feb 25, 2024
By default, the library will require _any_ sort of "certain" trust path during credential registration - this is actually slightly stricter than the previous behavior, as `Packed` formats _can_ result in this path. To compensate (and as a bonus, ease library development), this provides a new flag that can be passed to the registration verification process that _permits_ these uncertain paths to go through. In effect, if this flag is set, any credential has the security implications of the `none` format: you really know nothing about it, but authentication still is cryptographically verified. In the common case this means nothing, since (at minimum) Apple's implementation of passkeys uses `fmt: none` and blocking them is likely undesirable for most people. Fixes #69.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At present, not all attestation formats are fully supported, and since there aren't yet official test vectors (just w3c/webauthn#1633 that I'm aware of) that cover all of the format and key type combinations, it'll be a slow iterative approach to get 100% coverage.
In the meantime, it may be desirable to still register credentials that are on an unverified trust path: not all applications will care about the attestation, and in any case, the process for creating test vectors for this library could benefit from the same tooling.
This should NOT be the default behavior as it's less secure than the default behavior when attestation is provided. In effect, it's "treat attestation as
noneeven if one was provided, which may be reverified later".Highly related to #62.
My initial inclination is this looks like an additional optional parameter to
AttestationInterface::verify(), possiblyEnums\AttestationConveyancePreference(or a simple boolean), that roughly amounts totry { ao->verify() } catch { if (attIsSafeToIgnore) { trustPath = none } else { rethrow } }. There are some subtleties here though - it's more dependent on library support for a given attestation format than ignoring a failed verification of something fully supported.The text was updated successfully, but these errors were encountered: