Skip to content

Commit

Permalink
Merge pull request #309 from achamayou/allow_protected_x5chain
Browse files Browse the repository at this point in the history
Allow protected x5chain
  • Loading branch information
achamayou authored Oct 15, 2024
2 parents 59c44dc + 72c324c commit 523583c
Showing 1 changed file with 8 additions and 6 deletions.
14 changes: 8 additions & 6 deletions draft-ietf-scitt-architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -419,8 +419,10 @@ During Registration, a Transparency Service MUST, at a minimum, syntactically ch
The Issuer identity MUST be bound to the Signed Statement by including an identifier in the protected header.
If the protected header includes multiple identifiers, all those that are registered by the Transparency Service MUST be checked.

In essence, when using X.509 Signed Statements, the Transparency Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by `x5t` located in the protected header of the COSE_Sign1 Envelope, to one of the root certificates most recently registered as a trust anchor of the Transparency Service.
An `x5chain` with a leaf certificate that corresponds to the `x5t` value MAY be included in the unprotected header.
In essence, when using X.509 Signed Statements, the Transparency Service MUST build and validate a complete certification path from an Issuer's certificate to one of the root certificates most recently registered as a trust anchor by the Transparency Service.

The protected header of the COSE_Sign1 Envelope MUST include either the Issuer's certificate as `x5t` or the chain including the Issuer's certificate as `x5chain`.
If `x5t` is included in the protected header, an `x5chain` with a leaf certificate corresponding to the `x5t` value MAY be included in the unprotected header.

The Transparency Service MUST apply the Registration Policy that was most recently added to the Append-only Log at the time of Registration.

Expand Down Expand Up @@ -502,16 +504,16 @@ Relying Parties can choose which Issuers they trust.

Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree.

At least one identifier representing one credential MUST be included in the protected header of the COSE Envelope, as one of `x5t` or `kid`.
At least one identifier representing one credential MUST be included in the protected header of the COSE Envelope, as one of `x5t`, `x5chain` or `kid`.
Additionally, `x5chain` that corresponds to either `x5t` or `kid` identifying the leaf certificate in the included certification path MAY be included in the unprotected header of the COSE Envelope.

- When using x.509 certificates, support for `x5t` is REQUIRED to implement.
- When using x.509 certificates, support for either `x5t` or `x5chain` in the protected header is REQUIRED to implement.
- Support for `kid` in the protected header and `x5chain` in the unprotected header is OPTIONAL to implement.

When `x5t` is present, `iss` MUST be a string that meets URI requirements defined in {{RFC8392}}.
When `x5t` or `x5chain` is present in the protected header, `iss` MUST be a string that meets URI requirements defined in {{RFC8392}}.
The `iss` value's length MUST be between 1 and 8192 characters in length.

The `kid` header parameter MUST be present when `x5t` is not present.
The `kid` header parameter MUST be present when neither `x5t` nor `x5chain` is present in the protected header.
Key discovery protocols are out-of-scope of this document.

The protected header of a Signed Statement and a Receipt MUST include the `CWT Claims` header parameter as specified in {{Section 2 of CWT_CLAIMS_COSE}}.
Expand Down

0 comments on commit 523583c

Please sign in to comment.