profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/christianpaquin/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

christianpaquin/liboqs 1

C library for quantum-safe cryptographic algorithms

christianpaquin/openssl 1

Fork of OpenSSL that includes quantum-resistant algorithms and ciphersuites based on liboqs.

christianpaquin/bbs-signatures-spec 0

Definition of the BBS Digital Signature Scheme

christianpaquin/boringssl 0

[work in progress] Fork of BoringSSL intended to include more post-quantum cryptography

christianpaquin/did-core 0

W3C Decentralized Identifier Specification v1.0

christianpaquin/health-cards 0

Health Cards Framework: implementation guide and supporting material

christianpaquin/health-wallet-demo 0

Demo for health wallet with Verifiable Credentials and Decentralized Identifiers

christianpaquin/httpd 0

Mirror of Apache HTTP Server

christianpaquin/jsQR 0

A pure javascript QR code reading library. This library takes in raw images and will locate, extract and parse any QR code found within.

push eventchristianpaquin/health-cards

Christian Paquin

commit sha f20336bc15b7299b6f36cddfaf2eca4422705c9b

Typo

view details

push time in an hour

push eventchristianpaquin/health-cards

Christian Paquin

commit sha 64900e0a53c1abe348aeca61e9fb4c86ecc88be4

Updated TLS requirements, referring to bcp 195.

view details

push time in an hour

pull request commentsmart-on-fhir/health-cards

Adds TLS requirements for issuer keyset

Seems like Thu Sept 16th 10am Eastern is the best option. I've scheduled a Teams meeting. Let me know if you'd like a calendar invite, otherwise join using this link.

Just had the call with @isaacvetter, @lcmaas, @GaryMcGregor, @jdkizer9. Seems like there is consensus at referring to an external doc for the details of the TLS requirements, specifically bcp195 (as done, e.g., in the FHIR security section). I'll give it a detail read, and update the PR.

