COSE Header Parameter for Carrying OpenID Federation 1.0 Trust Chains

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 4 March 2024.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The Internet Standards [RFC8152] and [RFC9052] defines how to transport symmetric keys in the COSE headers, and are extended by [RFC9360] 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 [OIDC-FED] allows the exchange of metadata, roles, trust marks, policies and public keys, in a secure way.¶

OIDC Federation 1.0 [OIDC-FED] 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.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Terminology

The terms Trust Anchor, Intermediate, Trust Chain, Entity Statement, are defined in [OIDC-FED] and used in this specification.¶

4. 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.¶

5. Scope

This specification defines how a [OIDC-FED] Trust Chain is made available within the COSE headers.¶

6. Terminology

This specification uses the terms "Trust Chain", "Trust Anchor", "Intermediate", "Trust Mark" and "Entity Statement" as defined in [OIDC-FED].¶

7. 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 [OIDC-FED].¶

The Concise Binary Object Representation (CBOR) key structures [RFC8949] and Header Parameters for Carrying and Referencing X.509 Certificates [RFC9360] that have been defined in COSE currently do not support all the properties made available in [OIDC-FED].¶

8. 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 [RFC9052] MUST be used. KID allows an efficient matching to the key to be used for signature verification.¶

9. 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 [RFC7519]. How the Entity Statements are ordered is defined in [OIDC-FED].¶

The trust mechanism used to process any Entity Statements is defined in [OIDC-FED].¶

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.¶

 +=============+=======+=================+=====================+
 | Name        | Label | Value Type      | Description         |
 +=============+=======+=================+=====================+
 | trustchain  | 27    | COSE_TRUSTCHAIN | OpenID Connect      |
 |             |       |                 | Federation 1.0      |
 |             |       |                 | Trust Chain         |
 +-------------+-------+-----------------+---------------------+

           Table 1: TRUST CHAIN COSE Header Parameters

Below is an equivalent Concise Data Definition Language (CDDL) description (see [RFC8610]) 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.¶

10. IANA Considerations

TBD¶

Acknowledgments

TBD¶

Author's Address