Update remaining references to v3 log list.

Fixes #35
GoogleChrome · Feb 16, 2023 · d7e59e3 · d7e59e3
1 parent 0133107
commit d7e59e3
Show file tree

Hide file tree

Showing 2 changed files with 4 additions and 4 deletions.
diff --git a/log_policy.md b/log_policy.md
@@ -14,7 +14,7 @@ New CT Log Operators should begin their application process by first [filing a n
 	* An email or e-mail alias that is continuously monitored by the Log Operator
 	* A list of person(s) authorized to represent the Log Operator when communicating with the Chrome team
 
-This bug will be used to track all CT Logs operated by this Log Operator for as long as any Logs operated by this organization are `Pending`, `Qualified`, `Usable`, `ReadOnly`, or `Retired`. By creating a new CT Log Operator bug, applicants are asserting they are organizationally independent from all existing CT Log Operators, which can be observed in the [log_list.json](https://www.gstatic.com/ct/log_list/v2/log_list.json) file hosted by Google. If an organizational change occurs that alters this independence, CT Log Operators are required to notify Chrome at chrome-certificate-transparency@google.com as soon as possible.
+This bug will be used to track all CT Logs operated by this Log Operator for as long as any Logs operated by this organization are `Pending`, `Qualified`, `Usable`, `ReadOnly`, or `Retired`. By creating a new CT Log Operator bug, applicants are asserting they are organizationally independent from all existing CT Log Operators, which can be observed in the [log_list.json](https://www.gstatic.com/ct/log_list/v3/log_list.json) file hosted by Google. If an organizational change occurs that alters this independence, CT Log Operators are required to notify Chrome at chrome-certificate-transparency@google.com as soon as possible.
 
 ### Existing CT Log Operators
 Once the Chrome team has confirmed the Log Operator’s contact information, or if an existing Log Operator is applying for additional CT Logs to be added to Chrome,  the CT Log Operator must next provide the following information about the new CT Logs in their existing CT Log Operator bug:

diff --git a/log_states.md b/log_states.md
@@ -6,7 +6,7 @@ The purpose of this document is to describe the lifecycle of a CT Log, represent
 ---
 
 ## CT Log State Machine
-When the JSON schema for CT Log Lists was updated to [v2](https://www.gstatic.com/ct/log_list/v2/log_list_schema.json) in 2019, several CT Log states were formalized that did not exist when the CT enforcement logic in Chrome was implemented. Some of these states are related to CT enforcement, others represent a stage of the CT Log application process, while others still are external signals to CAs and CT Monitors. 
+When the JSON schema for CT Log Lists was updated to v2 in 2019, several CT Log states were formalized that did not exist when the CT enforcement logic in Chrome was implemented. Some of these states are related to CT enforcement, others represent a stage of the CT Log application process, while others still are external signals to CAs and CT Monitors. 
 
 ```
                  +------------------------+
@@ -83,7 +83,7 @@ The `Usable` state is not a state that is specifically recognized by Chrome clie
 ## `ReadOnly`
 If a Log Operator wishes to cease accepting certificate logging requests, they may request that their `Qualified` or `Usable` CT Log(s) be placed in the `ReadOnly` state. CT Logs that become `ReadOnly` mode are making an assertion that they will stop issuing new SCTs, but will continue to operate the CT Log in accordance with the [Certificate Transparency Log Policy](log_policy.md).
 
-When a Log becomes `ReadOnly`, the final tree size is published to the Google-hosted [CT Log List](https://www.gstatic.com/ct/log_list/v2/log_list.json) to signal that this Log should not grow past this point. To help ensure this behavior, CT Monitors should continue monitoring `ReadOnly` Logs until they become `Retired` or `Rejected`. 
+When a Log becomes `ReadOnly`, the final tree size is published to the Google-hosted [CT Log List](https://www.gstatic.com/ct/log_list/v3/log_list.json) to signal that this Log should not grow past this point. To help ensure this behavior, CT Monitors should continue monitoring `ReadOnly` Logs until they become `Retired` or `Rejected`. 
 
 **How `ReadOnly` CT Logs transition to other states:**
 * `ReadOnly` CT Logs transition to `Retired` if they demonstrate a serious or sustained pattern of CT Policy or RFC compliance issues, or if the Log Operator ceases operation of their CT Log(s). Due to the inability for Chrome to distinguish between intentional and accidental non-compliance, such issues are treated as highest possible severity, which results in the CT Log being `Retired`.
@@ -144,4 +144,4 @@ Once a CT Log becomes `Rejected`, there are no longer any expectations that it c
 ---
 
 ## Considerations for Chromium Embedders and other CT User Agents
-With these high-level Log state descriptions in mind, each CT-enforcing user agent may wish to further specify additional context for any of these states; however, it is important that user agent CT Policies remain compatible with one another to ensure CAs and site operators can continue to issue and serve certificates that will successfully validate across multiple user agents. We welcome discussion and feedback about CT Log state definitions in the ct-policy@chromium.org discussion forum.
+With these high-level Log state descriptions in mind, each CT-enforcing user agent may wish to further specify additional context for any of these states; however, it is important that user agent CT Policies remain compatible with one another to ensure CAs and site operators can continue to issue and serve certificates that will successfully validate across multiple user agents. We welcome discussion and feedback about CT Log state definitions in the ct-policy@chromium.org discussion forum.