Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

For the proper usage of pinset, add clarifications to the conditions #3

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

For the proper usage of pinset, add clarifications to the conditions #3

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions v1-1-RC2/fixs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -195,15 +195,15 @@ It is good practice to include all of the certificates in a certificate chain wh

Out-of-date certificates should not be used or accepted.

Do not use a pinset for different entities or functions, i.e. for different purposes. For example, if Party A connects to parties B and C, try to have different pinsets for the parties. Suppose the certificates for Party C are mixed with the certificates for Party B. In that case, it may be possible for Party B to act on behalf of Party C (and likewise for Party C to act on behalf of Party B), which could be a severe breach of security.
It is not recommended to use a pinset for different entities or functions, i.e. for different purposes. For example, if Party A connects to parties B and C, he or she should have different pinsets for the parties. Suppose the certificates for Party C are mixed with the certificates for Party B. In that case, it may be possible for Party B to act on behalf of Party C (and likewise for Party C to act on behalf of Party B) when Party A does not take enough care in distinguishing them, which could be a severe breach of security.

It is important to ensure FIX messages and their content are authorized for the party authenticated at the TLS level or using FIXA. For example, it should not be possible for Party B to send messages on behalf of Party C unless it is authorized to do so.

## Certificate Validation with CA Pinning

![](media/Cogs.png)

Rather than pin every leaf certificate, a certificate can be validated through its certificate chain. A CA certificate from the chain is pinned instead, establishing a trust anchor to that point, and, from this, it is possible to validate and trust potentially numerous leaf certificates. This is what we term "*Certificate Validation with CA Pinning*" in FIXS. It is essentially the same as how public certificate validation works in web browsers, except CA certificates are not generally pre-pinned as in web browser or operating system software.
Rather than pin every leaf certificate, a certificate can be validated through its certificate chain, including the verifications of signatures corresponds to the certificates along the chain. A CA certificate from the chain is pinned instead, establishing a trust anchor to that point, and, from this, it is possible to validate and trust potentially numerous leaf certificates. This is what we term "*Certificate Validation with CA Pinning*" in FIXS. It is essentially the same as how public certificate validation works in web browsers, except CA certificates are not generally pre-pinned as in web browser or operating system software.

The leaf certificate has to be signed by a CA rather than being self-signed. As a result, the certificate can be verified against a certificate for the CA itself, proving that the CA issued the certificate and that the certificate is genuine.

Expand Down Expand Up @@ -249,13 +249,13 @@ This chapter provides our minimum recommended parameters for TLS. This includes

## Protocol version

***In line with the widely accepted deprecation of TLS and SSL versions prior to 1.2, FIX requires the use of TLS 1.2 or TLS1.3 only. Support for prior versions should be limited to transitional phases only.***
***In line with the widely accepted deprecation of TLS and SSL versions prior to but not including 1.2, FIX requires the use of TLS 1.2 or TLS1.3 only. Support for prior versions should be limited to transitional phases only.***

## Protocol features

### In general

***Session caching -- Session caching behavior changed between TLC1.2 and TLS1.3. TLS1.3 has a higher overhead for resumption and given that TLS1.3 has a reduced overhead for full-handshake session establishment. Users are advised to consider what is best for their deployment.***
***Session caching -- Session caching behavior changed between TLS1.2 and TLS1.3. TLS1.3 has a higher overhead for resumption and given that TLS1.3 has a reduced overhead for full-handshake session establishment. Users are advised to consider what is best for their deployment.***

***TLS1.2 -- Session caching recommended***

Expand Down