W3C home > Mailing lists > Public > public-webauthn@w3.org > August 2016

Re: [webauthn] Clarify meaning of UVI

From: gmandyam via GitHub <sysbot+gh@w3.org>
Date: Mon, 08 Aug 2016 17:11:05 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-238303979-1470676263-sysbot+gh@w3.org>
@rlin1

"External applications cannot verify whether an authenticator is 
honest about (a) or (b) (or does something else).
Security certification schemes will be able to do so."

I don't see how security certification schemes can verify anything 
without knowing how the authenticator generates the UVI.

"I am not sure we can find a way to specify rawUVI formula which is 
sufficiently generic to be used for all kinds of biometric modalities 
and implementations."

Implementations that do not find the pre-registered UVI extension 
acceptable should be able to register their own proprietary formats 
when a registry is formally established by the group.

"Given the proposed formula for UVI being UVI = HASH(publicKey, 
rawUVI), I don't know how any rawUVI value could be misused as a 
side-channel (unless HASH is cryptographically broken)."

And what is to prevent an authenticator vendor from agreeing with an 
RP on an inband protocol and using a broken hash function so that the 
RP can peek into the data?

I appreciate the effort to provide a clarifying definition of UVI, but
 I think we are back to the original issue - UVI is inscrutable from 
the browser perspective and can be abused.  Maybe we should stick to 
the original definition of UVI as it is currently in the spec (which 
boils down to a max 32-byte opaque payload) and add a note that UVI 
can be prone to misuse and therefore the user agent should only allow 
this extension to pass if the authenticator has achieved certification
 from a trusted 3rd party.

-- 
GitHub Notification of comment by gmandyam
Please view or discuss this issue at 
https://github.com/w3c/webauthn/issues/156#issuecomment-238303979 
using your GitHub account
Received on Monday, 8 August 2016 17:13:12 UTC

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