Category: CBOR Page 1 of 4

Orie Steele and I have updated the “Fully-Specified Algorithms for JOSE and COSE” specification to incorporate working group last call (WGLC) feedback. Thanks to all who took the time to comment on the draft. Your feedback was exceptionally actionable and helped to substantially improve the specification. Responses to each WGLC comment thread were sent on the IETF JOSE working group mailing list.

The updated draft attempts to discuss the full range of the problems created by polymorphic algorithm identifiers. Guided by working group feedback, it strikes an engineering balance between which of these problems to fix immediately in the specification and which to describe how future specifications can fix later as the need arises.

I look forward to discussing next steps for the specification at IETF 120 in Vancouver.

The specification is available at:

https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-03.html

CBOR Web Token (CWT) Claims in COSE Headers is now RFC 9597

On June 24, 2024

The CBOR Web Token (CWT) Claims in COSE Headers specification has been published as RFC 9597! This closes a gap for COSE relative to JOSE, adding the ability to use CWT claims in COSE header parameters, just as JWT claims can be used in JOSE header parameters.

The specification abstract is:

This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all.

Special thanks to my co-author Tobias Looker, who had a use case for this functionality and wrote an RFC with me defining it (his first!). It was a pleasure working with Tobias on the draft as we navigated the ins and outs of working group feedback and IETF processes. The spec was refined by the journey we took together. And as with CBOR Object Signing and Encryption (COSE) “typ” (type) Header Parameter (now RFC 9596) that immediately preceded it, I believe the CBOR and COSE ecosystems are better for it.

COSE “typ” (type) Header Parameter is now RFC 9596

On June 11, 2024

The CBOR Object Signing and Encryption (COSE) “typ” (type) Header Parameter specification has been published as RFC 9596! This closes a gap for COSE relative to JOSE, adding the ability to use media types to declare the content of the complete COSE object.

The specification abstract is:

This specification adds the equivalent of the JSON Object Signing and Encryption (JOSE) “typ” (type) header parameter to CBOR Object Signing and Encryption (COSE). This enables the benefits of explicit typing (as defined in RFC 8725, “JSON Web Token Best Current Practices”) to be brought to COSE objects. The syntax of the COSE type header parameter value is the same as the existing COSE content type header parameter.

Special thanks to my co-author Orie Steele, who pointed out the gap and proposed that we close it. He was an active participant and insightful partner in making this RFC happen (his first!). The CBOR and COSE ecosystems are better for it.

Standards are About Making Choices

On June 9, 2024

In CBOR, Claims, Cryptography, Events, FIDO, IETF, Interoperability, JSON, OAuth, OpenID, Phishing Resistance, Specifications, W3C

EIC 2024 Logo I was honored to give the keynote presentation Standards are About Making Choices at the 2024 European Identity and Cloud Conference (PowerPoint) (PDF). The abstract was:

When building machines, we take for granted being able to use nuts, bolts, wires, light bulbs, and countless other parts made to industry standards. Standards contain choices about dimensions of screw threads, nut sizes, etc., enabling a marketplace of interoperable parts from multiple suppliers. Without these choices, every part would be custom manufactured. The same is true of the identity and security standards we use to build identity systems.

However, the identity and security standards at our disposal differ wildly in the degree to which they do and don’t make choices. Some consistently define ONE way to do things, resulting in everyone doing it that way (interoperability!). Others leave critical choices unmade, passing the buck to implementers and applications (your mileage may vary).

In this talk, I’ll name names and take prisoners, critiquing existing and emerging standards through the lens of the choices they made and failed to make. Hold on to your hats as we examine the pros and cons of the choices made by OAuth, SAML, X.509, OpenID Connect, Verifiable Credentials, DIDs, WebCrypto, JOSE, COSE, and many others through this lens!

I believe you’ll agree with me that making choices matters.

The conference keynote description includes a recording of the presentation.

Thanks to MATTR for providing a designer to work with me on the presentation, enabling the visual design to transcend my usual black-text-on-white-background design style!

Using Standards: Some Assembly Required

On May 30, 2024

In CBOR, Claims, Cryptography, Events, FIDO, IETF, Interoperability, JSON, OAuth, OpenID, Phishing Resistance, Specifications, W3C

Identiverse Logo I gave the following presentation in the session Using Standards: Some Assembly Required at the 2024 Identiverse conference (PowerPoint) (PDF). The abstract was:

