[Discussion] Secure timestamping in regards to short-lived keys & certificates.

[mikhailswift]

Description: As discussed during the May 12 meeting, I'm currently working on using short lived keys to sign artifacts and now need to handle making sure the signature was generated during the key's validity window. RFC3161 exists as a way to standardize this process but doesn't define any specifications for transport. I'm appealing to the tag-security group as a whole for individuals who have experience in this field to perhaps form a small meeting to discuss the issue.

Impact: This will impact my work on the in-toto project and how we approach supply chain security in that context.

Scope: I do not believe this to be a significant scope. A few people chimed in during the meeting who seemed experienced in this field. A few references were provided: sigstore/rekor#293 and TUF's handling of timestamps were of particular note.

@colek42 @trishankatdatadog Marina Moore also expressed interest on being tagged on this, but I am unable to find a github account for them.

[trishankatdatadog]

Cc @mnm678

[trishankatdatadog]

Cc @dlorenc @SantiagoTorres

[lumjjb]

@lukehinds tagging in case this is relevant for fulcio

[dlorenc]

Hey! Yes, we've taken this approach in sigstore. Let me know how I can help.

[lukehinds]

I'm currently working on using short lived keys to sign artifacts and now need to handle making sure the signature was generated during the key's validity window

This is exactly what sigstore does (with in-toto integration underway). Any reason to not just use / contribute to sigstore , are we missing something feature wise? Would be open to hearing if so.

[mnm678]

For shortlived keys like you describe, I agree that you should look into sigstore's approach.

More generally for ensuring timeliness of in-toto metadata, @trishankatdatadog has also had success using TUF as a transport mechanism for the in-toto metadata, which provides timeliness through TUF's timestamp and snapshot roles.

[colek42]

For our use case, we need to tie attestations to specific containers (file systems) and hardware (TPM AK) with an out-of-band process. SPIFFE/SPIRE framework provides this for us. I think this PR on Rekor will definitely be part of the solution.

in-toto additionally gives us the ability to make attestations with flat files. This is great when we need to verify software in air-gapped environments. From my understanding use of sigstore for this data would add an additional dependency to the toolchain at the time of verification.

one of our initial thoughts is to sign the link.metadata files with a timestamp server and use this spec:
https://theupdateframework.github.io/specification/latest/#file-formats-timestamp

@SantiagoTorres @anvega

[trishankatdatadog]

So I hate to be that guy, but I think a quick meeting may be in order to try to understand the problem better and see when and where we may be able to apply each tool? 🙂 One person representing each tool mentioned here should do.

[dlorenc]

I just opened tektoncd/chains#87 over in Tekton to track other ideas on how to make some of this stuff easier directly in Tekton itself.

[dlorenc]

Found this too: https://youtu.be/4lFbdkB62QI :)

[lukehinds]

@anvega should be here too.

[anvega]

Thanks, @colek42 and @lukehinds.

How is Tuesday 8 or 9 am US pacific time work for everyone to meet and discuss?

Tagging @azdagron and @evan2645 here whose perspective will be relevant and beneficial to the conversation.

[evan2645]

Tagging @azdagron and @evan2645 here whose perspective will be relevant and beneficial to the conversation.

👋

This week will be tough for me. I'd love to join a call if it's next week some time (Monday? Wednesday?), else I can review a recording or something to catch up and leave any relevant thoughts on this thread?

[colek42]

Next week will be better for Mikhail and myself as well. I am good next monday pretty much all day.

…

-Cole

On Mon, May 17, 2021 at 11:34 Evan Gilman ***@***.***> wrote: Tagging @azdagron <https://github.com/azdagron> and @evan2645 <https://github.com/evan2645> here whose perspective will be relevant and beneficial to the conversation. 👋 This week will be tough for me. I'd love to join a call if it's next week some time (Monday? Wednesday?), else I can review a recording or something to catch up and leave any relevant thoughts on this thread? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#625 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSTWVPTBC2UNXLZG2QMUULTOFASNANCNFSM443KQT2A> .

[trishankatdatadog]

Next Monday WFM too

[azdagron]

Happy to join a call next monday.

[lumjjb]

@mikhailswift @colek42 if you'd like to use the CNCF Security Tag zoom, that is always open, just note that the call is always recorded.

[mnm678]

Next Monday works for me as well.

[colek42]

I have a meeting set for Monday 24 May at 11:00AM-12:00AM CST using Zoom. Send me a message on Slack with your email if you would like and invite. Otherwise meeting details will be in TAG-Security Slack Channel for self-service

[anvega]

Thanks, @colek42. I've forwarded the invitation to everyone who has commented on this issue.

[ultrasaurus]

Hi all -- Glad this discussion is moving forward! I'd like to assign this issue to someone. Who wants to volunteer to summarize whatever is learned from this in issue and either close it or turn it into a proposal/suggestion if it seems like some artifact in the repo or other action would be useful? @colek42 @mikhailswift ?

[colek42]

Mikhail and I will take care of it.

…

On Wed, May 19, 2021 at 14:47 Sarah Allen ***@***.***> wrote: Hi all -- Glad this discussion is moving forward! I'd like to assign this issue to someone. Who wants to volunteer to summarize whatever is learned from this in issue and either close it or turn it into a proposal/suggestion if it seems like some artifact in the repo or other action would be useful? @colek42 <https://github.com/colek42> @mikhailswift <https://github.com/mikhailswift> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#625 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSTWVMOZ2GKM477BG6IDKTTOQIUTANCNFSM443KQT2A> .

[danpop-chainguard]

@anvega -- i would like to join this call if at all possible.

[lumjjb]

@danpopSD look in the #tag-security slack for the goodies :)

[stale]

This issue has been automatically marked as inactive because it has not had recent activity.

[TheFoxAtWork]

Checking in here - is there any outstanding action/project for the STAG or is this being handled out-of-band?

[trishankatdatadog]

Emily, I think the recommendations were:

1. TUF is not designed to do RFC-3161-style timestamping, despite the closely named timestamp role/metadata.
2. Best to use a RFC-3161 timestamping authority (TSA) like the one in SigStore.

[TheFoxAtWork]

Closing issue with the above recommendation for resolution from @trishankatdatadog