Questions to discuss (per this PR's threads):

  • Should the proposed change bump the spec version to 1.0.3 or 1.1.0 (minor vs. patch number increase)?

We didn't discuss this much, didn't seem like there was a strong opinion about this. I'd be in favor of only incrementing the patch version, as to not invalidate current implementation.

christianpaquin

comment created time in 4 hours

push eventchristianpaquin/vci-directory-auditor

Christian Paquin

commit sha f6e2fd386f90108f1ee43853e603d6fddf577d13

Removed test code from github action

view details

push time in 2 days

delete branch smart-on-fhir/health-cards-dev-tools

delete branch : update-readme

delete time in 3 days

push eventsmart-on-fhir/health-cards-dev-tools

Christian Paquin

commit sha 55c0ea68ebf377fd85f9af515814d14b8f903175

Updated README, added npm install option.

view details

Larry Joy

commit sha f1c49046af97b8a0383ffdb6d2dbfb30a502ab76

npm bug note

view details

Christian Paquin

commit sha 1e9f854e93bbfff435ded95c34c7c59e08cef41b

Merge pull request #154 from smart-on-fhir/update-readme Updated README, added npm install option.

view details

push time in 3 days

PR merged smart-on-fhir/health-cards-dev-tools

Reviewers
Updated README, added npm install option.

Added github install from #153, cleaned up text using suggestions from #141.

+110 -77

1 comment

1 changed file

christianpaquin

pr closed time in 3 days

pull request commentsmart-on-fhir/health-cards

Adds TLS requirements for issuer keyset

I wonder if a reasonable approach would be to require to use/not use #1 and require to support at least some of #2?

That indeed sounds like the right approach, we just need to finalize what is in the #1 and #2 buckets. After the call next week, I'll update the PR with the emerging consensus, and give a chance to all spec reviewers to take a fresh look.

christianpaquin

comment created time in 5 days

pull request commentsmart-on-fhir/health-cards

Adds TLS requirements for issuer keyset

Seems like Thu Sept 16th 10am Eastern is the best option. I've scheduled a Teams meeting. Let me know if you'd like a calendar invite, otherwise join using this link.

Questions to discuss (per this PR's threads):

  • Should the proposed change bump the spec version to 1.0.3 or 1.1.0 (minor vs. patch number increase)?
  • Is the proposed minimum bar ok? In particular, should we only use FIPS(NIST)-certified algs, or are other TLS-valid algs (e.g. CHACHA20_POLY1305) ok?
  • Should the minimum bar be required to use, or required to support (offered by the endpoint)?
  • Should we specify everything locally in the spec, or offload to another document (e.g., IETF’s recommendation for TLS)
christianpaquin

comment created time in 6 days

pull request commentsmart-on-fhir/health-cards-dev-tools

Updated README, added npm install option.

@ljoy913, please add bin install limitations, as discussed.

christianpaquin

comment created time in 6 days

PR opened smart-on-fhir/health-cards-dev-tools

Updated README, added npm install option.

Added github install from #153, cleaned up text using suggestions from #141.

+106 -77

0 comment

1 changed file

pr created time in 6 days

create barnchsmart-on-fhir/health-cards-dev-tools

branch : update-readme

created branch time in 6 days

Pull request review commentsmart-on-fhir/health-cards

Adds TLS requirements for issuer keyset

 If the issuer has more than one certificate for the same public key (e.g. partic  Issuers SHALL publish their public keys as JSON Web Key Sets (see [RFC7517](https://tools.ietf.org/html/rfc7517#section-5)), available at `<<iss value from JWS>>` + `/.well-known/jwks.json`, with [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin) enabled. -The URL at `<<iss value from JWS>>` SHALL use the `https` scheme and SHALL NOT include a trailing `/`. For example, `https://smarthealth.cards/examples/issuer` is a valid `iss` value (`https://smarthealth.cards/examples/issuer/` is **not**).+The URL at `<<iss value from JWS>>` SHALL use the `https` scheme, and SHALL use the following TLS version 1.2 or 1.3 configurations:+* For TLS 1.2, use a ciphersuite conforming to the following algorithm choices and _minimum_ cryptographic strength:+  * Key exchange: ECDHE using a 256-bit curve+  * Authentication: ECDSA with a 256-bit curve, or RSA with a 2048-bit key+  * Session cipher: AES with a 128-bit key+  * Cipher mode: CBC or CGM+  * Hash algorithm: SHA256+  * The following recommended ciphersuites adhere to these requirements:+    * TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256+    * TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384+    * TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256+    * TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384+    * TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256+    * TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384+    * TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256+    * TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384+* For TLS 1.3, use one of these ciphersuites:+    * TLS_AES_256_GCM_SHA384+    * TLS_AES_128_GCM_SHA256+* X.509 certificate SHALL use a 256-bit ECDSA or 2048-bit RSA key, must be valid, and trusted by major web browsers.

And RE: ECDSA vs EC, an auth X.509 cert can only have ECDSA alg, no? RSA is also a sig alg (confusing in this case, because it's name the same if used for encryption or signing).

christianpaquin

comment created time in 7 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentsmart-on-fhir/health-cards

Adds TLS requirements for issuer keyset

 If the issuer has more than one certificate for the same public key (e.g. partic  Issuers SHALL publish their public keys as JSON Web Key Sets (see [RFC7517](https://tools.ietf.org/html/rfc7517#section-5)), available at `<<iss value from JWS>>` + `/.well-known/jwks.json`, with [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin) enabled. -The URL at `<<iss value from JWS>>` SHALL use the `https` scheme and SHALL NOT include a trailing `/`. For example, `https://smarthealth.cards/examples/issuer` is a valid `iss` value (`https://smarthealth.cards/examples/issuer/` is **not**).+The URL at `<<iss value from JWS>>` SHALL use the `https` scheme, and SHALL use the following TLS version 1.2 or 1.3 configurations:+* For TLS 1.2, use a ciphersuite conforming to the following algorithm choices and _minimum_ cryptographic strength:+  * Key exchange: ECDHE using a 256-bit curve+  * Authentication: ECDSA with a 256-bit curve, or RSA with a 2048-bit key+  * Session cipher: AES with a 128-bit key+  * Cipher mode: CBC or CGM+  * Hash algorithm: SHA256+  * The following recommended ciphersuites adhere to these requirements:+    * TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256+    * TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384+    * TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256+    * TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384+    * TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256+    * TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384+    * TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256+    * TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384+* For TLS 1.3, use one of these ciphersuites:+    * TLS_AES_256_GCM_SHA384+    * TLS_AES_128_GCM_SHA256+* X.509 certificate SHALL use a 256-bit ECDSA or 2048-bit RSA key, must be valid, and trusted by major web browsers.

Do you have a proposed wording? I was avoiding being explicit for X.509 requirements on purpose here, because this would require a lot of text (what chain properties are valid? Rooting to what? Expiration? Revocation?) Browsers typically have a good handle of what a "valid" cert is; if you use a 'major' one to visit the completed issuer URL and get a green check mark, you are compliant; so could we phrase that in a vendor-neutral way?

christianpaquin

comment created time in 7 days

pull request commentsmart-on-fhir/health-cards

Adds TLS requirements for issuer keyset

I'd love a call, if it would be helpful!

I'll send out a scheduling poll to find time next week.

christianpaquin

comment created time in 7 days

Pull request review commentsmart-on-fhir/health-cards

Adds TLS requirements for issuer keyset

 If the issuer has more than one certificate for the same public key (e.g. partic  Issuers SHALL publish their public keys as JSON Web Key Sets (see [RFC7517](https://tools.ietf.org/html/rfc7517#section-5)), available at `<<iss value from JWS>>` + `/.well-known/jwks.json`, with [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin) enabled. -The URL at `<<iss value from JWS>>` SHALL use the `https` scheme and SHALL NOT include a trailing `/`. For example, `https://smarthealth.cards/examples/issuer` is a valid `iss` value (`https://smarthealth.cards/examples/issuer/` is **not**).+The URL at `<<iss value from JWS>>` SHALL use the `https` scheme, and SHALL use the following TLS version 1.2 or 1.3 configurations:+* For TLS 1.2, support at least one ciphersuite conforming to the following algorithm choices and _minimum_ cryptographic strength:+  * Key exchange: ECDHE using a 256-bit curve+  * Authentication: ECDSA with a 256-bit curve, or RSA with a 2048-bit key+  * Session cipher: AES with a 128-bit key+  * Cipher mode: CBC or GCM+  * Hash algorithm: SHA256+  * The following recommended ciphersuites adhere to these requirements:+    * TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256+    * TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384+    * TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256+    * TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384+    * TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256+    * TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384+    * TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256+    * TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384+* For TLS 1.3, use one of these ciphersuites:+    * TLS_AES_256_GCM_SHA384+    * TLS_AES_128_GCM_SHA256

I kept the proposal to the NIST standardized crypto algs, but we can add the CHACHA20_POLY1305.

christianpaquin

comment created time in 7 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentsmart-on-fhir/health-cards-dev-tools

Executable CLI + Refreshed Docs

Sorry for the delay here; we had some urgent work last week. We'll split this PR in two, one to address the bin install, and one to reorg the README.

jrasm91

comment created time in 9 days

issue openedthe-commons-project/vci-directory

Update Validation SDK name and URL

The Health Cards Validation SDK was renamed to Health Cards Dev Tools, so point 4 of the VCI agreement should now read:

SHCs issued by Issuer have gone through a quality assurance process to ensure correctness in addition to the validation using the developer tools, available at https://github.com/smart-on-fhir/health-cards-dev-tools and as a portal at https://demo-portals.smarthealth.cards/VerifierPortal.html.

created time in 14 days

fork christianpaquin/vci-directory

[WIP] Holds membership information for SHC issuers that are part of the VCI (https://vci.org/) Directory.

fork in 14 days

PR opened smart-on-fhir/health-cards

Updated URL to renamed dev tool project.

Updated "Validation SDK"'s name and URL to "Dev Tools"

+1 -1

0 comment

1 changed file

pr created time in 14 days

create barnchchristianpaquin/health-cards

branch : update-dev-tool-url

created branch time in 14 days

PullRequestReviewEvent

Pull request review commentsmart-on-fhir/health-cards

Adds TLS requirements for issuer keyset

 # Changelog -## 1.0.2 +## 1.0.3

It will probably be hard for SHC apps and validation tools to check this, because the TLS details are typically handled by libraries that don't offer visibility of these details.

christianpaquin

comment created time in 14 days

Pull request review commentsmart-on-fhir/health-cards

Adds TLS requirements for issuer keyset

 If the issuer has more than one certificate for the same public key (e.g. partic  Issuers SHALL publish their public keys as JSON Web Key Sets (see [RFC7517](https://tools.ietf.org/html/rfc7517#section-5)), available at `<<iss value from JWS>>` + `/.well-known/jwks.json`, with [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin) enabled. -The URL at `<<iss value from JWS>>` SHALL use the `https` scheme and SHALL NOT include a trailing `/`. For example, `https://smarthealth.cards/examples/issuer` is a valid `iss` value (`https://smarthealth.cards/examples/issuer/` is **not**).+The URL at `<<iss value from JWS>>` SHALL use the `https` scheme, and SHALL use the following TLS version 1.2 or 1.3 configurations:+* For TLS 1.2, use a ciphersuite conforming to the following algorithm choices and _minimum_ cryptographic strength:

Given this is a new spec leading to (presumably) new implementations, enforcing a secure min bar makes sense to me. Should be ok for servers, even if keys are hosted by legacy systems. Clients (wallets and newly created apps) should also support this min bar. Bottom line: which legacy components that can't meet these recommendations are we trying to support?

christianpaquin

comment created time in 14 days

PullRequestReviewEvent

pull request commentsmart-on-fhir/health-cards

Adds TLS requirements for issuer keyset

It seems we have a decision to make: enforce a MUST support (server must offer the min bar config, but client can ask for less secure options) vs. MUST use (server only offers the min bar config). If we opt for the former, we can adapt the language per @jmandel's comment (or refer to an external document with similar recommendation, per @lcmaas's comment). Comments? Should this be discussed on a call?

christianpaquin

comment created time in 14 days