Hi Deb, In your DISCUSS, you have highlighted four issues. At least three of these have been addressed via https://github.com/ietf-scitt/draft-birkholz-cose-tsa-tst-header-parameter/pull/61.
Correspondingly, I-D.ietf-cose-tsa-tst-header-parameter-07 reflects these changes. We hope that issues 2, 3 and 4 in your DISCUSS are addressed. This leaves issue 1: "Names of modes". The authors discussed this feedback extensively — and I mean _extensively_. Unfortunately, the author's opinion holds (where "signing" means "COSE"), as follows: "COSE Than Timestamp" (CTT) and "Timestamp Than COSE" (TCC) are as simple and intuitive as they get. To further address the concerns raised, we have created a new subsection of the Security Considerations: §5.1 "Avoiding Semantic Confusion", which is referenced from the very first paragraph of §1.1 "Use Cases". This presents text suggested by Stefan for further clarification. For convenience, we quote this text here:
Implementers MUST clearly differentiate between RFC 3161 TSA: timestamps proving the existence of payload data at an earlier point in time (TTC), and timestamps that explicitly provide evidence of the existence of the cryptographic signature (CTT). Failure to clearly Failure to distinguish between these timestamp semantics can result in vulnerabilities, such as incorrectly accepting signatures created after key revocation based on older payload-only timestamps. Validators must not interpret protected-header payload timestamps as proof of signature creation time, and should rely exclusively on RFC 3161 TSA timestamps explicitly cover signature data. determining signature validity timing
We expect readers to read the specification, and we believe that we have introduced a clear distinction between modes and the sequence of content. We have also introduced a prioritization of modes of use. Any further attempt to address your comment resulted in less readable text or redundant reminders in the English text about which mode applies in which context. This does not seem to be a naming problem, but a presentation problem. We sincerely hope that the compromise in version -07 is sufficient to address your concerns by improving the presentation. For the I-D.ietf-cose-tsa-tst-header-parameter editors, Henk On 05.08.25 21:19, Deb Cooley via Datatracker wrote:
Deb Cooley has entered the following ballot position for draft-ietf-cose-tsa-tst-header-parameter-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-tsa-tst-header-parameter/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to Stefan Santesson for the repeated secdir reviews. These reviews have driven change to create a better specification. The authors are lucky to have drawn a reviewer that is well versed in the subject of timestamps. I'm not sure it is possible to completely eliminate the issue of a choosing the wrong method, but I hope recent changes have made it harder for the developer to make that mistake. I will make a few comments which I hope will make it a tiny bit harder. Names of modes: Stefan points out that the two mode names are similar, perhaps too similar. Instead of choosing the mode names by the order of operation, maybe mode names that describe the operation. Perhaps 'certificate timestamps' and 'unsigned statement timestamps', recognizing that these don't create nice acronyms, and that it is a pretty pervasive change to the draft. Section 1.1: Add a sentence to the first para that this specification outlines the original mode and a new mode, where the security characteristics are different so care needs to be taken to choose the appropriate mode. Section 1.1, para 2&3: Please consider stating that this use case is the primary, or original use case that most implementations will use. Something like 'The original use case....' and then 'This primary usage scenario motivates....' Section 1.1, para 4&5: Please consider stating that this is a new use case for very specific purposes. Something like 'The new use case...' and then 'This new usage scenario....' ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1.1, para 4: A small clarification, if the TST is acquired before the statement is signed, then the relying party knows that the statement was signed by the issuer 'not before' the times specified by the TSA. This is an early bound (vice a no later bound in the first case).
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
