TrustedMaterial method naming

[haydentherapper]

Description

Before a major release, I'd like to change the names of the interface methods so that each is not called an Authority. Overuse of Authority is going to lead to confusion since transparency logs are never referred to as authorities in any literature. I'd like to make the following changes:

• TSACertificateAuthorities() -> TimestampingAuthorities() (or TimestampAuthorities(), but the former is the RFC3161 name)
• TlogAuthorities() -> RekorLogs() (Specifying Rekor because this refers only to the Rekor personality and wouldn't work with some generic representation of a log)
• CTlogAuthorities -> CTLogs()
• The TlogAuthority struct -> TransparencyLog

A last change I am debating is changing FulcioCertificateAuthorities to CodesigningCertificateAuthorities. I don't think it's the right thing to do, but wanted to note my thoughts. By using Fulcio, we're stating a requirement for a specific certificate profile. "Codesigning" would allow BYO PKI scenarios. However, there are many assumptions made in the codebase around the structure of the certificate - short lived certificates, certain extensions, identities, etc. I think the better approach is to keep FulcioCertificateAuthorities and later add a separate type for a generic code-signing CA which relaxes many of the constraints. We were thinking something along these lines for Cosign, having a dedicated CLI namespace for BYO PKI.

[steiza]

I'm a big +1 on spelling out TimestampingAuthorities() instead of TSACertificateAuthorities() - that was also on my list to fix.

I think what we were trying to convey with the use of Authority is that this was information coming from the trusted root and not the bundle (e.g. pkg/root/trusted_root.go:TlogAuthority vs pkg/bundle/bundle.go:TlogEntries()).

Authorities might not be the right word in all cases, but should we consider something else to denote that the information is coming from the trusted root and not the untrusted bundle? I guess sigstore_trustroot.proto just uses tlogs and ctlogs.

Maybe something like CTLogsTrusted? I'm not sure I have a good answer here.

[haydentherapper]

To me, the import path trusted_root and struct TrustedRoot should be sufficient, defining that these are trusted entities. Also calling them logs should denote a service rather than an untrusted entity like an entry. Is there an example you're thinking of where there might be confusion between the two?

[steiza]

To me, the import path trusted_root and struct TrustedRoot should be sufficient, defining that these are trusted entities.

Fair enough!

My only remaining hesitation is that in the bundle protobuf we call it tlogs instead of RekorLogs, but RekorLogs is definitely less confusing that tlogs and ctlogs.