]> independent

demarcog83@gmail.com

Security CBOR Object Signing and Encryption OpenID Connect Federation COSE The CBOR Object Signing and Encryption (COSE) message structure uses message headers to give references to elements that are needed for the security and verifiability of the message, such as algorithms and keys. OpenID Connect Federation 1.0 is a general purpose attestation mechanism to obtain verifiable metadata and cryptographic keys. This document defines a new COSE header parameter to identify and transport an OpenID Federation 1.0 Trust Chain. About This Document Status information for this document may be found at . Discussion of this document takes place on the CBOR Object Signing and Encryption Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Internet Standards and defines how to transport symmetric keys in the COSE headers, and are extended by to transport X.509 certificates for the requirements of identification and cryptographic key attestation of a third party. There are some cases where obtaining proof of a third party's identity through key attestation and cryptographic signature verification is not enough, cases where the solution requirements include attestation of metadata, proofs of compliance and policies. In these cases, it would be necessary to extend the X.509 certificates with policies, metadata and other information required by the interoperability schemes or by a trust framework. OpenID Connect Federation 1.0 allows the exchange of metadata, roles, trust marks, policies and public keys, in a secure way. OIDC Federation 1.0 allows the construction of a trust infrastructure in which even X.509 certificates can be published within the Entity Statements that make up the federation Trust Chain. This flexibility allows an infrastructure based on OIDC Federation 1.0 to guarantee the security of the solutions, the historical verifiability of the signatures, and the revocation mechanisms without the requirement to implement CRL or OCSP technologies, where X.509 requires it.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology The terms Trust Anchor, Intermediate, Trust Chain, Entity Statement, are defined in and used in this specification.

Audience Target audience/Usage The audience of the document is implementers that require a high level of security for the exchange of metadata, cryptographic keys and policies.

Scope This specification defines how a Trust Chain is made available within the COSE headers.

Out of Scope The following items are out of scope for the current version of this document:

• X.509 publication over a Infrastructure, this can be achieved using x5c or x5u as defind in .
• Metadata schemas, OIDC Federation allows the definition of custom metadata schemas even for entities not belonging to OAuth2 and OpenID ecosystems.

Terminology This specification uses the terms "Trust Chain", "Trust Anchor", "Intermediate", "Trust Mark" and "Entity Statement" as defined in .

The Scope of Trust Chain COSE Header Parameter The use of OIDC Federation Trust Chain enables a trust infrastructure with full suites of Trust Anchors, Intermediates, status and revocation checking, Trust Marks and metadata policies that have been defined in . The Concise Binary Object Representation (CBOR) key structures and Header Parameters for Carrying and Referencing X.509 Certificates that have been defined in COSE currently do not support all the properties made available in .

Requirements If the application cannot establish trust to the cryptographic keys or metadata made available and verified within the Trust Chain, the public key and the metadata MUST NOT be used. When Trust Chain parameter is used, the parameter KID defined in MUST be used. KID allows an efficient matching to the key to be used for signature verification.

Trust Chain COSE Header Parameter The header parameter defined is trustchain, described below: trustchain: This header parameter contains an ordered array of strings, representing federation Entity Statements encoded as signed Json Web Tokens . How the Entity Statements are ordered is defined in . The trust mechanism used to process any Entity Statements is defined in . The header parameter can be used in the following locations: COSE_Signature and COSE_Sign1 objects: In these objects, the parameters identify the Trust Chain to be used for obtaining the key needed for validating the signature, any needed metadata for interoperability purpose, any metadata policy and any required Trust Marks for administrative and technical compliances. The labels assigned to the header parameter can be found in Table 1. Below is an equivalent Concise Data Definition Language (CDDL) description (see ) of the text above. COSE_TRUSTCHAIN = [ N * jws :bstr ] The variable N represent the number of Entity Statements that a Trust Chain can contain. The contents of "bstr" are the bytes representing a JWS.

IANA Considerations TBD

Normative References A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. n.d. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments TBD