Unclear whether compressed curve points need to be supported by RPs

[arianvp]

COSE_Key supports storing compressed points (https://tools.ietf.org/html/rfc8152#section-13.1.1):

if y is a boolean, consider it the sign of x, if y is a bstr consider it an uncompressed point.

However it's not clear for my from the Webauthn spec if compressed points need to be supported.
Especially https://w3c.github.io/webauthn/#sctn-public-key-easys says:

User agents MUST be able to return a non-null value for getPublicKey() when the credential public key has a COSEAlgorithmIdentifier value of:
-7 (ES256), where kty is 2 (uncompressed points) and crv is 1 (P-256).

which suggests kty = 2 always implies uncompressed points but this formulation is not normative and the COSE RFC says compressed points are not recommended due to IPR issues (what is IPR?) but that advise is also not normative

The latter encoding has not been recommended in the IETF due to potential IPR issues.

[arianvp]

I would also be interested if anybody could shed some light how a simple formula like:

y = +/-sqrt(x^3 + ax + b)

has IPR issues as I couldn't find any reference to it in the RFC. After some browsing I found https://patents.google.com/patent/US6130946A/en which is expired.

Not supporting compressed points and not recommending them will lead to many implementation mistakes where people miss a pointIsValid call.

I see that ECDAA was recently removed from Webauthn #1410
which largest critique was point compression ambiguity.

I would suggest two things going forward:

1. explicitly support FIDO devices that provide the COSE key in compressed form (I'm not sure if this conflicts with any of the FIDO specs? it might?)

2. Add explicit steps to 7. Webauthn Relying Party Operations which says that an implementor MUST make sure that any public key credential they receive has a point that lies on the curve of that public key credential so that people are at least made aware of the problem of uncompressed points when implementing a Relying Party

[ve7jtb]

IPR is Intellectual property rights
Code point compression has been a sensitive topic. IETF and W3C avoid making supporting compression mandatory.
We also avoid speaking the devils name so as to not invoke triple damages.
I have not looked at any patients in this respect.

I agree with making it clear that people need to validate uncompressed points.

[equalsJeffH]

on 2020-07-01 call: @agl proposes we add a note to L2 webauthn spec to ban compressed points. arguably it is a spec bug in that we are not as precise as we ought to be.

[arianvp]

Lets also add language that you need to explicitly validate any public key to make sure it's on the curve to stop invalid curve attacks

[agl]

As noted, we decided to prohibit compressed points rather than explicitly support them. Uncompressed points are the norm so we can, at most, add to that baseline. Since there's no utility in saving a small number of bytes in this context, we've chosen to eliminate the option instead. (In practice, even if we technically required support for compressed points, support would be threadbare and they would not be practically usable anyway.)

As for calling out point validation: there are lots of checks needed during signature validation and we don't want to reproduce every signature algorithm specification in WebAuthn. However, having skimmed over the two ECDSA references, I admit that point validation is not highlighted in them, so I'll put that in too. (Although, if an attacker can substitute a public key during registration, there are larger problems. So it's just to catch errors in the authenticator.)