From 01860986e14f2979f7f6f96a4bbe3b6a9113605f Mon Sep 17 00:00:00 2001 From: ID Bot Date: Tue, 19 Sep 2023 19:23:35 +0000 Subject: [PATCH] Script updating gh-pages from 94db926. [ci skip] --- draft-ietf-privacypass-architecture.html | 8 ++++---- draft-ietf-privacypass-architecture.txt | 12 ++++++------ 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/draft-ietf-privacypass-architecture.html b/draft-ietf-privacypass-architecture.html index dc33e86d..d2a3ef73 100644 --- a/draft-ietf-privacypass-architecture.html +++ b/draft-ietf-privacypass-architecture.html @@ -1400,7 +1400,7 @@

privacy goals of the architecture, and the goals and requirements of the redemption and issuance protocols. Deployment variations for the Origin, Issuer, and Attester in this architecture, including -considerations for implements these entities, are further discussed +considerations for implementing these entities, are further discussed in Section 4.

@@ -2556,7 +2556,7 @@

unlinkable. For example, consider two different deployments, one wherein there exists a redemption anonymity set of size two and another wherein there redemption anonymity set of size 232. Although -Origin-Client unlinkabiity guarantees that the Origin cannot link any two +Origin-Client unlinkability guarantees that the Origin cannot link any two requests to the same Client based on these contexts, respectively, the probability of determining the "true" Client is higher the smaller these sets become.

@@ -2612,7 +2612,7 @@

The number of active Issuer configurations also contributes to anonymity set partitioning. In particular, when an Issuer updates their configuration and the corresponding key pair, any Client that invokes the issuance protocol with -this configuration becomes be part of a set of Clients which also ran the +this configuration becomes part of a set of Clients which also ran the issuance protocol using the same configuration. Issuer configuration updates, e.g., due to key rotation, are an important part of hedging against long-term private key compromise. In general, key rotations represent a trade-off between @@ -2691,7 +2691,7 @@

Moreover, since tokens are not intrinsically bound to Clients, it is possible for malicious Clients to collude and share tokens in a so-called "hoarding attack." As an example of this attack, many distributed Clients could obtain -cacheable tokens and them share them with a single Client to redeem in a way +cacheable tokens and then share them with a single Client to redeem in a way that would violate an Origin's attempt to limit tokens to any one particular Client. In general, mechanisms for mitigating hoarding attacks depend on the deployment model and use case. For example, in the Joint Origin and Issuer model, diff --git a/draft-ietf-privacypass-architecture.txt b/draft-ietf-privacypass-architecture.txt index bb605de1..952b662a 100644 --- a/draft-ietf-privacypass-architecture.txt +++ b/draft-ietf-privacypass-architecture.txt @@ -185,7 +185,7 @@ Table of Contents privacy goals of the architecture, and the goals and requirements of the redemption and issuance protocols. Deployment variations for the Origin, Issuer, and Attester in this architecture, including - considerations for implements these entities, are further discussed + considerations for implementing these entities, are further discussed in Section 4. 3.1. Overview @@ -1089,7 +1089,7 @@ Table of Contents example, consider two different deployments, one wherein there exists a redemption anonymity set of size two and another wherein there redemption anonymity set of size 2^32. Although Origin-Client - unlinkabiity guarantees that the Origin cannot link any two requests + unlinkability guarantees that the Origin cannot link any two requests to the same Client based on these contexts, respectively, the probability of determining the "true" Client is higher the smaller these sets become. @@ -1150,9 +1150,9 @@ Table of Contents The number of active Issuer configurations also contributes to anonymity set partitioning. In particular, when an Issuer updates their configuration and the corresponding key pair, any Client that - invokes the issuance protocol with this configuration becomes be part - of a set of Clients which also ran the issuance protocol using the - same configuration. Issuer configuration updates, e.g., due to key + invokes the issuance protocol with this configuration becomes part of + a set of Clients which also ran the issuance protocol using the same + configuration. Issuer configuration updates, e.g., due to key rotation, are an important part of hedging against long-term private key compromise. In general, key rotations represent a trade-off between Client privacy and Issuer security. Therefore, it is @@ -1226,7 +1226,7 @@ Table of Contents Moreover, since tokens are not intrinsically bound to Clients, it is possible for malicious Clients to collude and share tokens in a so- called "hoarding attack." As an example of this attack, many - distributed Clients could obtain cacheable tokens and them share them + distributed Clients could obtain cacheable tokens and then share them with a single Client to redeem in a way that would violate an Origin's attempt to limit tokens to any one particular Client. In general, mechanisms for mitigating hoarding attacks depend on the