Multiple-Issuer Statements for the Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture

1.1. Motivation

Some Artifacts are accepted only after multiple authorities sign the same Statement. For example, firmware might require signatures from a component manufacturer, a device manufacturer, and an enterprise deployment authority. Each Issuer can use its own key, algorithm, certificate chain, Subject, and other protected metadata.¶

Using separate COSE_Sign1 objects produces independent Signed Statements that are registered separately. COSE_Sign packages Issuer-specific signatures over one common payload in one registered object.¶

1.2. Terminology

This document uses the terms "Artifact", "Issuer", "Receipt", "Registration", "Registration Policy", "Signed Statement", "Statement", "Statement Sequence", "Subject", "Transparency Service", and "Transparent Statement" as defined in Section 3 of [RFC9943]. The terms COSE_Sign, COSE_Sign1, and COSE_Signature, and the terms "protected header", "unprotected header", and "payload", are used as defined in Sections 3 and 4 of [RFC9052].¶

This document uses "joint Statement" for a Signed Statement represented by a tagged COSE_Sign and constrained as specified in this document. Each Issuer signs the common payload and its own protected headers, but does not sign or endorse the other signatures. A Receipt makes the exact signature set accepted at Registration transparent.¶

1.3. Requirements Notation

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

2.1. Relationship to RFC 9943

This document extends the Signed_Statement and Transparent_Statement definitions in Sections 6 and 7 of [RFC9943]. A joint Statement uses tagged COSE_Sign (CBOR tag 98); the existing single-issuer form continues to use tagged COSE_Sign1 (CBOR tag 18). Untagged forms are not permitted.¶

Joint_Sign constrains COSE_Sign; it does not define a new COSE message type. The signing and verification procedures in Section 4.4 of [RFC9052] are unchanged. An implementation of [RFC9943] does not necessarily support joint Statements, even though both forms use the same media type.¶

2.2. Data Model

The following Concise Data Definition Language (CDDL) [RFC8610] defines the single-issuer and joint Statement forms. Appendix A repeats the definitions imported from [RFC9052], [RFC9943], and [RFC9360].¶

Signed_Statement =
  #6.18(COSE_Sign1) /
  Submitted_Joint_Statement

Transparent_Statement =
  #6.18(Single_Issuer_Transparent_Sign1) /
  Joint_Transparent_Statement

Submitted_Joint_Statement =
  #6.98(Joint_Sign)

Registered_Joint_Statement =
  #6.98(Registered_Joint_Sign)

Joint_Transparent_Statement =
  #6.98(Joint_Transparent_Sign)

Single_Issuer_Transparent_Sign1 =
  Single_Issuer_Transparent_Structure .within COSE_Sign1

Single_Issuer_Transparent_Structure = [
  protected: bstr .cbor Protected_Header,
  unprotected: Receipts_Body_Unprotected_Header,
  payload: bstr / nil,
  signature: bstr
]

Joint_Sign =
  Joint_Sign_Structure .within COSE_Sign

Joint_Sign_Structure = [
  body_protected: bstr .size 0,
  body_unprotected:
    Empty_Body_Unprotected_Header /
    Receipts_Body_Unprotected_Header,
  payload: bstr / nil,
  signatures: [2* Joint_Signature]
]

Registered_Joint_Sign =
  Registered_Joint_Structure .within Joint_Sign

Registered_Joint_Structure = [
  body_protected: bstr .size 0,
  body_unprotected: Empty_Body_Unprotected_Header,
  payload: bstr / nil,
  signatures: [2* Registered_Joint_Signature]
]

Joint_Transparent_Sign =
  Joint_Transparent_Structure .within Joint_Sign

Joint_Transparent_Structure = [
  body_protected: bstr .size 0,
  body_unprotected: Receipts_Body_Unprotected_Header,
  payload: bstr / nil,
  signatures: [2* Registered_Joint_Signature]
]

Joint_Signature =
  Joint_Signature_Structure .within COSE_Signature

Joint_Signature_Structure = [
  sign_protected: bstr .cbor Protected_Header,
  sign_unprotected: Signature_Unprotected_Header,
  signature: bstr
]

Registered_Joint_Signature =
  Registered_Joint_Signature_Structure
    .within Joint_Signature

Registered_Joint_Signature_Structure = [
  sign_protected: bstr .cbor Protected_Header,
  sign_unprotected: {},
  signature: bstr
]

Signature_Unprotected_Header = {
  * ((int .ne 394) / tstr) => any
}

Empty_Body_Unprotected_Header = {}

Receipts_Body_Unprotected_Header = {
  &(receipts: 394) => [+ bstr .cbor Receipt]
}

Single_Issuer_Transparent_Sign1 restates, without changing, the requirement in Section 7 of [RFC9943] that a single-issuer Transparent Statement contain only receipts in its unprotected header.¶

2.3. Protected Headers and Issuer Identity

The COSE_Sign body protected header MUST be a zero-length byte string. Consequently, all Issuer- and Subject-specific metadata is carried by the individual signatures.¶

Each COSE_Signature protected header MUST conform to Protected_Header and CWT_Claims from Figure 3 in Section 6.1 of [RFC9943] and contain its own iss and sub Claims in the CBOR Web Token (CWT) Claims header parameter defined in Section 2 of [RFC9597]. Algorithm, key, certificate, Issuer, and Subject metadata is specific to that signature.¶

The content_type parameter describes the common payload. It MUST either be absent from every signature or have the same value in every signature.¶

A joint Statement MUST contain signatures from at least two distinct Issuers. The Registration Policy MUST define how iss values identify Issuers and how aliases are handled. Unequal iss strings alone do not establish distinct Issuer identities.¶

2.4. Registration and Transparency

A Submitted_Joint_Statement may have an empty body unprotected header or one containing only receipts. Signature unprotected headers MAY contain values used for verification or Registration Policy evaluation, but MUST NOT contain receipts.¶

During Registration, the Transparency Service MUST:¶

1. Verify every signature according to Section 4.4 of [RFC9052] using a key authorized for that signature's iss value.¶

2. Apply the required-header and Registration Policy checks from Section 6.3 of [RFC9943] to each signature's protected header.¶

3. Remove all body and signature unprotected values before adding the Statement to a Statement Sequence.¶

The resulting Registered_Joint_Statement has empty body and signature unprotected headers. Adding one or more Receipts to its body unprotected header produces a Joint_Transparent_Statement; its signature unprotected headers remain empty.¶

A Joint_Transparent_Statement may subsequently be submitted to another Transparency Service. Its existing Receipts are removed during Registration.¶

COSE_Sign1 verification and its body iss and sub Claims are unchanged.¶

5.1. Media Types Registry

In the "Media Types" registry, IANA is requested to update the application/scitt-statement+cose registration as follows:¶

• Add this document to the "Published specification" field.¶

• Replace the "Security considerations" field with:¶

  • Section 9.5 of [RFC9943] and Section 3 of this document.¶

• Replace the "Interoperability considerations" field with:¶

  • The mandatory CBOR tags distinguish the COSE_Sign1 and COSE_Sign forms. Implementations that support only the COSE_Sign1 form specified by Sections 6 and 7 of [RFC9943] do not necessarily support the COSE_Sign form specified by this document.¶

• Replace the "Applications that use this media type" field with:¶

  • Used to provide an identifiable and non-repudiable Statement about an Artifact signed by one or more Issuers.¶

5.2. CoAP Content-Formats Registry

In the "CoAP Content-Formats" registry, IANA is requested to list this document as an additional reference for ID 277 (application/scitt-statement+cose).¶

No other IANA actions are requested.¶