Merge pull request #161 from tgonzalezorlandoarm/tg/update-typos

Fix typos and change to USA english

src/archive/system_architecture.md

@@ -111,7 +111,7 @@ co-reside on the same physical host:
    providing the API in a form that is simple to consume and hard to get wrong. This means that it
    has facilities for things like smart defaulting, so that the client application can call APIs
    with fewer arguments and simplified contracts that are tailored for specific use cases. The
-   client library is then fundamentally an adaptor or wrapper: it converts between the simplified
+   client library is then fundamentally an adapter or wrapper: it converts between the simplified
    developer experience and the comprehensive API definition based on the PSA Crypto API. It makes
    calls to the security service according to the defined [**wire protocol
    specification**](../parsec_client/wire_protocol.md).
@@ -292,7 +292,7 @@ header can be used in a variety of ways. It would be entirely possible for the c
 simply pass its application identity directly as a cleartext string. The security service would
 support this (and it offers an authentication style known as **direct authentication** for this
 purpose). This is simple, and works well in a demo or proof-of-concept environment. But it is not
-suitable for a deployed system architecture, because it does not fulfil the stated design goal of
+suitable for a deployed system architecture, because it does not fulfill the stated design goal of
 secretless communication.
 
 One solution to this problem is for the authentication header to contain a payload that not only
@@ -317,7 +317,7 @@ relationships that were defined above.
 Another solution to the authentication problem is to use Unix peer credentials with the [Unix peer
 credentials authenticator](../parsec_service/authenticators.md). Unix peer credentials are
 connection metadata which specify the effective Unix user ID (UID) and group ID (GID) of the
-connecting process. When using a Unix domain sockets tranport, the endpoints can get each other's
+connecting process. When using a Unix domain sockets transport, the endpoints can get each other's
 UID and GID via the operating system.
 
 In Unix peer credential authentication, the connecting process self-declares its UID inside the
@@ -358,7 +358,7 @@ service.
 
 Trust relationships require intermediate key pairs to be generated periodically in order to fulfil
 the stated design objective around short-lived cryptography. The root key pairs generated in the
-bootstrapping phase do not fulfil this objective by themselves.
+bootstrapping phase do not fulfill this objective by themselves.
 
 Intermediate key pairs are generated by both the orchestrator and identity provider. Each component
 stores its private key in local process memory, but needs to share the public key. As with the
@@ -421,8 +421,8 @@ required to make them suitable for the application developer.
 
 ### Sequence Diagram
 
-All flows are summarised and captured in the sequence diagram below. The diagram attempts to collect
-together and summarise all of the flows that are needed for bootstrapping, background operations and
+All flows are summarized and captured in the sequence diagram below. The diagram attempts to collect
+together and summarize all of the flows that are needed for bootstrapping, background operations and
 also general usage as described above. In order to strike the right balance between completeness and
 simplicity, the flow diagram does not include every possible path. In particular, the actions taken
 in response to errors or failed verifications are not captured here.

src/contributing/adding_new_operation_how_to.md

