Verify conformance with specifications about timestamp-authority

[haydentherapper]

https://datatracker.ietf.org/doc/html/rfc3628#section-7.2 and https://datatracker.ietf.org/doc/html/rfc3628#section-7.4 are the main sections on policy that I'm not sure we can conform to in a cloud environment. MS or Apple might have a better TSA policy that's more up to date with modern deployment.

[haydentherapper]

A few more links I had recorded at some point:

• https://datatracker.ietf.org/doc/html/rfc5816 - Updates for certificate inclusion to 3161
• Use of RFC 3628's policy ID - https://cs.github.com/?scopeName=All+repos&scope=&q=%220.4.0.19422.1.1%22
• Policy requirements as per EU - https://www.etsi.org/deliver/etsi_en/319400_319499/319422/01.01.00_30/en_319422v010100v.pdf
• More policy requirements - https://www.etsi.org/deliver/etsi_en/319400_319499/319421/01.01.01_60/en_319421v010101p.pdf

[haydentherapper]

Yea, if the rest of RFC 3628 is relevant, we could just copy it into a document and update the section on key storage.

[haydentherapper]

This GitHub repo would be best! Architecture docs might be a good final home, but we haven't checked anything into that yet. docs is just for the website currently.

[malancas]

Github won't let me assign myself to the issue yet but I can start taking a look at this.

[malancas]

After reading through https://datatracker.ietf.org/doc/html/rfc3628 and specifically sections 7.2 and 7.4 noted above, I don't believe we can conform to in a cloud environment. These sections discuss the generation of keys in a physically secure location and securing/limiting the access to the facilities that host the keys and TSA hardware, see section 7.4.4.

Apple has a timestamp sub-CA certification practice statement. Section 3.2.1 covers private key storage and specifies that the private key must be stored in a HSM validated at a minimum level of FIPS 140-2 Level 3. GCP offers a cloud-based HSM service that fulfills the same FIPS requirement.

However the statement also discusses physical security in section 5.5. This section includes defining "security perimeters with appropriate physical barriers to entry around the business premises and Timestamp Sub-CA facilities". Because we are using a cloud environment, this is not something we can enforce ourselves.

[malancas]

I'll look into whether MS has a more modern one as well but we may want to consider writing our own.

[malancas]

@haydentherapper reading through https://www.etsi.org/deliver/etsi_en/319400_319499/319421/01.01.01_60/en_319421v010101p.pdf, it looks like the private key generation section states the generation must be carried out in a secure environment, similar to RFC 3161.

What do you think of creating a policy that just updates the "private key generation" and "physical and environmental security" sections of either RFC 3161 or RFC 5816 to work with cloud environment?

I'll keep looking through more policies in the meantime.

[malancas]

Where do we want to store the finalized specifications doc? In this repository as a markdown file? I noticed the https://github.com/sigstore/architecture-docs and https://github.com/sigstore/docs repositories as well.

[malancas]

Update OID here: https://github.com/sigstore/timestamp-authority/blob/main/pkg/api/timestamp.go#L40