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
