On Thu, Jan 30, 2025 at 09:25:39AM +0100, Linus Nordberg wrote:
Rasmus Dahlberg rgdd@glasklarteknik.se wrote Wed, 29 Jan 2025 19:35:59 +0100:
## What I would like for us to move away from "pet names" for stable Sigsum services, including log instances. Or if we decide to keep them, choose them in a way that provides some context.
What context do you want to provide?
As much as seem practically possible. Three ideas were outlined in the "why" section ("sigsum", type of service, protocol version). A fourth would be one that indicates when in time the service was deployed.
## Why Pet names without any context requires everybody to memorise a token and connect it to a Sigsum service. While this might be ok for those who work
The alternatives I see without pet names are:
- We talk about "foo's sigsum log"
- We talk about a Sigsum log with <pub key / key hash>
The first option doesn't work well if foo operates >1 log or witness, unless they have their own unique contexts of course. Hence my question above (and further down below) about what context you want to provide.
The second option doesn't work well in conversation, and is the main reason why we have names like jellyfish, seasalp, etc., for our logs.
I should perhaps have clarified that when I say "pet names" I mean names which have no meaning themselves. By that definition a name like "sigsum/log/stable/2024/seasalp" would *not* be a pet name even if it contains one.
with them a lot, I find it a bit presumptuous to ask everyone else to do that. Compare Debian release names.
## How One kind of context that would have particular value for all but the few of us who work with Sigsum daily would be a connection to Sigsum. Prefixing names with "sigsum-" would be one way of doing this.
Another type of context could be provided by including in the name the type of service provided. "log" and "witness", "wit" or "wtn" come to mind. It could be argued that the cleverly chosen families of animals currently used provide such context but I don't think that is helpful.
FWIW I don't view "seasalp" and "jellyfish" as clever sigsum aliases. It might have been better if seasalp had actually had this base URL:
https://sigsum.glasklar.is/seasalp/
But I still think it is helpful that "seasalp" is included. It's a way to refer to a particular Sigsum log that is operated by Glasklar.
Thinking of the name as a combination of a base URL and a pet name adds context, and maybe that is enough for logs. As for witnesses, they do have a URL but in the case of a witness using a bastion host, not one that gives any context.
Rallying around signed-note, a witness does have a name:
And it's recommended it is a schema-less URL (need not be reachable). So I would expect that a foo witness has a name that contains "foo.tld", possibly with other context before and/or after.
When you're thinking about naming and context. Also think about where these names will appear. The most obvious place is in trust policies; and the second most obvious place I can think of is where the self-selected name is discovered from the operator (e.g., about page).
This discussion might need more well defined terminology, especially what we mean when we say "name". I will make an attempt at that below.
Yet another, useful in cases where we know that there is an upcoming incompatible protocol change, would be to include a version number.
Related:
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/archive/202... https://git.glasklar.is/sigsum/project/documentation/-/blob/main/proposals/2...
I still think it makes sense to not *require* that a version string is included in the address of a service. That doesn't mean that for certain deployments it can be useful to include a version string in the *name*
Agreed.
of a service. But again, what is a name?
## Random, minor Non stable services, like current test log "jellyfish", are presumably used by fewer and more involved people and can keep being named like pets.
## Going forward Happy to turn this into a proposal if there's any support for this position.
If you have a suggestion for a context that's helpful I think that would be much better than pet names. But I'm not sure what that context is.
Maybe context is not a good word for describing what I think is needed.
I think that Sigsum services need at least the following attributes, each of them unique to an instance:
- an identity, typically a hash of a signing key
- an internet address, typically a URL
- a name useful for humans
The identity and address are used by machines, while the name is used by humans.
In order to be unique among all Sigsum services a name should probably contain
- name of operator ("Glasklar", "Debian")
- service type ("log", "witness")
- uniqueifier ("stable", "seasalp", "001")
Sounds reasonable. I'd prefer if the uniqueifier is easy for humans.
-Rasmus
If we want to be unique outside of the scope of Sigsum, we would need to include that somewhere. Could be part of service type, so "log" would become "sigsum log".