search

sigstore / timestamp-authority

RFC3161 Timestamp Authority
Apache License 2.0
63 stars 38 forks source link

Verify conformance with specifications #2

Closed haydentherapper closed 1 year ago

haydentherapper commented 2 years ago

An alternative policy for Apple's TSA: https://images.apple.com/certificateauthority/pdf/Apple_Timestamp_CPS_v2.0.pdf

We may need to create our own TSA policy with its own OID if we can't conform to 3628

malancas commented 2 years ago

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

haydentherapper commented 2 years ago

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.

malancas commented 2 years ago

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 commented 2 years ago

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

haydentherapper commented 2 years ago

A few more links I had recorded at some point:

malancas commented 2 years ago

@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.

haydentherapper commented 2 years ago

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

malancas commented 2 years ago

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.

haydentherapper commented 2 years ago

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 commented 1 year ago

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