[Last-Call] Re: Secdir telechat review of draft-ietf-cose-tsa-tst-header-parameter-04

Stefan Santesson <stefan@xxxxxxxxxxx> · Sun, 16 Mar 2025 02:37:51 +0100

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

}

On 2025-03-16 02:22, Stefan Santesson wrote:
Hi, Thomas

I do respect that you had a workgroup process where you decided on 
this functionality (TCC). A process that I did not take part in and 
therefore has limited knowledge about.

So I'm just coming to this as an experienced implementer of electronic 
signatures in general (And by chance also implementer of COSE).

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.

At least I think it should be highlighted and discussed in the 
security considerations section.

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.

With regard to text explaining a use-case where COSE is used to sign 
documents that need to be validated and processed over considerable 
time (Such as a PDF based contract), I can't help you. I'm currently 
not aware of such use-cases. Not saying that they don't exist. But 
this is not a big issue. If you have a concrete example, it would be 
useful to include it.

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.

These are just my opinions, in case they are helpful.

/Stefan

On 2025-03-15 22:01, Thomas Fossati wrote:
Hi Stefan,

Thanks very much for your review.

On Fri, 14 Mar 2025 at 00:25, Stefan Santesson via Datatracker
<noreply@xxxxxxxx> wrote:
Reviewer: Stefan Santesson
Review result: Serious Issues

I have some issues with this document of various severity.

Use cases: Timestamping of signed documents is normally only relevant
for documents that are processed and trusted over a long time. It is
generally not useful for interactive protocol exchanges, where the
signed data includes necessary elements for asserting that the data is
fresh and not a replay.

The nature of the COSE signature is naturally optimaized for use in
protocol exchanges rather than those use cases that needs time-stamp
protection.
Maybe.  This doesn't prevent COSE-signed objects from being utilised in
other contexts.  There's a growing ecosystem of applications that use
COSE to secure their messages - e.g., SCITT and RATS among others -
where signatures can be applied to objects that have long-term archival
requirements (e.g., for auditing).

It would be useful if the Introduction could highlight in what cases
COSE is a natural choice for the types of documents that actually
benefit from timestamping.
Section 1.1 (use cases) was intended to address this matter.
If the current content is insufficient, could you please suggest some
additional text?

Purpose of time stamping: When timestamps are added as part of the
signed object, it has the purpose of asserting the time when the
signature is created. This is essential to meet the security goal to
ensure that the signature was not created with compromised
credentials.
OK, that is one use of timestamping, which is covered by CTT.

The mode "Timestamp then COSE" (TTC) violates this propose by
timestamping just the payload in a pre-signature process.
I wouldn't frame this in terms of "violation".  Instead, TTC implements
a different (legitimate, in my opinion) use pattern than the one covered
by CTT.

I argue that this mode has nothing to do with COSE. This is purely
timestamping of some data before being signed and I struggle to see
that it is appropriate to put such time stamp in a COSE header, as it
has nothing to do with the COSE signature.
Sorry, I don't understand. If the signature also covers the timesatmped
data, it has everything to do with the COSE signature.

It is also of questionable value to add this as a protected header.
The TST is signed by itself and cryptographically bound to the signed
payload. I struggle to see what the benefits are to have it protected
by the COSE signature.
By incorporating it into the header, we provide a way to tightly wrap
all the associated things together.  I see no compelling technical
reason against adopting this approach.  Given that the current design is
the consensus of the COSE WG, I would prefer to leave it as-is.

Security threat with pre signature timestamping (TTC).  I'm worried
that the timestamp created before signing can be misunderstood by
implementers to mark a time when the signature was created. This worry
is increased by the fact that this is the way time stamps provided in
signatures normally work. If this would be the case, it would be
possible to fool such verifier by stealing a signed document with a
timestamped payload before key compromise and resigning it with a
compromised key.

At a minimum, this should be highlighted in the Security
Considerations, which is silent on the topic.
The implementer is presented with two choices, each with well-defined
security properteis.  Certainly, we can always add more prose to explain
the implications of these choices for implementers.  Again, if you think
the current text is lacking, we are happy to incorporate your
suggestions.

Requested change I would recommend to remove the TTC mode timestamp
altogether. If a time stamp is required of the payload data only, this
should not be a COSE header as it has nothing to do with COSE. This
also removes potential security issues cased by implementers not
understanding fully that this timestamp has a completely different
security context than CTT.

It seems to me that the CTT mode does everything that TTC does, just
better.
It does, except when the application flow is such that the signer has
already obtained a timestamp before sending it through the COSE
machinery.

If we drop CTT, this usage pattern will not be addressed, and that would
be a loss of functionality.

cheers!

--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx