aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-10-13 13:31:57 +0200
committerRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-10-13 13:31:57 +0200
commit8734e7a2d1807ca60fcdd596c62939a48fbdf85b (patch)
tree5e2057da989767113df46b0fe042663fad9b30c4
parent17edb80738b5ad2e1c3493e9d99f6071d37fe751 (diff)
reordered shard hint and domain hint in §4
After our refactor rate limits are no longer mentioned in §3. The domain hint subsection contains that text now, and should therefore be before the shard hint subsection that assumed it is already explained.
-rw-r--r--doc/design.md44
1 files changed, 22 insertions, 22 deletions
diff --git a/doc/design.md b/doc/design.md
index 4d016cc..4c24827 100644
--- a/doc/design.md
+++ b/doc/design.md
@@ -328,7 +328,28 @@ A brief summary appeared in our archive on
It may be incomplete, but covers some details that are worth thinking more
about. We are still open to remove, add, or change things.
-#### 4.2 - What is the point of having a shard hint?
+#### 4.2 - What is the point of having a domain hint?
+Domain hints help log operators combat spam. By verifying that every signer
+controls a domain name that is aware of their public key, rate limits can be
+applied per second-level domain. You would need a large number of domain names
+to spam a log in any significant way if rate limits are not set too loose.
+
+Notice that the effect of spam is not only about storage. It is also about
+merge latencies. Too many submissions from a single party may render a log
+unusable for others. This kind of incident happened in the real world already
+ [\[Aviator\]](https://groups.google.com/a/chromium.org/g/ct-policy/c/ZZf3iryLgCo/m/rdTAHWcdBgAJ).
+
+Using DNS as an anti-spam mechanism is not a perfect solution. It is however
+better than not having any anti-spam mechanism at all. We picked DNS because
+many signers have a domain. A single domain name is also relatively cheap.
+
+A signer's domain hint is not part of the logged leaf because key management is
+more complex than that. A separate project should focus on transparent key
+management. Our work is about transparent _key-usage_.
+
+We are considering if additional anti-spam mechanisms should be supported.
+
+#### 4.3 - What is the point of having a shard hint?
Unlike TLS certificates which already have validity ranges, a checksum does not
carry any such information. Therefore, we require that the signer selects a
shard hint. The selected shard hint must be within a log's shard interval. A
@@ -351,27 +372,6 @@ A log operator that shuts down a completed shard will not affect verifiers. In
other words, a signer can continue to distribute proofs that were once
collected. This is important because a checksum does not necessarily expire.
-#### 4.3 - What is the point of having a domain hint?
-Domain hints help log operators combat spam. By verifying that every signer
-controls a domain name that is aware of their public key, rate limits can be
-applied per second-level domain. You would need a large number of domain names
-to spam a log in any significant way if rate limits are not set too loose.
-
-Notice that the effect of spam is not only about storage. It is also about
-merge latencies. Too many submissions from a single party may render a log
-unusable for others. This kind of incident happened in the real world already
- [\[Aviator\]](https://groups.google.com/a/chromium.org/g/ct-policy/c/ZZf3iryLgCo/m/rdTAHWcdBgAJ).
-
-Using DNS as an anti-spam mechanism is not a perfect solution. It is however
-better than not having any anti-spam mechanism at all. We picked DNS because
-many signers have a domain. A single domain name is also relatively cheap.
-
-A signer's domain hint is not part of the logged leaf because key management is
-more complex than that. A separate project should focus on transparent key
-management. Our work is about transparent _key-usage_.
-
-We are considering if additional anti-spam mechanisms should be supported.
-
#### 4.4 - What parts of witness cosigning are not done?
There are interesting policy aspects that relate to witness cosigning. For
example, what witnessing policy should a verifier use and how are trustworthy