I’m pleased to report that the IETF COSE Working Group has adopted the specification “COSE and JOSE Registrations for WebAuthn Algorithms”. An abstract of what it does is:
This specification defines how to use several algorithms with COSE [RFC8152] that are used by implementations of the W3C Web Authentication (WebAuthn) [WebAuthn] and FIDO2 Client to Authenticator Protocol (CTAP) [CTAP] specifications. These algorithms are to be registered in the IANA “COSE Algorithms” registry [IANA.COSE.Algorithms] and also in the IANA “JSON Web Signature and Encryption Algorithms” registry [IANA.JOSE.Algorithms], when not already registered there.
I have written draft-jones-cose-additional-algorithms, which combines these starting points into a single draft, which registers these algorithms in the IANA COSE registries. When not already registered, this draft also registers these algorithms for use with JOSE in the IANA JOSE registries. I believe that this draft is ready for working group adoption to satisfy this deliverable.
The Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been updated to address issues identified by Roman Danyliw while writing his shepherd review. Thanks to Samuel Erdtman for fixing an incorrect example.
Key ID confirmation method considerations suggested by Jim Schaad have been added to the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification. Per discussions in the working group meeting in Bangkok, it’s now time for the shepherd review.
The Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been updated to addresses a few additional Working Group Last Call (WGLC) comments. All of the (few) changes were about improving the clarity of the exposition. I believe that this completes addressing the WGLC comments.
Thanks to Roman Danyliw for helping to categorize the remaining comments that needed to be addressed.
The “CBOR Web Token (CWT)” specification is now RFC 8392 – an IETF standard. The abstract for the specification is:
CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.
The WebAuthn working group has published the “COSE Algorithms for Web Authentication (WebAuthn)” specification, which registers COSE algorithm identifiers for RSASSA-PKCS1-v1_5 signature algorithms with SHA-2 and SHA-1 hash algorithms. RSASSA-PKCS1-v1_5 with SHA-256 is used by several kinds of authenticators. RSASSA-PKCS1-v1_5 with SHA-1, while deprecated, is used by some Trusted Platform Modules (TPMs). See https://www.iana.org/assignments/cose/cose.xhtml#algorithms for the actual IANA registrations.
Thanks to John Fontana, Jeff Hodges, Tony Nadalin, Jim Schaad, Göran Selander, Wendy Seltzer, Sean Turner, and Samuel Weiler for their roles in registering these algorithm identifiers.
One more clarification to the CBOR Web Token (CWT) specification has been made to address a comment by IESG member Adam Roach. This version is being sent to the RFC Editor in preparation for its publication as an RFC. The change was:
Added section references when the terms “NumericDate” and “StringOrURI” are used, as suggested by Adam Roach.
Special thanks to Security Area Director Kathleen Moriarty for helping get this across the finish line!
Cleaned up the descriptions of the numeric ranges of claim keys being registered in the registration template for the “CBOR Web Token (CWT) Claims” registry, as suggested by Adam Roach.
Clarified the relationships between the JWT and CWT “NumericDate” and “StringOrURI” terms, as suggested by Adam Roach.
Eliminated unnecessary uses of the word “type”, as suggested by Adam Roach.
Added the text “IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list” from RFC 7519, as suggested by Amanda Baber of IANA, which is also intended to address Alexey Melnikov’s comment.
Removed a superfluous comma, as suggested by Warren Kumari.
A new CBOR Web Token (CWT) draft has been published that applies a correction to an example. The full list of changes is:
Corrected the “iv” value in the signed and encrypted CWT example.
Mention CoAP in the application/cwt media type registration.
Changed references of the form “Section 4.1.1 of JWT <xref target="RFC7519"/>” to “Section 4.1.1 of <xref target="RFC7519"/>” so that rfcmarkup will generate correct external section reference links.
Thanks to Samuel Erdtman for validating all the examples once more and finding the issue with the signed and encrypted example. Thanks to Benjamin Kaduk for pointing out additional improvements that could be applied from the second WGLC comments.
A new CBOR Web Token (CWT) draft has been published that addresses comments received during the second working group last call. Thanks to Hannes Tschofenig, Esko Dijk, Ludwig Seitz, Carsten Bormann, and Benjamin Kaduk for their feedback. All changes made were clarifications or formatting improvements.
Draft -01 of the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification updates the examples to use CBOR diagnostic notation, thanks to Ludwig Seitz. A table summarizing the “cnf” names, keys, and value types was added, thanks to Samuel Erdtman. Finally, some of Jim Schaad’s feedback on -00 was addressed (with more to be addressed by the opening of IETF 100 in Singapore).
A new CBOR Web Token (CWT) draft has been published that adds CBOR_Key values and Key IDs to examples. Thanks to Samuel Erdtman for working on the examples, as always. Thanks to Giridhar Mandyam for validating the examples!
I believe that it’s time to request publication, as there remain no known issues with the specification.
The initial working group draft of the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been posted. It contains the same normative content as draft-jones-ace-cwt-proof-of-possession-01. The abstract of the specification is:
This specification describes how to declare in a CBOR Web Token (CWT) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. This specification provides equivalent functionality to “Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)” (RFC 7800), but using CBOR and CWTs rather than JSON and JWTs.
I look forward to working with my co-authors and the working group to hopefully complete this quickly!
The “Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages” specification is now RFC 8230 – an IETF standard. The abstract for the specification is:
The CBOR Object Signing and Encryption (COSE) specification defines cryptographic message encodings using Concise Binary Object Representation (CBOR). This specification defines algorithm encodings and representations enabling RSA algorithms to be used for COSE messages. Encodings are specified for the use of RSA Probabilistic Signature Scheme (RSASSA-PSS) signatures, RSA Encryption Scheme – Optimal Asymmetric Encryption Padding (RSAES-OAEP) encryption, and RSA keys.
Some of these values are already being used by the sixth working draft of the W3C Web Authentication specification. In addition, the WebAuthn specification defines algorithm values for RSASSA-PKCS1-v1_5 signatures, which are used by TPMs, among other applications. The RSASSA-PKCS1-v1_5 signature algorithm values should also be registered shortly.
Thanks to Kathleen Moriarty for her Area Director sponsorship of the specification!
A new CBOR Web Token (CWT) draft has been published that updates the diagnostic notation for embedded objects in the examples. Thanks to Samuel Erdtman for making these updates. Thanks to Carsten Bormann for reviewing the examples!
This addresses all known issues with the specification. I believe that it is now time to request publication.