Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification on CBOR-encoding of COSE keys #2054

Closed
zacknewman opened this issue Mar 28, 2024 · 4 comments
Closed

Clarification on CBOR-encoding of COSE keys #2054

zacknewman opened this issue Mar 28, 2024 · 4 comments

Comments

@zacknewman
Copy link

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?

@MasterKale
Copy link
Contributor

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 🤔

@zacknewman
Copy link
Author

zacknewman commented Mar 28, 2024

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

@zacknewman
Copy link
Author

zacknewman commented Mar 28, 2024

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.

@zacknewman
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants