Re: [Rats] Android comments on EAT draft

[Laurence Lundblade <[e-mail]>]

Seems like we can define the inclusion of a public key in an attestation token to mean whatever we want. We don’t have to restrict ourselves to the semantics implied by draft-ietf-ace-cwt-proof-of-possession-06 (and usage for authentication only seems implied). 

Maybe there is optional key usage associated with the key. If the key usage is absent, then there is no restriction. The key usage would look something like X.509 Extended Key Use <https://tools.ietf.org/html/rfc5280#section-4.2.1.12>.

(Is proof-of-possesion a term defined somewhere that I don’t know about to mean something very specific? If so where is this definition?)

LL


> On May 20, 2019, at 11:03 PM, Mathias Brossard <[e-mail]> wrote:
> 
> 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.