Standards are about making choices. When building machines, we take for granted being able to use nuts, bolts, wires, light bulbs, and countless other parts made to industry standards. Standards contain choices about dimensions of screw threads, nut sizes, etc., enabling a marketplace of interoperable parts from multiple suppliers. Without these choices, every part would be custom-manufactured. The same is true of the identity and security standards we use to build the Identity Engine. However, the identity and security standards at our disposal differ wildly in the degree to which they do and don’t make choices. Some consistently define ONE way to do things, resulting in everyone doing it that way (interoperability!). Others leave critical choices unmade, passing the buck to implementers and applications (your mileage may vary). In this talk, I’ll name names and take prisoners, critiquing existing and emerging standards through the lens of the choices they made and failed to make. Hold on to your hats as we examine the pros and cons of the choices made by OAuth, SAML, X.509, OpenID Connect, Verifiable Credentials, DIDs, WebCrypto, JOSE, COSE, and many others through this lens! I believe you’ll agree with me that making choices matters.

The audience was highly engaged by the process of giving existing and emerging standards letter grades based on the choices they made (or failed to make)!

Securing Verifiable Credentials using JOSE and COSE is now a W3C Candidate Recommendation

On April 28, 2024

In CBOR, Claims, Cryptography, JSON, Specifications, W3C

The Securing Verifiable Credentials using JOSE and COSE specification (a.k.a. VC-JOSE-COSE) has reached W3C Candidate Recommendation status. The Candidate Recommendation milestone is described in the W3C Process document. Please review the Candidate Recommendation of VC-JOSE-COSE. Thanks especially to Gabe Cohen, Orie Steele, and Brent Zundel for doing the hard work of getting us to this point!

Since I last wrote about this work, the W3C Verifiable Credentials Data Model (VCDM), which is also at Candidate Recommendation stage, has been narrowed to only use JSON-LD to represent credentials. VC-JOSE-COSE secures VCDM payloads with JOSE, SD-JWT, or COSE signatures. While I’m admittedly not a fan of JSON-LD, to the extent that Verifiable Credentials using the VCDM are in use, I’m committed to finishing a solid VC-JOSE-COSE specification so there is a simple, secure, standards-based way to sign these credentials.

Of course, there are lots of Verifiable Credential formats to choose from, and more on the way. Choices already existing include ISO mDoc, IETF SD-JWT, IETF JSON Web Proof (JWP), and W3C VCDM. The IETF is also planning to create a CBOR-based selective disclosure representation in the newly formed SPICE working group. It will be interesting to see how these all shake out in the marketplace!

COSE “typ” (type) Header Parameter Specification in RFC Editor Queue

On April 12, 2024

I’m pleased to report that the COSE “typ” (type) Header Parameter Specification has been approved by the IESG and is now in the RFC Editor queue.

The version approved by the IESG and sent to the RFC Editor is:

https://www.ietf.org/archive/id/draft-ietf-cose-typ-header-parameter-05.html

It joins CBOR Web Token (CWT) Claims in COSE Headers in the RFC Editor queue. Because of the reference to this spec by CWT Claims in Headers, they form a cluster, and therefore will become RFCs at the same time.

Eight Specifications Published in Preparation for IETF 119

On March 20, 2024

In CBOR, Claims, Cryptography, Events, IETF, JSON, Specifications

My co-authors and I published updated versions of eight specifications in preparation for IETF 119 in Brisbane. The specifications span three working groups: JOSE, COSE, and OAuth. The updated specifications and outcomes when discussed at IETF 119 are as follows.

1, 2, & 3: JSON Web Proof, JSON Proof Algorithms, and JSON Proof Token. Updates were:

Normatively defined header parameters used
Populated IANA Considerations sections
Allowed proof representations to contain multiple base64url-encoded parts
Specified representation of zero-length disclosed payloads
Added Terminology sections
Updated to use draft-irtf-cfrg-bbs-signatures-05
Updated to use draft-ietf-cose-bls-key-representations-04
More and better examples
Improvements resulting from a full proofreading

Continued reviews and feedback from implementations are requested.

4: Fully-Specified Algorithms for JOSE and COSE. Updates were:

Published initial working group document following adoption
Added text on fully-specified computations using multiple algorithms
Added text on KEMs and encapsulated keys
Updated instructions to the designated experts

