Subject: [Rats] Public Key Claims in JWT / CWT

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Nov 2019 08:28:01 +0000

Hi all,

Here is some background info to the discussions today in the RATS WG meeting.

With RFC 7800 we added the "cnf" claim to the JWT to contain members used to identify the proof-of-possession key.
It re-uses the work done for JSON Web Key, including key ids, JWK Thumbprints, symmetric as well as asymmetric keys.
This claim has been registered with IANA at https://www.iana.org/assignments/jwt/jwt.xhtml

Later, after working on CWT we created the corresponding functionality for https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-11.
It aims to provide functionality equivalent to RFC 7800. The spec re-uses the "COSE_Key" and "Encrypted_COSE_Key" structures defined in RFC 8392.
draft-ietf-ace-cwt-proof-of-possession-11 is in the RFC Editor Queue and the IANA registry value for cnf is already available in https://www.iana.org/assignments/cwt/cwt.xhtml

These specs are implemented and deployed.

I would be surprised if you cannot reuse this functionality in the EAT token for offering proof-of-possession functionality.

Ciao
Hannes

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.

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 19 Nov 2019 11:05:47 +0000

Thanks Hannes.

I don't know if 'cnf' semantics would actually cover something like FIDO's Credential ID (see https://www.w3.org/TR/webauthn/#terminology for definition), which would also be a candidate for public key attestation.  For instance, would a Cred ID be designated as a 'kid' as per the ACE PoP spec, or would there need to be a custom claim?

-Giri

From: RATS <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Tuesday, November 19, 2019 12:28 AM
To: [email-masked]
Subject: [Rats] Public Key Claims in JWT / CWT

CAUTION: This email originated from outside of the organization.
Hi all,

Ciao
Hannes

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 19 Nov 2019 21:20:49 +0800

Aware of these and wouldn’t think of doing it any other way, but I think we need a little glue, like IANA registrations at a minimum.

If we want augment this stuff that already exists with things like key ID and key usage like the Android key store has, then we’ll need to do more. I don’t have a strong opinion on how far we go yet.

Probably the combo of COSE_Key + proof-of-possesion gives us a CBOR-based CSR, but I’m not quite sure if that covers the use case(s) unless we think it through. 

Also, someone might actually want a true PKCS10 for compatibility reasons.

I think including pub keys also begs questions about the attestation context Giri has brought up.

LL

> On Nov 19, 2019, at 4:28 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all, 
>  
> This claim has been registered with IANA at https://www.iana.org/assignments/jwt/jwt.xhtml <https://www.iana.org/assignments/jwt/jwt.xhtml>
>  
> Later, after working on CWT we created the corresponding functionality for https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-11 <https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-11>.
> draft-ietf-ace-cwt-proof-of-possession-11 is in the RFC Editor Queue and the IANA registry value for cnf is already available in https://www.iana.org/assignments/cwt/cwt.xhtml <https://www.iana.org/assignments/cwt/cwt.xhtml>
>  
> 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. _______________________________________________
> RATS mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>