W3C home > Mailing lists > Public > public-webauthn@w3.org > April 2020

Re: [webauthn] Add more requirements for ClientDataJSON serialisation. (#1375)

From: Adam Langley via GitHub <sysbot+gh@w3.org>
Date: Wed, 15 Apr 2020 23:12:39 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-614324973-1586992358-sysbot+gh@w3.org>
> Do we also need to make comments around verification of extensions and attestations, given that an implementation without JSON is somewhat likely to also not have an implementation of CBOR?

The differences stem from different sensitivities of different bits of code. Registering a new authenticator (during which attestation processing may be done) is usually less sensitive than pre-auth verification of a signature. Extension processing could be a problem, although the CBOR used is already significantly subsetted by CTAP2 and currently no authentication extensions are commonly used.

> There should be no justification for not requiring a standard JSON serializer and parser.

I roughly agree that JSON is not an unreasonably complex format, even in sensitive locations. I wrote a, I think, demonstrably memory-safe JSON parser as an example of how it could be done. However, it's not my decision and I must admit that, compared to SSH's length-prefixed bytestrings, JSON _is_ a lot more heavyweight and would significantly increase the amount of code in the highly-sensitive preauth flow.

(For those looking for a safe JSON parser in C, I suggest looking at the [Wuffs](https://github.com/google/wuffs) framework, on which the Chromium's future JSON parser may well be based.)

> Asking implementors to do manual serialization of part of a JSON document is almost guaranteed to result in one or more vulnerabilities.

I disagree here. While things could get hairy in general, the input strings here are either static values from the browser, base64url-encoded values, or punycoded origin strings. Of these, only the last is not trivially safe for plain template insertion. This is not a general data structure that's being encoded, it has a few, known keys and values. Lastly, there are few browser implementations and they have to do much more complex and subtle things to ensure safety in WebAuthn than this.

It's worth emphasing that no site needs to worry about this, and are recommended not to worry about this. No site need touch anything other than a standard JSON parser.

GitHub Notification of comment by agl
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1375#issuecomment-614324973 using your GitHub account
Received on Wednesday, 15 April 2020 23:12:42 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:40 UTC