Re: [Rats] Android comments on EAT draft

[Mathias Brossard <[e-mail]>]

Hi,

The idea is that a device might want to attest a key that would be used for other purposes than proof-of-possession (authentication). The attestation token would act as a form of certificate, essentially the link between a key to a device. We are thinking about integrity (signature) and encryption / key agreement. In many cases you could use TLS with PoP to provide the same kind of security properties. But in some cases there is no IP connectivity, the resources are too constrained or you want the security to be maintained end-to-end (rather than at the transport layer).

The protocol flow would not change for attestation.

Sincerely,
-- Mathias Brossard

From: Laurence Lundblade <[e-mail]>
Date: Friday, May 17, 2019 at 6:57 PM
To: Mathias Brossard <[e-mail]>
Cc: Simon Frost <[e-mail]>, Shawn Willden <swillden=[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Rats] Android comments on EAT draft


On May 16, 2019, at 9:31 AM, Mathias Brossard <[e-mail]<mailto:[e-mail]>> wrote:

But even for the relatively simple use-case of putting a public key in a token, which it technically supports, I am worried that the semantics might be too constraining. It focuses on proof-of-possession (PoP), where we are thinking about additional functions (signature, encryption, key agreement, etc.).

Mathias, can you say more about the additional functions you are thinking about?

Would they change the protocol flow in a big way? Mostly what we are thinking is that the RP sends a nonce to the device and the device returns a token.

LL


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.