From b72f240c910eb848a2c410eba42f5c507d130895 Mon Sep 17 00:00:00 2001 From: "A.J. Stein" Date: Wed, 7 Aug 2024 13:58:09 -0400 Subject: [PATCH 1/4] More clear explanation of reg pol and CDDL for #277 --- draft-ietf-scitt-architecture.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index 6190a32d..e8cb51ca 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -515,8 +515,9 @@ A Receipt is a Signed Statement, (cose-sign1), with addition Claims in its prote {{fig-signed-statement-cddl}} illustrates a normative CDDL definition (see {{-CDDL}}) for of the protected header and unprotected header of Signed Statements and Receipts. -Everything that is optional in the following CDDL definition can potentially be discovered out of band and Registration Policies are not assured on the presence of these optional fields. -A Registration Policy that requires an optional field to be present MUST reject any Signed Statements or Receipts that are invalid according to the Registration Policy. +This definition specifies the minimally required keys and values as mandatory. Most keys and their respective values for the unprotected header, protected header, and the claims embedded therein are optional for Signed Statements and Receipts. +This design maximizes interoperability with these default requirements for all use cases, while permitting implementers to customize requirements for a specific use case through Registration Policy. +For customizing requirements in Signed Statements and Receipts, a Registration Policy MAY define keys and/or values that are mandatory for that Transparency Service instance. Such a Transparency Service instance MUST reject any Signed Statements or Receipts that are invalid according to its current Registration Policy. ~~~ cddl {::include signed_statement.cddl} From a6a58621d7235eac9140916dbbf852720e89d4d9 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Wed, 7 Aug 2024 15:26:21 -0700 Subject: [PATCH 2/4] markdown formatting --- draft-ietf-scitt-architecture.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index e8cb51ca..d0069850 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -515,7 +515,8 @@ A Receipt is a Signed Statement, (cose-sign1), with addition Claims in its prote {{fig-signed-statement-cddl}} illustrates a normative CDDL definition (see {{-CDDL}}) for of the protected header and unprotected header of Signed Statements and Receipts. -This definition specifies the minimally required keys and values as mandatory. Most keys and their respective values for the unprotected header, protected header, and the claims embedded therein are optional for Signed Statements and Receipts. +This definition specifies the minimally required keys and values as mandatory. +Most keys and their respective values for the unprotected header, protected header, and the claims embedded therein are optional for Signed Statements and Receipts. This design maximizes interoperability with these default requirements for all use cases, while permitting implementers to customize requirements for a specific use case through Registration Policy. For customizing requirements in Signed Statements and Receipts, a Registration Policy MAY define keys and/or values that are mandatory for that Transparency Service instance. Such a Transparency Service instance MUST reject any Signed Statements or Receipts that are invalid according to its current Registration Policy. From a73b5b3944d97b49dd416b24a03364372416aa15 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Wed, 7 Aug 2024 15:27:30 -0700 Subject: [PATCH 3/4] markdown formatting draft-ietf-scitt-architecture.md --- draft-ietf-scitt-architecture.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index d0069850..34555123 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -518,7 +518,8 @@ A Receipt is a Signed Statement, (cose-sign1), with addition Claims in its prote This definition specifies the minimally required keys and values as mandatory. Most keys and their respective values for the unprotected header, protected header, and the claims embedded therein are optional for Signed Statements and Receipts. This design maximizes interoperability with these default requirements for all use cases, while permitting implementers to customize requirements for a specific use case through Registration Policy. -For customizing requirements in Signed Statements and Receipts, a Registration Policy MAY define keys and/or values that are mandatory for that Transparency Service instance. Such a Transparency Service instance MUST reject any Signed Statements or Receipts that are invalid according to its current Registration Policy. +For customizing requirements in Signed Statements and Receipts, a Registration Policy MAY define keys and/or values that are mandatory for that Transparency Service instance. +Such a Transparency Service instance MUST reject any Signed Statements or Receipts that are invalid according to its current Registration Policy. ~~~ cddl {::include signed_statement.cddl} From 123c8fca8a1f244bde8603a68d16b8dd4c51d465 Mon Sep 17 00:00:00 2001 From: "A.J. Stein" Date: Wed, 7 Aug 2024 23:24:48 -0400 Subject: [PATCH 4/4] Accept adjusted phrasing from @SteveLasker's review for #277. Co-authored-by: Steve Lasker --- draft-ietf-scitt-architecture.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md index 34555123..c897fc3c 100644 --- a/draft-ietf-scitt-architecture.md +++ b/draft-ietf-scitt-architecture.md @@ -515,11 +515,10 @@ A Receipt is a Signed Statement, (cose-sign1), with addition Claims in its prote {{fig-signed-statement-cddl}} illustrates a normative CDDL definition (see {{-CDDL}}) for of the protected header and unprotected header of Signed Statements and Receipts. -This definition specifies the minimally required keys and values as mandatory. -Most keys and their respective values for the unprotected header, protected header, and the claims embedded therein are optional for Signed Statements and Receipts. -This design maximizes interoperability with these default requirements for all use cases, while permitting implementers to customize requirements for a specific use case through Registration Policy. -For customizing requirements in Signed Statements and Receipts, a Registration Policy MAY define keys and/or values that are mandatory for that Transparency Service instance. -Such a Transparency Service instance MUST reject any Signed Statements or Receipts that are invalid according to its current Registration Policy. +This definition specifies the minimal mandatory labels. +Implementation-specific Registration Policies may define additional mandatory labels. +A Transparency Service implementation MUST reject registering Signed Statements that do not meet their current Registration Policy requirements. +Each implementation SHOULD provide details for their registration policies through documentation or discovery APIs. ~~~ cddl {::include signed_statement.cddl}