[RFC] Rehome io.intoto namespace under dev.sigstore?

[woodruffw]

This repository currently contains a copy of the in-toto envelope message definitions, tweaked slightly to influence code generation:

https://github.com/sigstore/protobuf-specs/blob/85dce20afb5e8ad9e170328abb7ff2e61b758958/protos/envelope.proto

These message definitions currently declare their package namespace as io.intoto, which is consistent with the original definition in the DSSE spec repo:

https://github.com/secure-systems-lab/dsse/blob/master/envelope.proto

Based on the conversation in #86, IMO it may make sense to change the package namespace to dev.sigstore.intoto or similar here:

1. We've slightly modified the message definition (adding metadata to reflect different codegen namespaces)
2. We've slightly modified the definition's documentation (clarifying it in a few places)
3. Our copy is (nominally) independent in the sense that we're locked into it, and upstream changes won't be reflected by us without additional compatibility work.

On the other hand:

1. I'm not sure this actually matters: aside from code generation, does anything really care about the package namespace definition?
2. Maybe it's unidiomatic to change the package namespace like this? I'm not familiar enough with the Protobuf ecosystem to know.

CC @znewman01 @bobcallaway @haydentherapper for opinions here.

[haydentherapper]

If we're modifying the definition, I agree we should move it to the Sigstore package namespace. Don't feel incredibly strongly about this though, and to your second point, I'm not sure if there's a precedent we should be following.

[kommendorkapten]

The changes we have made are only for code generation (i.e what package name the generated code should be in)? All other changes made it upstream I believe.

I don't consider renaming the protiobuf package that important, Actually I think it can potentially benefit from staying in io.intoto to indicate that we are sourcing from another package?

To keep the definition in sync, I wonder if we could do some trick with dependabot to get notified when a new release of SSL exists?