This is enough for me to clear my discuss (as I see v7 has been published with all the changes).
Deb p.s. I was also happy to see that the typos in the message (than/then, TCC/TTC) were not in the draft. shew.... On Wed, Aug 13, 2025 at 8:01 AM Henk Birkholz < [email protected]> wrote: > 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]
