Design: Where to put timestamps in envelope?

[dlorenc]

Some signing schemes, particularly around artifacts and metadata, rely on timestamp authorities to attest to when a signature was produced. (JARs and Authenticode are examples of this in the wild today).

In this case, the keyID and signature are no longer enough to actually verify that a signature is correct. We have to also check that the signature was produced during the validity window for that key. I think it might make sense to add a field for this somewhere in the envelope.

[trishankatdatadog]

I don't think it needs to be in the signature envelope itself. It could be part of the signed content, but looking forward to objections here.

[dlorenc]

I don't think putting it in the signed content itself would work - what we really need is proof that the signature was created during the validity window of the key, not the signed content.

So we have something like:

Bob signs Payload A with Key A, getting Signature A.
Bob hashes this signature itself and asks the Trusted Timestamp Authority to "timestamp" that.
The Timestamp Authority generates a Payload B containing its own system clock and this payload digest, and signs that.

This way we have independent, non-repudiatable proof that the signature existed before a specific time (typically the key expiry)

[trishankatdatadog]

Yes, this makes sense.

[MarkLodato]

Dan, could you write a brief concrete proposal on how that would work in practice? It sounds like this wouldn't be just a timestamp but rather a single field containing both timestamp and signature. Are there any standards or conventions for how this is conveyed? Do different timestamp authorities use different ones?

[dlorenc]

There's a standard that contains both the timestamp and signature together defined in rfc3161. There are alternates such as https://github.com/cyborch/tsa-json, that also do the same thing.

I think the simplest would be add a new, optional field to the "signature" type to contain this, and treat it as an opaque byte string.

[MarkLodato]

Do you also need a type to indicate how to interpret it?

And either way, this does not affect the signature itself (i.e. the PAE), correct?

[dlorenc]

We don't have a type on the sig field, so I don't think we would need a type here either: https://github.com/secure-systems-lab/signing-spec/blob/master/envelope.proto#L29

I'd be fine either way. And correct - this does not affect the PAE layer.

[MarkLodato]

So basically we'd say that keyid is a hint for both sig and timestamp? That seems OK to start with.

[trishankatdatadog]

So basically we'd say that keyid is a hint for both sig and timestamp? That seems OK to start with.

Mark, this is not clear to me. Could you elaborate?

I'd be fine either way. And correct - this does not affect the PAE layer.

Dan, do you mean sticking the timeserver-signed H(timestamp|signature) alongside the original signature?

[dlorenc]

My idea would basically be this modification, applied here: https://github.com/secure-systems-lab/signing-spec/blob/master/envelope.proto#L26

message Signature {
  // Signature itself. (In JSON, this is encoded as base64.)
  // REQUIRED.
  bytes sig = 1;

  // *Unauthenticated* hint identifying which public key was used.
  // OPTIONAL.
  string keyid = 2;

  // *Separately authenticated* timestamp attesting to when the sig itself occurred.
  // OPTIONAL.
  bytes timestamp = 3;
}

[trishankatdatadog]

My idea would basically be this modification, applied here: https://github.com/secure-systems-lab/signing-spec/blob/master/envelope.proto#L26

Good: this is what I had in mind also. I don't think the keyid could be multiplexed for this, but i might have misunderstood Mark's proposal.

[dlorenc]

Yeah, I'm not sure I understand that part either.

[MarkLodato]

To confirm, this is not blocking #37 because the timestamp does not appear in the PAE, correct?

Sorry for the confusion around keyid. The consumer needs to know how to interpret the timestamp field, namely what format and authority (public key) to use. Is the suggestion that this is tied to the public key used for sig (and hinted by keyid)? For example, if key X signed sig, then the consumer would know that the timestamp field is expected to be in the RFC 3161 format and signed by key Y?

A few other questions:

• Does there need to be a separate "timestamp" field from the "timestamp signature"? Or is the timestamp itself embedded in the blob?
• Is there a use case for more than one timestamp, such as in the case of having more than one authority?