profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/lcmaas/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.

HL7/fhir-udap-security-ig 1

IG repository for UDAP Security for Registration, Authentication, and Authorization IG.

lcmaas/openemr 1

Mirror of official OpenEMR Sourceforge repository

lcmaas/fhir-udap-security-ig 0

IG repository for UDAP Security for Registration, Authentication, and Authorization IG.

lcmaas/health-cards 0

Health Cards Framework: implementation guide and supporting material

lcmaas/JIRA-Spec-Artifacts 0

Manages the artifacts, pages and other lists associated with all HL7 projects managed through JIRA feedback projects

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.

reword? The way the last phrase of the proposed change is worded suggests that this spec intends to dictate what 'major' web browsers shall or shall not do; also there is likely disagreement on what defines a 'major' browser, so that is not really enforceable/testable.

christianpaquin

comment created time in 8 days

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, 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

chacha is not a fips 140-2 approved algorithm so it would likely be a problem for federal entities to require support

christianpaquin

comment created time in 8 days

PullRequestReviewEvent

pull request commentsmart-on-fhir/health-cards

Adds TLS requirements for issuer keyset

Hi, have we fully considered referring to the best practice documents for TLS that are managed by IETF instead? (BCP 11 and 195); perhaps recommending following these best practices is a good start as this is a nuanced topic to get right, and these docs get updated as deficiencies/vulnerabilities of different cryptographic algorithms are identified. I think this might generally be simpler (and more secure) than trying to list out specific ciphersuites in this guide. To @isaacvetter 's point, I would note that BCP 11 addresses both client and server considerations.

I will add, however, that using TLS to protect the distribution of an issuer's naked public keys (naked=not in an X.509 certificate) introduces additional security considerations: the strength of the keys and ciphersuites used to protect the TLS connection really need to be at least as strong as the key material being protected, because the TLS connection is being repurposed as a mechanism to securely bind the public key to the identity of the issuer (or in this case to the DNS domain of the issuer). For examples, using a P-256 EC based key agreement protocol or AES-128 encryption for the TLS connection decreases the effective strength of a P-384 key.

I would also note that the TLS connection issues would not be relevant if every JWKS returned included an X509 cert for each public key, because the CA signature on an X.509 cert is already at least as strong as the public key in the cert (for any competent CA) and therefore the keys/certs can actually be safely distributed without TLS at all (because the certificates can be independently validated by the party receiving them). This is commonplace in PKIX communities and also avoids circular trust boot-strapping issues. Unfortunately, as verifier support for certificate based trust of issuer keys is currently optional in the spec, we are probably stuck with explaining that properly configuring and enforcing TLS parameters is critical when either the issuer or verifier relies on TLS to bind public keys to an issuer identity.

christianpaquin

comment created time in 16 days

issue commentsmart-on-fhir/health-cards

Incorrect JWS signature

For a HC, the compressed data is the JWS Payload, and the signature should be computed as per the RFC section you referenced. Take a look at issue #128 for further discussion; hopefully that will clarify.

pradeepBoston

comment created time in a month

issue commentsmart-on-fhir/health-cards

CA for wellknown URL

The current trust model (list of issuers published by vci) was designed as a bootstrap model for rapid deployment and proof of concept; it is expected that this simple file-based trust model will be replaced or at least supplemented by PKI based models commonly used for health information networks as the number of issuers increases.

There are healthcare industry specific CAs that can provide certificates with URI SANs, e.g. EMR Direct.

pradeepBoston

comment created time in a month

push eventHL7/fhir-udap-security-ig

lcmaas

commit sha 17555dc802399a40026821045c589d69b9694456

update current version and date for ballot

view details

push time in a month

push eventHL7/fhir-udap-security-ig

lcmaas

commit sha 17555dc802399a40026821045c589d69b9694456

update current version and date for ballot

view details

push time in a month

push eventHL7/fhir-udap-security-ig

lcmaas

commit sha 7e8f1735ace252475de1d5e46f1c77cbf06394a7

update current and date for ballot

view details

push time in a month

push eventHL7/fhir-udap-security-ig