It was agreed during the JOSE meeting to describe what fully-specified algorithms for ECDH would look like, for consideration by the working group.

5: OAuth 2.0 Protected Resource Metadata. Updates were:

Switched from concatenating .well-known to the end of the resource identifier to inserting it between the host and path components of it
Have WWW-Authenticate return resource_metadata URL rather than resource identifier

It was decided to start working group last call during the OAuth meeting.

6: COSE “typ” (type) Header Parameter. Updates were:

Added language about media type parameters
Addressed working group last call comments
Changed requested assignment from 14 to 16 due to conflict with a new assignment
Addressed GENART, OPSDIR, and SECDIR review comments

This document is scheduled for the April 4, 2024 IESG telechat.

7: Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE. Updates were:

Changed to use key type EC for JOSE and equivalent EC2 for COSE for uncompressed key representations
Changed identifier spellings from “Bls” to “BLS”, since these letters are people’s initials

We received feedback to not add compressed key representations to the draft.

8: Use of Hybrid Public-Key Encryption (HPKE) with JavaScript Object Signing and Encryption (JOSE). Updates were:

Use existing "alg": "dir" value for HPKE Direct Encryption mode
Aligned choices more closely with those of Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE)
Defined both Integrated Encryption mode and Key Encryption mode
Added IANA Considerations section
Removed Post-Quantum Considerations

It was decided to start a working group call for adoption during the JOSE meeting.

Thanks to all who contributed to the progress made on these specifications, both before and during IETF 119!

COSE “typ” (type) Header Parameter Specification Addressing IETF Last Call Feedback

On February 26, 2024

Orie Steele and I have updated the COSE “typ” (type) Header Parameter Specification to address feedback received during IETF Last Call. No normative changes were made.

Thanks to those that reviewed the specification!

The specification is available at:

https://www.ietf.org/archive/id/draft-ietf-cose-typ-header-parameter-03.html

Besides the spec being useful on its own, it’s worth noting that the CBOR Web Token (CWT) Claims in COSE Headers specification references this spec, and so won’t exit the RFC Editor queue as an RFC until this one also does.

Fully-Specified Algorithms adopted by JOSE working group

On January 31, 2024

The “Fully-Specified Algorithms for JOSE and COSE” specification has been adopted by the JOSE working group. See my original post about the spec for why fully-specified algorithms matter. Thanks to all who supported adoption and also thanks to those who provided useful detailed feedback that we can address in future working group drafts.

The specification is available at:

https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-00.html

BLS Key Representations for JOSE and COSE updated for IETF 118

On October 24, 2023

In CBOR, Claims, IETF, JSON, Privacy, Specifications

Tobias Looker and I have published an updated Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE specification in preparation for IETF 118 in Prague. This one of suite of IETF and IRTF specifications, including BLS Signatures and JSON Web Proofs that are coming together to enable standards for the use of JSON-based and CBOR-based tokens utilizing zero-knowledge proofs.

The specification is available at:

https://www.ietf.org/archive/id/draft-ietf-cose-bls-key-representations-03.html

CBOR Web Token (CWT) Claims in COSE Headers Draft Addressing IETF Last Call Comments

On October 24, 2023

Tobias Looker and I have published an updated CBOR Web Token (CWT) Claims in COSE Headers specification that addresses the IETF Last Call (WGLC) comments received. Changes made were:

Added Privacy Consideration about unencrypted claims in header parameters.
Added Security Consideration about detached content.
Added Security Consideration about claims that are present both in the payload and the header of a CWT.
Changed requested IANA COSE Header Parameter assignment number from 13 to 15 due to subsequent assignments of 13 and 14.
Acknowledged last call reviewers.

The specification is available at:

https://www.ietf.org/archive/id/draft-ietf-cose-cwt-claims-in-headers-07.html

The specification is scheduled for the IESG telechat on November 30, 2023.

Fully-Specified Algorithms updated in preparation for IETF 118

On October 20, 2023

Orie Steele and I have updated the “Fully-Specified Algorithms for JOSE and COSE” specification in preparation for presentation and discussions at IETF 118 in Prague. The updates address comments received during the discussions at IETF 117 and afterwards. Specifically, this draft adds descriptions of key representations and of algorithms not updated by the specification. See my original post about the spec for why fully-specified algorithms matter.

Hopefully working group adoption will be considered by the JOSE working group during IETF 118.

The specification is available at:

