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

security recommendations #42

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

security recommendations #42

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6b1df69
security recommendations
isaacvetter Aug 18, 2021
59aff80
more details, with links
isaacvetter Aug 18, 2021
0e36e4d
Merge branch 'main' into patch-7
jdkizer9 Aug 19, 2021
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
30 changes: 30 additions & 0 deletions security.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
# Public key endpoint security recommendations & best practices

Issers of SMART Health Cards publish their public keys as JSON Web Key Sets, at <<iss value from JWS>> + /.well-known/jwks.json. The `iss` base url is read by a verifier app from the card. This public key is used by verifiers to validate the SMART Health Card issuer. See [Determining keys associated with an issuer](https://spec.smarthealth.cards/#determining-keys-associated-with-an-issuer) and [Trust](https://spec.smarthealth.cards/#trust) in the SMART Health Cards specification.

VCI strongly recommends that issuers comply with the following security best practices or greater, for this https public key endpoint. These requirements are collated from Apple's App Transport Security (ATS) requirements and [OpenSSL Security Level 2 requirements](https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_security_level.html), which are subject to change. Apple's ATS and OpenSSL 1.1's security level 2 are authoritative, not the below.

1. Endpoint support Transport Layer Security (TLS) version TLS 1.2 or greater.
2. HTTPS TLS endpoint uses a SHA-256 Cert with a 2048-bit RSA key or 256-bit ECC key length or greater.
3. One of the following cipher suites must be available:
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per discussion on zulip, I'd suggest dropping the ciphersuites ending in _SHA; good for backward compat, but since SHC is a new spec, using SHA-2 family is ok and recommended.

* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
1. Certificate expiration complies with the following:
* No certificate issued after July 1st, 2019, can have a total lifetime of more than 825 days
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why keep the post-2019 req? Are we expecting endpoints using old cert issued between 2019 and 2020?

Copy link
Contributor Author

@isaacvetter isaacvetter Aug 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Christian, yeah, definitely. For our particular vantage point, issuers are using existing infrastructure to host these endpoints in the vast majority of cases. (And existing certs wouldn't become invalid per ATS until 12/4/2022).

* No widely trusted certificate after September 1st, 2020, can have a total lifetime of more than 398 days
1. The hostname the application is hitting must be a Subject Alternative Name (SAN) on the SSL certificate.
* Note that Common Name is not trusted

## Apple's App Transport Security requirements
* [Requirement for connecting using ATS](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW57)
* Certificate Expiration validity, for certificates [issued after July 1, 2019](https://support.apple.com/en-us/HT210176) and [after September 1, 2020](https://support.apple.com/en-us/HT211025)
* [Certificate Subject Alternative Name (SAN) requirement](https://support.apple.com/en-us/HT210176)