| Internet-Draft | COSE Trust Chains | February 2024 |
| Marco & Bradley | Expires 4 August 2024 | [Page] |
The CBOR Object Signing and Encryption (COSE) [RFC9053] 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 Federation 1.0 [OIDC-FED] 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.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-demarco-cose-header-federation-trust-chain/.¶
Discussion of this document takes place on the CBOR Object Signing and Encryption Working Group mailing list (mailto:cose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Subscribe at https://www.ietf.org/mailman/listinfo/cose/.¶
Source for this draft and an issue tracker can be found at https://github.com/peppelinux/draft-demarco-cose-header-federation-trust-chain.¶
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 August 2024.¶
Copyright (c) 2024 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.¶
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 Federation 1.0 [OIDC-FED] allows the exchange of metadata, roles, trust marks, policies and public keys, in a secure way.¶
OpenID 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 OpenID 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.¶
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.¶
The terms Trust Anchor, Intermediate, Trust Chain, Entity Statement, are defined in [OIDC-FED] and used in this specification.¶
The audience of the document is implementers that require a high level of security for the exchange of metadata, cryptographic keys and policies.¶
This specification defines how a [OIDC-FED] Trust Chain is made available within the COSE headers.¶
The following items are out of scope for the current version of this document:¶
This specification uses the terms "Trust Chain", "Trust Anchor", "Intermediate", "Trust Mark" and "Entity Statement" as defined in [OIDC-FED].¶
The use of OpenID 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].¶
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.¶
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 |
| | | | 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 represents the number of Entity Statements that a Trust Chain contains. The contents of "bstr" are the bytes representing a signed JWT.¶
TBD¶