https://www.ietf.org/archive/id/draft-jones-jose-fully-specified-algorithms-02.html

Adoption Time! And Lessons Learned…

On September 6, 2023

In CBOR, IETF, JSON, OAuth, Specifications

I’ve had two different IETF specifications adopted by two different working groups in the last two days – a pleasant coincidence! Yesterday, the COSE “typ” (type) Header Parameter specification was adopted by the COSE working group. Today, the OAuth 2.0 Protected Resource Metadata specification was adopted by the OAuth working group. Their journeys from individual drafts to working group drafts couldn’t have been more different!

As I was musing with Phil Hunt, who wrote the original individual draft of OAuth 2.0 Protected Resource Metadata with me, I’m pretty sure that this is the longest time from writing an individual draft to it becoming a working group draft in my experience: August 3, 2016 to September 6, 2023 – seven years and a month!

Whereas, the time from the individual draft of COSE “typ” (type) Header Parameter to the first working group draft was only three months: July 8, 2023 to September 5, 2023. Which got me thinking… Is that the fastest progression I’ve had?

It turns out that my fastest time from individual draft to working group draft was for the JWK Thumbprint URI specification which I wrote with Kristina Yasuda. It went from individual draft to working group draft in only two months: November 24, 2021 to January 28, 2022. (And it became RFC 9278 on August 9, 2022 – less than nine months from start to finish, which I believe is also a personal record.)

Ironically, while OAuth 2.0 Protected Resource Metadata took over seven years from individual to working group drafts, a closely-related draft, OAuth 2.0 Discovery (which became RFC 8414) was previously my fastest from individual draft to working group draft: 2.5 months! (The journey to becoming an RFC took 2.5 years.)

The other relative speed demon was Proof-Of-Possession Semantics for JSON Web Tokens (JWTs): 3.5 months from individual draft to working group draft and two years from start to RFC 7800.

What are my takeaways from all these musings about starting things?

Starting things is something to celebrate. It’s a creative process to go from an idea to something concrete and useful. But as my COSE co-chair Ivaylo Petrov wrote, “We would also like to remind you that adoption does not mean a document is finished, only that it is an acceptable starting point.”
Perseverance is essential. Progressing things can take dedication and persistence. My most-referenced specification, JSON Web Token (JWT) – RFC 7519, referenced from 45 RFCs, took 4.5 years.
Focused specifications that do one thing well can progress quickly. Proof-Of-Possession Semantics for JSON Web Tokens (JWTs) – RFC 7800 and JWK Thumbprint URI – RFC 9278 are prime examples. I’m hoping that COSE “typ” (type) Header Parameter will be one of these – a sentiment I shared with co-author Orie Steele.
Finishing things matters. That speaks for itself, but it’s sometimes easier said than done. Finished things get used!

Fully-Specified Algorithms for JOSE and COSE

On August 29, 2023

Orie Steele and I have written a new specification creating algorithm identifiers for JOSE and COSE that fully specify the cryptographic operations to be performed – something we’d promised to do during our presentation to the JOSE working group at IETF 117. The introduction to the specification (quoted below) describes why this matters.

The IANA algorithm registries for JOSE [IANA.JOSE.Algorithms] and COSE [IANA.COSE.Algorithms] contain two kinds of algorithm identifiers:

Fully Specified: Those that fully determine the cryptographic operations to be performed, including any curve, key derivation function (KDF), hash functions, etc. Examples are RS256 and ES256K in both JOSE and COSE and ES256 in JOSE.
Polymorphic: Those requiring information beyond the algorithm identifier to determine the cryptographic operations to be performed. Such additional information could include the actual key value and a curve that it uses. Examples are EdDSA in both JOSE and COSE and ES256 in COSE.

This matters because many protocols negotiate supported operations using only algorithm identifiers. For instance, OAuth Authorization Server Metadata [RFC8414] uses negotiation parameters like these (from an example in the specification):

"token_endpoint_auth_signing_alg_values_supported": ["RS256", "ES256"]

OpenID Connect Discovery [OpenID.Discovery] likewise negotiates supported algorithms using alg and enc values. W3C Web Authentication [WebAuthn] and FIDO Client to Authenticator Protocol (CTAP) [FIDO2] negotiate using COSE alg numbers.

This does not work for polymorphic algorithms. For instance, with EdDSA, you do not know which of the curves Ed25519 and/or Ed448 are supported! This causes real problems in practice.

