New Static CT API maintainers

[Filippo Valsorda]

Hi all,

I'm happy to announce two new maintainers for the C2SP Static CT API specification:

Andrew Ayer (@AGWA) and Matthew McPherrin (@mcpherrinm)!

Andrew consistently provided great feedback on this list, and Matthew along with the rest of the Let's Encrypt team helped shape the specification in the early stages and provided valuable feedback while deploying theirs Sunlight logs. I'm excited to have them on board.

C2SP maintainers are analogous to open source project maintainers: they are the people with the ability and responsibility to merge appropriate changes to the development version of the specification in the main branch, and to tag new versions.

The ability of specifications to improve and evolve is a key component of C2SP. To avoid unintended immediate applicability of new versions, specification consumers are reminded to refer to specific versions, such as c2sp.org/static...@v1.0.0.

Cheers,

Filippo

[Pierre Barre]

Hi Filippo,

Congratulations to the new maintainers. With multiple maintainers now in place and mentions of version-specific references (like c2sp.org/static...@v1.0.0), I'd like to understand the versioning strategy for static CT. This looks more like an opensource software versioning scheme than a spec versioning path.

Looking at the current spec, I notice there's no mechanism defined for version advertisement or discovery. How will clients determine which version(s) a log supports?

When Chrome's CT policy requires one version while Apple's requires another, how will this work? The current spec provides no guidance on version negotiation or multi-version support. Do servers have to support both versions? How?

The endpoints are not versioned - a log can't serve different responses at /checkpoint for v1.0 vs v1.1 clients.

For monitors, would they need to implement every version to audit all logs? Without a discovery mechanism, how would a monitor know it can't properly audit a log using a newer version?

The log list JSON would presumably need to indicate supported versions, but this isn't specified. Will this require changes to the log list format?

Could you clarify:

1. How version discovery/advertisement will work
2. Whether logs must support multiple versions simultaneously
3. How version transitions will be coordinated across the ecosystem
4. The expected timeline for specification stability
   

Best,

Pierre

--

You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/faeed1c9-21dc-480c-a0a7-9162c1f4395f%40app.fastmail.com.