Hi Stefan, me again. Sorry for the top posting. Could you please review this PR [1]? [1] https://github.com/ietf-scitt/draft-birkholz-cose-tsa-tst-header-parameter/pull/48 cheers, t On Mon, 17 Mar 2025 at 17:38, Thomas Fossati <thomas.fossati@xxxxxxxxxx> wrote: > > Hi Stefan, > > On Sun, 16 Mar 2025 at 02:22, Stefan Santesson <stefan@xxxxxxxxxxx> wrote: > > I get worried when timestamps gets included in a non-traditional > > fashion. And my experience tells me that there is a real threat here > > that other implementers that comes from a traditional interpretation > > of timestamps included in signatures will miss the fact that this > > timestamp has very different security properties. > > Initially, the document defined only one claim and wasn't clear about > the different semantics. With -01 we moved to two claims precisely to > expose the semantic separation at the syntactic level. IOW we ensured > that the input fed into the processing logic is strongly typed. I don't > want to be dismissive, but an implementation that opts to remove the > typing information does so at its own peril, no? > > > At least I think it should be highlighted and discussed in the > > security considerations section. > > OK, I'll try to add some text to the security considerations. > > > I also struggle to see the value in the intended workflow of TCC. > > > > If the payload contains data to be time-stamped, I argue that this is > > an application specific process that should be handled outside of > > COSE. > > > > If there is a compelling sound reason to integrate this with COSE, > > then I think that this should be explained better in the document. I'm > > sure you have reasons that I'm not aware of. > > > > My argument is that this is not part of the signing process, and is > > not used to validate the signature. Therefore it does not belong > > there. If it is part of the signing process, then CCT does the job in > > a way that is well understood and is compatible with how this is > > handled in all other signature formats. > > Both headers have been reviewed by the designated experts of the "COSE > Header Parameters" registry, who didn't raise any exceptions abuot the > "content-related" semantics of TTC. > TBH, I would have been surprised if they did, since §3 of STD96 states > the following: "[COSE headers] are used for holding information about > content, algorithms, keys, or evaluation hints for the processing of > the layer.”, which seems to cast a pretty wide net in terms of what > headres can cover. > > > Finally. Something that I noted, but forget to include in my review: > > > > If you keep TCC, I would remove the following: > > > > To minimize dependencies, the hash algorithm used for signing the > > COSE message SHOULD be the same as the algorithm used in the > > RFC3161 MessageImprint. > > > > I find this to be an unreasonable burden on implementations of > > applications using COSE. Many applications implementing signing has > > its own process to decide what algorithms to use when signing. > > Changing a preconfigured (or negotiated) hash algorithm just because > > the Timestamp Authority use another hash algorithm seems like an > > unreasonable request. In particular if the Timestamp Authority use a > > weaker hash than I intended to use for signing. > > > > SHOULD seems to strong. A MAY would be more suitable IMO. > > The hash algorithm is chosen by the timestamp requestor, not by the TSA. > And, in most cases, the timestamp requestor and the COSE signer are > expected to be the same entity, i.e., the document holder. Therefore, > I think it makes sense to try and minimise the algorithmic recipe. > The situation where the timestamp requestor and the COSE signer are > different seems like a good exception to the SHOULD rule. > I'll add that to the rationale. > > > These are just my opinions, in case they are helpful. > > Of course, they are very helpful; thanks very much for spending your > time and sharing your experience with us! > > On Sun, 16 Mar 2025 at 02:37, Stefan Santesson <stefan@xxxxxxxxxxx> wrote: > > Just to illustrate what I prercieve as a threat with TCC. Here is a > > pseudo code example of what I fear an implementer may produce if they > > are not careful: > > > > > > function (validateSignature(CoseSignature signature) { > > > > signatureValid = CoseSignatureValidator.validate(signature) > > > > if (signatureValid) { > > signingTime = TimeStampValidator.validate(signature.tccTimestamp, signature.payload) > > > > certificateValid = CertificateValidator.validateCertificateChain(signature.chain, signingTime) > > > > return signatureValid & certificateValid > > } > > > > return false > > > > } > > This is a compelling illustration of the perils associated with casting > away semantics that I mentioned above. > As an implementer, I need to deliberately remove the typing information > carried by the header label and consciously decide to force the input > through some other logic. > > cheers! -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
