w3c / webauthn

Web Authentication: An API for accessing Public Key Credentials

Home Page:https://w3c.github.io/webauthn/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Clarification on CBOR-encoding of COSE keys

zacknewman opened this issue · comments

The CTAP2 canonical CBOR encoding form does not restrict the CBOR major type that MUST be used for parameters that are allowed to have multiple types. For example the value for kty is allowed to be a tstr or int (e.g., "OKP" or 1 for an octet key pair). "In the wild" I've really only encountered the use of int for such a thing. Is it truly the case that kty can be a tstr? More generally, is it actually the case when a parameter value can have multiple major types according to RFCs 9052 and 9053, that all such major types be allowed; or is this an oversight, and the most compact type MUST be used?

Funny you should mention that, there was some issues back in August with Firefox returning "OKP" for kty instead of 1 - it broke some libraries (like the ones I maintain) that weren't expecting to get a string. @emlun noted here that:

As far as I can tell, all actual values in the COSE registry (the "Value" and "Label" columns) seem to be integer typed.

So in practice there's something to point and say, "kty should only be int around here". But as you note there's currently nothing in the spec that explicitly forbids use of tstr 🤔

Interesting. I'll have to ruminate if my library should support such types then.

I sent an e-mail to the COSE mailing list at IETF for clarification if tstr is in fact allowed for kty, alg, and crv. If they reply and do so in the affirmative, then perhaps CTAP2 canonical CBOR encoding form should be amended to restrict such parameters to only be int types seeing how the intent of it appears to be to reduce the payload sizes.

I'll respond here with the response if I get one. As of now, I'll interpret the RFCs that while such parameters are allowed to be tstrs, only ints have been defined; thus only (the registered subset of values of) ints should be allowed. In the future new values may be added to the IANA registry that are tstrs; but until then, my parser will only parse ints and allow the subset of values defined in the registry.

Well I never got an e-mail response, so I'll enforce that the values are ints until tstrs are added to the registry as well.