Hi Thomas
Comment below:
On 2025-03-17 17:38, Thomas Fossati
wrote:
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!
Well, your expectations of implementers is higher than mine :)
Of course the implementation example above is highly simplified. But these are the steps that I think an implementer may take to reach this logic.
- They search for all available time stamps.
- By a process and trial and error and reading just what they need to get their implementation to work, they verify the different timestamps against the correct data
- But they miss the fact that TCC timestamp has nothing to do with the signing time. IMO a reasonable and probable mistake by at least a few implementers.
- They pull out the time stamp time and use that as the validation time for the cert chain (which they obviously shouldn't).
- The error goes undetected as the implementer only create
reasonable tests where the timestamp time and signing time is
very close.
A contributing factor for making this error is that they may have validated timestamps before in signatures, and they all represented a time after signature creation.
These types of errors are tricky as there will be no indication of the error in normal testing, until its gets exploited.
In my book this is asking for trouble. But I guess I made my
point :). I leave it to you and the IESG to decide.
Cheers
/Stefan
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
