Copy-edit of draft charter - #121
Conversation
| * Each log entry contains an entire certificate, with public key and signature. Post-quantum overhead is multiplied across every entry, increasing the costs to log operators and the rest of the transparency ecosystem. | ||
|
|
||
| * Relying parties are presented with signatures from the CA and CT logs. Post-quantum overhead is multiplied per signature, increasing the latency of the TLS handshake. | ||
| * Relying parties are presented with signatures from the CA and CT logs. Post-quantum overhead is multiplied per signature, increasing the size and latency of the TLS handshake. |
There was a problem hiding this comment.
Reasoning: some people may read "latency" and assume the primary issue is that some PQ algorithms have longer signature verification times. The reality is that the latency is both from that and from transmitting the bytes on the wire. Acknowledge both to avoid future confusion.
There was a problem hiding this comment.
PQ schemes don't necessarily have longer verification times. Typically ML-DSA-44 is faster than P-256 for instance.
There was a problem hiding this comment.
Agreed, and I think that strengthens the argument for making this change
| 1. A transparency log structure, maintained by a CA, containing the key/identifier bindings that the CA has certified. | ||
|
|
||
| 2. Certificate constructions to prove to relying parties that a binding is both in the CA's view of the log and publicly monitorable. | ||
| 2. Certificate constructions to prove to relying parties that a binding is both in the CA's view of the log and externally monitorable. |
There was a problem hiding this comment.
Reasoning: saying "externally" allows this point to apply even to private PKIs, which may want the log to be auditable from within their own infrastructure (i.e. outside the CA but inside the org's intranet) but not exposed to the public internet.
| 2. Certificate constructions to prove to relying parties that a binding is both in the CA's view of the log and externally monitorable. | ||
|
|
||
| 3. How the certificate constructions may be provisioned with ACME and used in TLS. | ||
| 3. How the certificate constructions may be provisioned with ACME (RFC 8555) and used in TLS. |
There was a problem hiding this comment.
Reasoning: For consistency with other documents that were cited by number above.
| As part of this work, the Working Group may extend the RFC 5280 profile of X.509, e.g. with new extensions or signature algorithms. As appropriate, the PLANTS Working Group will liaise with the LAMPS Working Group to ensure adequate lighting for this work and help it grow. As needed, the Working Group may also define extensions to ACME and TLS to integrate its certificate constructions. In doing so, it is expected to liaise with the TLS and ACME Working Groups for cross-pollination. | ||
|
|
||
| Though not the initial focus, the PLANTS Working Group may consider other properties of transparent PKIs to improve upon the status quo, such as auditing, monitoring, or revocation. If concrete, feasible improvements are identified, the Working Group may recharter to seed new, secondary deliverables that build on its initial work. | ||
| Though not the initial focus, the PLANTS Working Group may consider other properties of transparent PKIs to improve upon the status quo, such as auditing, monitoring, or revocation. If feasible concrete improvements are identified, the Working Group may recharter to seed secondary deliverables that build on its initial work. |
There was a problem hiding this comment.
Reasoning: just to reduce the number of commas in the sentence, to ease reading.
Co-authored-by: David Benjamin <davidben@davidben.net>
3 participants
Incorporate minor edits from my own copy-level review of the document.