RE: Attestation formats

That seems reasonable at a high level, but I still have the question - how are extensions supported on the TPM and Android formats? Or are they not supported at all?

It seems to me that every scheme is capable of signing arbitrary rawData, since every scheme takes in a challenge to sign, and the rawData could for example be hashed into the challenge. That would also make for uniform support of things like extensions across all formats.

The way the spec is currently written, it seems like every new attestation format can similarly describe its own support for all these things, which seems like a recipe for long-term inconsistency.

From: Rolf Lindemann [mailto:rlindemann@noknok.com]
Sent: Friday, July 22, 2016 12:06 AM
To: Vijay Bharadwaj <vijaybh@microsoft.com>; 'W3C WebAuthn WG' <public-webauthn@w3.org>; 'Rolf Lindemann' <rlindemann@noknok.com>
Subject: AW: Attestation formats

Hi Vijay,

the rawData is always generated by the authenticator.
In the initial attestation section, there was a single JSON attestationStatement structure and different rawData formats (one for packed, one for TPMs and one for SafetyNet).
The idea was to replace the SafetyNet one by Android "N" HW key attestation.
In that case we would have 3 different but similarly capable rawData structures.
Note that at this time, the TPMs are *not* generating packed attestation nor des Android "N" generate it (even though it supports HW attestation).

>From a security perspective, the attestation rawData structure needs to be controlled and signed by the Authenticator (or its crypto kernel).

I don't think that "A method to take in a rawData in the above format and produce a signature" makes much sense as it suggests to get an arbitrary rawData object signed.

I would propose the following:

1.       Remove the SafetyNet thing at this offers substantially different security guarantees than all others and replace it by Android "N" attestation.

2.       Define a single attestationStatmeent (JSON) structure.

3.       Keep the different attestation rawData formats (i.e. Android "N", TPM and "packed".

4.       Potentially add more rawData formats (by the registry approach) if this cannot be avoided in order to supports other plaforms.

Kind regards,
    Rolf

Von: Vijay Bharadwaj [mailto:vijaybh@microsoft.com]
Gesendet: Freitag, 22. Juli 2016 08:19
An: W3C WebAuthn WG; Rolf Lindemann
Betreff: Attestation formats

I was looking through the attestation formats and it seems to me that this area could use some cleanup. All the formats are defined in very different ways and it's not clear that all of them are equally capable. For instance none of the formats other than packed are able to deal with extensions at all. Also, Android attestation is quite weird in that it extends the ClientData with fields that really should be authenticator-attested.

I would like to revise this section significantly, and organize it as follows:

-          In the core spec, define the rawData format for packed attestation as the thing that is always generated by the authenticator. This could even be extended by the above (Android) fields if necessary.

-          Define an attestation format as consisting of the following things:

o   A method to take in a rawData in the above format and produce a signature

o   A method to verify the above signature

-          Rewrite the attestation formats section in the above format

This would also allow for adding new attestation formats in the future by taking a registry approach, as Giri had suggested.

What do others think? If we have some momentum around this idea I can do up a PR by early next week.

--
-Vijay