0

Previously some good fellow explained the importance of verifying the public key created and offered by authenticators.

As before, given the complexity of a FULL implementation of RP operation, I believe it's possible that some aspect may be mis-implemented for someone doesn't fully understand the spec (e.g. having to implement ECDAA to verify some attestation formats).

So Q1: Is it reasonable to implement just a subset of WebAuthn relaying party operation? E.g. accepting only "self" attestation and "none" attestation format so that the public key can be used to verify itself, without having to trace a trust anchor in the x5c array structure? Q2: Is there a "mandatory" attestation statement format and optional ones?

1 Answer 1

2

Q1: Is it reasonable to implement just a subset of WebAuthn relaying party operation?

Yes. The purpose of attestation is to enable users to self-provision authenticators ("bring your own device"), while still enabling relying parties (RPs) to verify the security properties of the authenticator if the RP needs it. For example, a bank might require that the authenticator meets some particular certification to be eligible for use with that bank's services. The bank can then either provision the authenticator for the user (i.e., send one by mail), or let the user do it themself as long as the chosen authenticator has the required certification. Attestation enables the bank to authenticate trusted authenticator vendors remotely.

If you (a web service) don't need these kinds of guarantees about who the authenticator vendor is and what the authenticator's security properties are, then you do not need to verify the attestation. In fact attestation is disabled by default, and WebAuthn issue #1710 tracks an initiative to make attestation verification more clearly optional in the spec.

A special case worth noting is "self attestation", where the credential private key is used instead of a vendor attestation key. This doesn't provide much benefit since the attestation signature can be replaced along with the credential public key, so a self attestation cannot meaningfully prove any security characteristics in the way other attestations can. At most, a self attestation protects against accidental data corruption during transmission, but it does not protect against malicious tampering. Part of these concerns also apply to other forms of attestation, as described in the security considerations section §13.4.4. Attestation Limitations: an attestation can prove what kind of hardware holds the credential private key, but it cannot prove who is in possession of that hardware.

Some more discussion of when attestation may or may not be needed, in the context of the question "when can the RP trust the UV flag?", can be found in WebAuthn issue #1698. Here is a summary:

[...] it depends on your threat model, what you mean by "trust", and whose trust you're talking about.

1. UV on the user's initiative

In this scenario, the RP doesn't really care [...], it only wants to enable users to customize their authentication experience. [...] Attestation is not necessary, because the RP only cares about getting a signature from an already-registered public key.

2. UV as a "best effort"

In this scenario, the RP may require UV for some interactions [...] but isn't really worried about the flag's authenticity. If the user happens to be using an honest authenticator and browser, which most users probably will, then this gives a reasonable assurance [...]. There's still the possibility that some users might [...] [lie] [...], but if so, that's the user's responsibility.

[...] The RP might request and store attestation statements for future reference - for example to warn users if an authenticator model is discovered to be insecure - but it's not strictly necessary since [...] the RP largely "trusts" the user to not do anything stupid.

3. UV strictly required

[...] For example, the RP may be subject to legal regulations that require certain security properties. In this case the RP simply must require attestation and only allow explicitly trusted authenticators, because there's no other way to know that the user, authenticator and/or browser isn't lying. [...]

Q2: Is there a "mandatory" attestation statement format and optional ones?

Only for various certification programs. As explained above, it is up to each RP (and any security auditors it may be subject to) to decide its policy for what attestation, if any, is required. If the RP does use attestation, then it is in that RP's own interest to be compatible with as many relevant attestation statement formats as possible.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .