Vote: a new repository for implementation of the Time-Stamp Protocol (TSP)

[yizha1]

I would like to propose the creation of a new repository for implementation of timestamp (RFC3161) . Here are the details:

Repository name:

timestamp

Description:

This repository contains implementations of the Time-Stamp Protocol (TSP) as specified in RFC3161 and a subset of pkcs7/CMS (Cryptographic Message Syntax) as specified in (RFC5652).

@notaryproject/notaryproject-governance-maintainers @shizhMSFT @patrickzheng200 @JeyJeyGao If you agree with above proposal, please comment LGTM or +1 in this issue.

[FeynmanZhou]

LGTM. Linking https://github.com/notaryproject/notation/issues/838 for context

[shizhMSFT]

+1

[priteshbandi]

+1

[rgnote]

IMO, timestamp is too generic and doesn't indicate that the package deals with TSA timestamping.

Below are couple of alternatives I can think of

1. trusted-timestamp
2. tsa-signature

[shizhMSFT]

I would like to suggest an alternative name of timestamp-go to match other repositories like notation-go.

[shizhMSFT]

@rgnote TSA stands for Time Stamping Authority but this new repository intends to implement a golang client library. Thus, I don't think it is good to include the term tsa in the name.

Another key point is that the repo name is not only just the name of the repository but also the name of the golang module. If we name this repository as timestamp or timestamp-go, it is easy to have the module name timestamp and can be invoked by others as follows.

package main

import "github.com/notaryproject/timestamp-go"

func main() {
    timestamp.Demo()
}

If we name the repo name as trusted-timestamp, it is difficult to name the package name and harder for users to adopt the library as follows (package alias is required)

package main

import timestamp "github.com/notaryproject/trusted-timestamp"

func main() {
    timestamp.Demo()
}

Detailed doc can be found at https://go.dev/wiki/PackagePublishing

[Two-Hearts]

+1 for timestamp-go based on discussions above.

[yizha1]

+1 for timestamp-go

@priteshbandi @FeynmanZhou @toddysm @vaninrao10 @rgnote @gokarnm would you mind voting for the name of the new repo?

[toddysm]

We discussed this in the Notary Project community meeting. Naming is still something that we need to resolve. @NiazFK was going to look at the issue and propose a name before Monday's meeting.

[gokarnm]

IMO timestamp is too generic, a name that includes timestamp protocol or rfc3161 would be preferable.

[rgnote]

If this package is going to be just a client for rfc3161 standard, I agree with Milind and prefer rfc3161 so that we are being super clear with the intent of this package.

[yizha1]

Thanks @gokarnm and @rgnote, as described in the description of this issue

This repository contains implementations of the Time-Stamp Protocol (TSP) as specified in RFC3161 and a subset of pkcs7/CMS (Cryptographic Message Syntax) as specified in (RFC5652).

So, it is not purely rfc3161.

[gokarnm]

@yizha1 could you share some details about what subset pkcs7/CMS is being implemented. Will that subset be directly available to package consumers through APIs?

[yizha1]

@shizhMSFT or @Two-Hearts Could you help to answer the question?

@yizha1 could you share some details about what subset pkcs7/CMS is being implemented. Will that subset be directly available to package consumers through APIs?

[Two-Hearts]

@yizha1 could you share some details about what subset pkcs7/CMS is being implemented. Will that subset be directly available to package consumers through APIs?

@gokarnm In this new library there's also a BER to DER converter and an implementation of signed-data content type of CMS (ref: https://datatracker.ietf.org/doc/html/rfc5652#section-5). In terms of API level, the current design is mainly related to rfc 3161 Timestamping. For the naming of the new repo, since we have libraries like notation-go and notation-core-go, timestamp-go sounds like a good name to align with other libraries in notary project. But we could discuss more on the naming if you think it's too generic. Do you have any suggestions in your mind? If yes, could you list them here? Thanks.

[gokarnm]

@Two-Hearts thanks for the details. If the functionality is scoped to RFC 3161 timestamping, can we name the package as rfc3161-go? timestamp-go can be misinterpreted as anything to do with generic timestamps, other options are authentictime-go , trustedtime-go or similar. Do we plan to add any new functionality in this package not related to RFC 3161 in future? If not, I'd vote for rfc3161-go.

[shizhMSFT]

@Two-Hearts thanks for the details. If the functionality is scoped to RFC 3161 timestamping, can we name the package as rfc3161-go? timestamp-go can be misinterpreted as anything to do with generic timestamps, other options are authentictime-go , trustedtime-go or similar. Do we plan to add any new functionality in this package not related to RFC 3161 in future? If not, I'd vote for rfc3161-go.

@gokarnm What if later there is a new RFC doc, which obsolete RFC3161? For example, a COSE-based timestamping protocol.

[gokarnm]

I don't think RFC3161 and its support by public CAs will obsolete anytime soon. An additional COSE based protocol can come up, I think we'd probably implement it in a different package, so we have well defined core timestamping libraries, that consumers can pick, with their own security reviews and advisories. That way we can keep ASN.1 based implementation separate from COSE based. We can implement appropriate abstractions for trusted timestamp if required in the consuming upstream package, but I think it might be too early for that now.

[shizhMSFT]

SGTM. Let's put rfc3161-go as a candidate name.

[yizha1]

Thanks @shizhMSFT @gokarnm , now we have two candidates.

1. timestamp-go
2. rfc3161-go

Should we start a new round of votes?

@priteshbandi @FeynmanZhou @toddysm @vaninrao10 @gokarnm @shizhMSFT @Two-Hearts

[FeynmanZhou]

timestamp-go sounds much easier for users to understand. Another similar project named timestamp and it seems has been widely adopted in the OSS community: https://github.com/digitorus/timestamp

[whalelines]

I think timestamp-go is more clear than rfc3161-go but I think timestamp-go is too generic. The purpose is not a generic library processing timestamps but an implementation of a client for a timestamp authority (TSA). As such, I would recommend something like tsaclient or tsprotocol.

[priteshbandi]

I second David's suggestion of using tsa-client-go as repo name and tsaclient as package name.

[toddysm]

I agree with @whalelines and @priteshbandi on including client in the name and not using the generic timestamp or cryptic rfc3161. I would suggest tsprotocol-client-go or timestampprotocol-go.

[yizha1]

Now we have more options:

1. timestamp-go (original)
2. rfc3161-go (by Milind)
3. tsaclient (by David)
4. tsprotocol (by David)
5. tsa-client-go (by Pritesh)
6. tsprotocol-client-go (by Toddy)
7. timestampprotocol-go (by Toddy)

I vote for option-5 tsa-client-go

[JeyJeyGao]

timestamp-go follows the convention of RFC 3161 package naming (for example, as seen in https://github.com/digitorus/timestamp), as mentioned by @FeynmanZhou. By using this name, it will be easier to search for due to the well-known related repository.

Meanwhile, tsa-client-go is a clear name that describes the functionality of the repository.

So, I vote for both timestamp-go and tsa-client-go.

[shizhMSFT]

TL;DR I'd vote for timestamp-go and a variant tsprotocol-go of the candidate `tsprotocol.

Here's the reasoning:

1. timestamp-go: clear although it is generic
2. rfc3161-go: accurate but developers need to deep dive into rfc3161
3. tsaclient: tsaclient stands for Time-Stamp Authority client. It seems not correct as it is a time-stamping client (i.e. tsclient-go).
4. tsprotocol: it makes sense as it is a better name than rfc3161 but I think it should be tsprotocol-go.
5. tsa-client-go: since golang does not support hyphen - in the module name, it is not user friendly as it will be used as import tsaclient "github.com/notaryproject/tsa-client-go" (module name alias is always required)
6. tsprotocol-client-go: same reason as above
7. timestampprotocol-go: the name is too long as a module name.

[Two-Hearts]

I vote for timestamp-go and tsaclient-go (given hyphen is not well supported by golang in module names).

[FeynmanZhou]

I vote for timestamp-go.

In the context of Notary Project, existing users and developers might be aware of what's the purpose and usage of this library.

For new users and viewers, a generic but clear project name is good for SEO and easier to memory.

If we feel the project name is too generic, we can add corresponding description alongside the project (repository) name.

[vaninrao10]

repo as "tspclient-go" and package name "tspclient" finalized as per the community meeting on Jan 16th 2024.

[yizha1]

Based on the discussion during the meeting on Jan 16th, 2024, we vote for the name tspclient-go as the repo name, and tspclient as the package name.

[yizha1]

I will start to create the new repo, set up necessary governance and then update the status later.

[yizha1]

Thank you all for voting. Closed this issue as https://github.com/notaryproject/tspclient-go created.