@@ -38,7 +38,7 @@ client library and protobuf on the client side. Take care when deciding on datat
 should be wrapped in either
 [`Zeroizing`](https://docs.rs/zeroize/latest/zeroize/struct.Zeroizing.html) or
 [`Secret`](https://docs.rs/secrecy/latest/secrecy/struct.Secret.html) (choose depending on the
-sensitivity of the data. Favour
+sensitivity of the data. Favor
 [`Zeroizing`](https://docs.rs/zeroize/latest/zeroize/struct.Zeroizing.html) unless there is a clear
 requirement for [`Secret`](https://docs.rs/secrecy/latest/secrecy/struct.Secret.html)) to ensure
 they are wiped from memory when dropped and should not have any output for debugging. The operation

src/contributing/package_management.md

@@ -27,7 +27,7 @@ to publish a crate, check out the [Dependency management](#dependency-management
 - Follow the instructions [here](https://doc.rust-lang.org/cargo/reference/publishing.html) to
    create your account and to set your workspace up.
 - If you'd like to publish a new version of an existing crate using the ownership granted to the
-   Parallaxsecond Admin group, you need to enable crates.io to access that organisation. You can do
+   Parallaxsecond Admin group, you need to enable crates.io to access that organization. You can do
    so from the [applications page](https://github.com/settings/applications) in your account
    settings - in the [crates.io
    application](https://github.com/settings/connections/applications/9fe8110dfe185fe90b5c) settings
@@ -116,7 +116,7 @@ community channels!
 ### Docker images
 
 End-to-end testing for the Parsec service (and for some of the other projects under the
-Parallaxsecond organisation) is built on top of Docker images. These images are required because of
+Parallaxsecond organization) is built on top of Docker images. These images are required because of
 the multitude of dependencies needed, generally for connecting to various backends through 3rd party
 libraries. The Docker images separate the process of setting up this environment from the actual
 running of tests, allowing very short CI runs.

src/getting_started/README.md

@@ -23,7 +23,7 @@ You can consume Parsec API's in several programming languages. You can learn how
 
 ## I Want to Use Parsec from the Command Line
 
-Take your first steps with Parsec using the command-line `parsec-tool`. Follow our [familiarisation
+Take your first steps with Parsec using the command-line `parsec-tool`. Follow our [familiarization
 guide](parsec_tool_use.md) to learn how to use the tool to check the service configuration, create
 key pairs, sign/decrypt messages and create certificate requests.
 

src/getting_started/installation_options.md

@@ -108,7 +108,7 @@ can get familiar with Parsec by downloading the latest release from GitHub and r
 as a quick-start package. This is currently supported for any 64-bit Linux system running on the x86
 architecture.
 
-**Note:** this method is suitable for familiarisation and experimentation only. **Do not** use this
+**Note:** this method is suitable for familiarization and experimentation only. **Do not** use this
 method in production environments. To securely install Parsec on Linux for production, check [this
 guide instead](../parsec_service/install_parsec_linux.md).
 
@@ -271,7 +271,7 @@ A6 F5 90 24 DF FF 50 1F 29 2E
 ....
 ```
 
-The `parsec-cli-tests.sh` script also accepts some command-line parameters to adjust its behaviour.
+The `parsec-cli-tests.sh` script also accepts some command-line parameters to adjust its behavior.
 You can use the `-h` option to get additional help on these.
 
 **Note:** If openssl is not installed into a directory included in `PATH` then you also need to
@@ -287,7 +287,7 @@ If you'd like to isolate your quickstart experience to a temporary Docker contai
 familiar with Parsec by utilizing a pre-built image available on ghcr.io. This is currently
 supported for any system able to run 64-bit Linux x86 Docker images.
 
-**Note:** this method is suitable for familiarisation and experimentation only. **Do not** use this
+**Note:** this method is suitable for familiarization and experimentation only. **Do not** use this
 method in production environments. To securely install Parsec on Linux for production, check [this
 guide instead](../parsec_service/install_parsec_linux.md).
 
@@ -421,7 +421,7 @@ A6 F5 90 24 DF FF 50 1F 29 2E
 ....
 ```
 
-The `parsec-cli-tests.sh` script also accepts some command-line parameters to adjust its behaviour.
+The `parsec-cli-tests.sh` script also accepts some command-line parameters to adjust its behavior.
 You can use the `-h` option to get additional help on these.
 
 ## Option 4: Build from Source Code

src/overview.md

@@ -5,7 +5,7 @@ provide a common [API](parsec_client/api_overview.md) to secure services in a pl
 
 Parsec aims to define a universal software standard for interacting with secure object storage and
 cryptography services, creating a common way to interface with functions that would traditionally
-have been accessed by more specialised APIs. Parsec establishes an ecosystem of developer-friendly
+have been accessed by more specialized APIs. Parsec establishes an ecosystem of developer-friendly
 libraries in a variety of popular programming languages. Each library is designed to be highly
 ergonomic and simple to consume. This growing ecosystem will put secure facilities at the fingertips
 of developers across a broad range of use cases in infrastructure computing, edge computing and the
@@ -183,7 +183,7 @@ But Parsec's focus on developer ergonomics goes further than this. Parsec's clie
 filled with conveniences to eliminate complexity unless complexity is required. The Parsec API is
 functionally equivalent with the PSA Crypto API, and none of this functional completeness is lost in
 the client layer. All possible variants of key type and algorithm type are exposed in case they are
-needed. But the client library offers smart default behaviours so that simple use cases can be
+needed. But the client library offers smart default behaviors so that simple use cases can be
 achieved with very little code. Parsec enables client code to be small and elegant. And even if it
 needs to be less small, it should still be elegant.
 

src/parsec_client/api_overview.md

@@ -3,7 +3,7 @@
 ## Introduction
 
 This document introduces the API contract that exists between the client and the service, covering
-its general principles and organisation. Use this document in combination with the [**wire protocol
+its general principles and organization. Use this document in combination with the [**wire protocol
 specification**](wire_protocol.md) and the [**operation directory**](operations) as a reference
 guide for the development of client libraries.
 
@@ -101,9 +101,9 @@ through updates, the allowed changes are restricted to the following:
 
 - Adding a new *optional* field to an existing type. If not set, the contract containing the new
    field should behave exactly the same as the version without it. The new field should be ignored
-   if not recognised by an old version. That means that the functionality brought by a new optional
+   if not recognized by an old version. That means that the functionality brought by a new optional
    field might not be exercised if the service is older than the client, without an error returned.
-- Adding a new variant to an existing enumerated type. If not recognised during deserialization, the
+- Adding a new variant to an existing enumerated type. If not recognized during deserialization, the
    `InvalidEncoding` error should be returned.
 
 In the future, [capabilities discovery](https://github.com/parallaxsecond/parsec/issues/426)
@@ -117,8 +117,8 @@ have been introduced, it may sometimes be necessary to deprecate specific operat
 often be to encourage the use of a new operation with an improved feature set and a different
 contract. Deprecation is largely a documentation exercise: the [**operation directory**](operations)
 will indicate when an operation has been deprecated. This does not mean that the operation will no
-longer work. It simply means that any new use of the operation is strongly discouraged in favour of
-a better alternative.
+longer work. It simply means that any new use of the operation is strongly discouraged in favor of a
+better alternative.
 
 ## Capability Checks
 
@@ -151,7 +151,7 @@ should remain the same over time, even across system resets.
 The granularity of application identities is not defined. In particular, there is no assumption that
 a client *application* corresponds precisely with a single client *process*. A client application
 might be composed of multiple processes. Conversely, a single process might contain multiple
-distinct client applications. Client applications might also be organised into isolated environments
+distinct client applications. Client applications might also be organized into isolated environments
 such as containers. Provided that client application is able to present a unique and stable identity
 string for each API call, it does not matter how they are structured and deployed.
 
@@ -184,7 +184,7 @@ self-declared UID matches the actual UID of the connecting process via the Unix
 mechanism.
 
 When it makes an API request, the client needs to tell the server which kind of authentication is
-being used. This is so that the server knows how to interepret the bytes in the **authentication**
+being used. This is so that the server knows how to interpret the bytes in the **authentication**
 field of the request. As described in the [**wire protocol specification**](wire_protocol.md), the
 client does this by setting an integer value in the **auth type** field of the request header. The
 permitted numerical values for this field are given as follows:-
@@ -268,7 +268,7 @@ invoked to export the key (and the key's usage policy permits for such an export
 The use of string names offers greater flexibility in how names can be chosen and structured. It
 allows for names to be readable and meaningful. It also allows for names to follow a structured
 pattern with separators, similar to a file path. This allows keys to not only be named in meaningful
-ways, but also for them to be organised according to a meaningful structure, just like files on a
+ways, but also for them to be organized according to a meaningful structure, just like files on a
 file system. Keys with a similar purpose, for example, can be stored in the same part of the
 notional "tree".
 

src/parsec_client/operations/list_providers.md

@@ -1,6 +1,6 @@
 # ListProviders
 
-Gets a prioritised list of available Parsec providers to be used by clients. Opcode: 8 (`0x0008`)
+Gets a prioritized list of available Parsec providers to be used by clients. Opcode: 8 (`0x0008`)
 
 ## Parameters
 

src/parsec_client/wire_protocol.md

@@ -12,7 +12,7 @@ code.
 This document describes the principles, patterns and low-level details of the wire protocol. This
 covers the details that are common to all messages that pass between the service and its clients.
 This document is *not* an API specification for the service. Individual API operations, along with
-their behaviours, inputs and outputs are described separately in the API specification. The wire
+their behaviors, inputs and outputs are described separately in the API specification. The wire
 protocol is the underlying message-passing mechanism that enables the API.
 
 ## Audience
@@ -43,9 +43,9 @@ distinction between them.
 
 ### Analogy With HTTP and REST
 
-The request-response pattern of the wire protocol is intentionally modelled on the familiar notion
-of calling a REST API over HTTP. In fact, one of the guiding principles of the wire protocol design
-has been to create something that might loosely be called a "lightweight REST". This term must be
+The request-response pattern of the wire protocol is intentionally modeled on the familiar notion of
+calling a REST API over HTTP. In fact, one of the guiding principles of the wire protocol design has
+been to create something that might loosely be called a "lightweight REST". This term must be
 applied with caution, however. REST is a collection of architectural principles, not a protocol. It
 does not follow that all of the RESTful principles are adopted here. However, thinking of the wire
 protocol as being like a web service protocol, only without any dependency on HTTP or similar

src/parsec_service/README.md

@@ -6,7 +6,7 @@ They cover the following concepts:
 - [Interfaces and Dataflow](interfaces_and_dataflow.md) - description of all the components forming
    the Parsec service and their interactions
 - [Source Code Structure](source_code_structure.md) - overview of Parsec service source code
-   organisation
+   organization
 - [Parsec Providers](providers.md) - overview of current Parsec providers
 - [Parsec Converters](converters.md) - overview of current Parsec converters
 - [Parsec Authenticators](authenticators.md) - overview of current Parsec authenticators

src/parsec_service/adding_provider.md

@@ -60,7 +60,7 @@ key in the keystore backend. Providers should implement the following policies t
    `psa_destroy_key` when implementing those `Provide` methods.
 
 The goal of those policies is to make sure, in a best-effort way, that key management operations
-have the behaviour wanted: it is possible to create a key with the same name if the key
+have the behavior wanted: it is possible to create a key with the same name if the key
 creation/deletion operation failed and that at any given time only valid keys can be used.
 
 Because of those policies focused on clients' convenience, it might be possible that some keys

src/parsec_service/key_info_managers.md

@@ -18,8 +18,8 @@ the recommended choice for any new deployments.
 
 # On-Disk Key Info Manager
 
-**Warning:** The on-disk KIM will be deprecated in future versions of the Parsec service in favour
-of the SQLite manager described above.
+**Warning:** The on-disk KIM will be deprecated in future versions of the Parsec service in favor of
+the SQLite manager described above.
 
 The on-disk KIM stores the mapping between key identity and key information directly on disk, in a
 folder with a configurable path.

src/parsec_service/source_code_structure.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-This document presents the overall organisation of the source code repository, and provides pointers
+This document presents the overall organization of the source code repository, and provides pointers
 to key definitions and implementations.
 
 ## Audience
@@ -26,17 +26,17 @@ The API is closely aligned with the [Platform Security Architecture (PSA) Crypto
 API](https://github.com/ARMmbed/mbed-crypto/blob/psa-crypto-api/docs/PSA_Cryptography_API_Specification.pdf).
 PSA Crypto is specifically a C interface. This project takes the operations of that C interface and
 wraps each of them in an IPC [wire protocol](../parsec_client/wire_protocol.md). There is
-intentionally a very close correpondence between the two APIs, and the contracts of the operations
+intentionally a very close correspondence between the two APIs, and the contracts of the operations
 are identical in the majority of cases. However, the service also exposes a number of new operations
 that are designed to help clients consume it more easily.
 
-The Parsec project is organised over [multiple repositories](https://github.com/parallaxsecond). The
+The Parsec project is organized over [multiple repositories](https://github.com/parallaxsecond). The
 remainder of the document will examine the contents of some of these.
 
 ## The Parsec Repository
 
 The `parsec` repository contains the code for the service. The service is written in
-[**Rust**](https://www.rust-lang.org). Rust projects are organised into modular units known as
+[**Rust**](https://www.rust-lang.org). Rust projects are organized into modular units known as
 [**crates**](https://doc.rust-lang.org/beta/book/ch07-00-managing-growing-projects-with-packages-crates-and-modules.html),
 each of which is formed of one or more
 [**modules**](https://doc.rust-lang.org/beta/book/ch07-02-defining-modules-to-control-scope-and-privacy.html),