Hayden B

> Wasn't there also something about using a different style of logid for rekor? I can't seem to remember details, but there was no guarantee it was going to continue...

I just reread what I wrote, and it's kinda messy. so tldr * ed25519-signed checkpoint key ID: `SHA-256(key name || 0x0A || 0x01 || 32-byte Ed25519 public key)[:4]` * ecdsa-signed...

> Stop assuming that everything is ECDSA Correct, particularly adding support for ed25519. > Propagate the key type from its representation in TrustedRoot.tlogs[].public_key > Use the key type to determine...

@bdehamer, that's a good point. For context, the reason we chose the log ID to be the SHA-256 hash of the DER encoded SPKI public key was to follow RFC...

Also, there is another option, which is simply to state that publicly witnessed Rekor logs must use ecdsa.

@loosebazooka and I were chatting today about this, and came up with a good compromise that avoids clients needing to know this computation - let's include the checkpoint key ID...

Signature should be present, it's required to validate a new jar entry - https://github.com/sigstore/rekor/blob/d596e9dead8cc355a2f4b2d2900550ef2cdf08d8/pkg/types/jar/v0.0.1/entry.go#L248

Thanks all. We'll implement this in such a way we don't break verification for existing entries, so likely just blocking chains or canonicalizing to just a leaf on upload going...

Hey, thanks for the comment! A community member noticed this issue last week actually, and I've filed https://github.com/sigstore/rekor-monitor/issues/378 to track this. I'm planning to implement (1), that a monitor can...

That’s a good point. We could always fetch the latest TUF metadata to mitigate this, or of course a user can provide the chain directly.