push time in a month

push eventHL7/fhir-udap-security-ig

lcmaas

commit sha e1bafc4f10e15235d3c721827fe9478e5fec6e14

update current version and date for ballot

view details

push time in a month

push eventHL7/fhir-udap-security-ig

push time in a month

push eventHL7/fhir-udap-security-ig

lcmaas

commit sha 1854f83384ae3c991775c227a3e67025242c18ce

add version to ig.ini

view details

push time in a month

push eventHL7/fhir-udap-security-ig

lcmaas

commit sha bf9fc2ab865fa5f66c17ce78a7c5868ad935a9ae

add comment regarding branch names

view details

lcmaas

commit sha 672f088f35531c38e65d8ef6e06714424684d57b

update version number for Sep 2021 ballot

view details

lcmaas

commit sha dc8d282db5a0b878678b35eef26ec4f35e684f8b

update version num and current ver for balloting

view details

lcmaas

commit sha 498f94fc543904e139e803b659fd64fd45d9586d

update releaseLabel for ballot

view details

lcmaas

commit sha da6e4ea8c53464b0c864c3f3b0560634b0d132ac

update version number for ballot

view details

lcmaas

commit sha 3201d51170d05b8dc1e7ac95d60e75117dd7f8c9

Merge pull request #6 from lcmaas/patch-4 version number updates for Sep 2021 ballot

view details

push time in a month

PR opened HL7/JIRA-Spec-Artifacts

update udap IG version num for ballot

changed STU1 ballot version to 0.1.0 per Lynn

+3 -2

0 comment

1 changed file

pr created time in a month

create barnchlcmaas/JIRA-Spec-Artifacts

branch : udap-patch-1

created branch time in a month

create barnchlcmaas/JIRA-Spec-Artifacts

branch : lcmaas-patch-2

created branch time in 2 months

fork lcmaas/JIRA-Spec-Artifacts

Manages the artifacts, pages and other lists associated with all HL7 projects managed through JIRA feedback projects

fork in 2 months

push eventHL7/fhir-udap-security-ig

lcmaas

commit sha bf9fc2ab865fa5f66c17ce78a7c5868ad935a9ae

add comment regarding branch names

view details

lcmaas

commit sha 672f088f35531c38e65d8ef6e06714424684d57b

update version number for Sep 2021 ballot

view details

lcmaas

commit sha dc8d282db5a0b878678b35eef26ec4f35e684f8b

update version num and current ver for balloting

view details

lcmaas

commit sha 498f94fc543904e139e803b659fd64fd45d9586d

update releaseLabel for ballot

view details

lcmaas

commit sha da6e4ea8c53464b0c864c3f3b0560634b0d132ac

update version number for ballot

view details

lcmaas

commit sha 3201d51170d05b8dc1e7ac95d60e75117dd7f8c9

Merge pull request #6 from lcmaas/patch-4 version number updates for Sep 2021 ballot

view details

push time in 2 months

push eventlcmaas/fhir-udap-security-ig

lcmaas

commit sha da6e4ea8c53464b0c864c3f3b0560634b0d132ac

update version number for ballot

view details

push time in 2 months

push eventlcmaas/fhir-udap-security-ig

lcmaas

commit sha 498f94fc543904e139e803b659fd64fd45d9586d

update releaseLabel for ballot

view details

push time in 2 months

push eventlcmaas/fhir-udap-security-ig

lcmaas

commit sha dc8d282db5a0b878678b35eef26ec4f35e684f8b

update version num and current ver for balloting

view details

push time in 2 months

push eventlcmaas/fhir-udap-security-ig

lcmaas

commit sha 672f088f35531c38e65d8ef6e06714424684d57b

update version number for Sep 2021 ballot

view details

push time in 2 months

create barnchlcmaas/fhir-udap-security-ig

branch : patch-4

created branch time in 2 months

delete branch lcmaas/fhir-udap-security-ig

delete branch : lcmaas-patch-4

delete time in 2 months

create barnchlcmaas/fhir-udap-security-ig

branch : lcmaas-patch-4

created branch time in 2 months