WebAuthn contains this de-facto algorithm definition to work around this problem:

-8 (EdDSA), where crv is 6 (Ed25519)

This redefines the COSE EdDSA algorithm identifier for the purposes of WebAuthn to restrict it to using the Ed25519 curve – making it non-polymorphic so that algorithm negotiation can succeed, but also effectively eliminating the possibility of using Ed448. Other similar workarounds for polymorphic algorithm identifiers are used in practice.

This specification creates fully-specified algorithm identifiers for all registered polymorphic JOSE and COSE algorithms and their parameters, enabling applications to use only fully-specified algorithm identifiers. It furthermore deprecates the practice of registering polymorphic algorithm identifiers.

The specification is available at:

https://www.ietf.org/archive/id/draft-jones-jose-fully-specified-algorithms-00.html

COSE “typ” (type) Header Parameter Specification Addressing Feedback from IETF 117

On August 4, 2023

In CBOR, IETF, Specifications

Orie Steele and I have updated the COSE “typ” (type) Header Parameter Specification to address feedback received during IETF 117 in San Francisco. Specifically, the spec now requires that the typ header parameter only be used in the protected header parameters. And we described the implications of the unprotected header parameters changing.

The specification is available at:

https://www.ietf.org/archive/id/draft-jones-cose-typ-header-parameter-01.html

We believe that having done this, the spec is now ready for working group adoption.

COSE “typ” (type) Header Parameter Specification

On July 8, 2023

In CBOR, IETF, Specifications

Orie Steele and I have created a specification to add a typ header parameter to COSE – something increasingly widely used in JOSE but currently missing in COSE. The introduction to the spec tells the story:

CBOR Object Signing and Encryption (COSE) [RFC9052] defines header parameters that parallel many of those defined by the JSON Object Signing and Encryption (JOSE) [RFC7515] [RFC7516] specifications. However, one way in which COSE does not provide equivalent functionality to JOSE is that it does not define an equivalent of the typ (type) header parameter, which is used for declaring the type of the entire JOSE data structure. The security benefits of having typ (type) are described in the JSON Web Token Best Current Practices [RFC8725], which recommends its use for “explicit typing” — using typ values to distinguish between different kinds of objects.

This specification adds the equivalent of the JOSE typ (type) header parameter to COSE so that the benefits of explicit typing can be brought to COSE objects. The syntax of the COSE type header parameter value is the same as the existing COSE content type header parameter, allowing both integer CoAP Content-Formats [IANA.CoAP.ContentFormats] values and string Media Type [IANA.MediaTypes] values to be used.

The specification is available at:

https://www.ietf.org/archive/id/draft-jones-cose-typ-header-parameter-00.html

We plan to socialize this specification at IETF 117 in San Francisco later this month.

CBOR Web Token (CWT) Claims in COSE Headers Draft Addressing Working Group Last Call Comments

On June 29, 2023

Tobias Looker and I have published an updated CBOR Web Token (CWT) Claims in COSE Headers draft that addresses the COSE Working Group Last Call (WGLC) comments received. Changes made were:

Added Acknowledgements section.
Addressed WGLC feedback. Specifically…
Added statement about being able to use the header parameter in any COSE object.
Moved statement about verifying that claim values present in both the header and payload are identical from the Security Considerations to the body of the specification.

The specification is available at:

https://www.ietf.org/archive/id/draft-ietf-cose-cwt-claims-in-headers-05.html

Initial Reanimiated JOSE Working Group Specifications Published

On May 8, 2023

In CBOR, Claims, Cryptography, IETF, JSON, Privacy, Specifications

Following a call for adoption by the restarted JSON Object Signing and Encryption (JOSE) Working Group, I’m pleased to report that the three initial working group specifications have been published. They are:

JSON Web Proof, with abstract:

This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) called a JSON Web Proof (JWP). Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a protected header to prevent replay and support binding mechanisms.

JSON Proof Algorithms, with abstract:

The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof (JWP) and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.

JSON Proof Token, with abstract:

JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving representation of claims to be transferred between three parties. The claims in a JPT are encoded as base64url-encoded JSON objects that are used as the payloads of a JSON Web Proof (JWP) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs).

Thanks to Jeremie Miller and David Waite for helping us get there!

JSON Object Signing and Encryption (JOSE) Working Group Reanimated