FHIR Chat · Bundle.signature · Security and Privacy

@John Moehrke I read your blog and the ihe spec and am still confused how to apply it Bundle.signature. It sounds like a digitally signed jws will have copy of the bundle minus the signature embedded right in the bundle. Am I correct? Am I missing something ?

John Moehrke (Sep 24 2021 at 20:46):

you do not apply it to Bundle.signature. It is a totally different DocumentReference that points at the signature "document", and that has a relationship to the DocumentReference that points at the FHIR-Document. The FHIR-Document does not have a Bundle.signature element..... This is the strength of this method. Given that it is a WHOLE signature, there is no blindspots. When you have an element inside the signed thing, like Bundle.signature, you must use stylesheets to exclude the bundle.signature element from the signature, thus ANY CHANGE TO THE Bundle.signature in the future are NOT detectable. This includes stuffing in extensions.

Eric Haas (Sep 24 2021 at 20:52):

So the docref is exchanged ?

Eric Haas (Sep 24 2021 at 20:54):

As in I want x (ccd,resource, FHIR document,etc) and the response is a docref?

Eric Haas (Sep 24 2021 at 20:57):

Which points to a JWS which wraps the thing you want?

John Moehrke (Sep 27 2021 at 11:54):

You are searching for clinical documents, searching on DocumentReference for some use-case. You end up with a clinical document, that you are wondering about signatures. At this point you have the clinical document DocumentReference.id. So you then search for DocumentReference with a .relatesTo.target equal to that id (and a .relatesTo.code of signs). Now you have the signature document of the clinical document. The signature document is nothing but the signature, which in the cryptographically protected signature blob is also the indicators of the document, who signed, why they signed, when they signed, method of signature, etc). Two different documentReference, but related. The lifecycle of the clinical document is independent of the lifecycle of the signature. The clinical document will exist well before it is signed. The signature does not change the clinical document. Anyone not caring about the signature just uses the clinical document and is not bothered by the overhead of any signature (which is 99.999% of all uses of data, no one cares to confirm a signature, it is there when some legal action happens.)

Eric Haas (Sep 27 2021 at 18:20):

Why not just exchange the signed thing

Eric Haas (Sep 27 2021 at 18:21):

Let the receiver use the document as they want? With the understanding It is no longer attested by the signer when they do?

John Moehrke (Sep 27 2021 at 19:02):

in a push case, you might choose to push the signature too... sure.

John Moehrke (Sep 27 2021 at 19:26):

in a REST, those that need the signature can find it. most don't need to be bothered with it.

Eric Haas (Sep 28 2021 at 01:27):

I appreciate your input , but I don't understand what you mean exactly by "in a REST, those that need the signature can find it. most don't need to be bothered with it.". In CDEX we have a use case for 'signatures required" and you commented on it here...

https://confluence.hl7.org/display/DVP/Signature+Option+per+Use+Case

We assume the digital Sig is needed and are proposing using a FHIR document bundle or search bundle with the signature element. We will need to document how to do this. Thing is, after digging into it, I was unable to even start to describe how the technical pieces work based on what we decided for CDEX for the new stuff. Namely the similar questions to those Josh asked on the other stream. For example Here are my issues:

the payload for the signature has to be the bundle without the signature element
the signature payload ("copy1") is a purportedly a copy of the bundle ("copy2") without the signature element... so now we have two copies exchanged over the wire
Upon receipt you would have to check if copy1 and copy2 are the same?
1. What if copy1 and copy2 are not the same? do you use copy1?

Lloyd McKenzie (Sep 28 2021 at 01:32):

To sign the document, you run the document through the canonicalization algorithm and calculate the signature, then affix the signature to the Bundle. The recipient receives one Bundle. They remove the signature (in memory), run the canonicalization algorithm and check the result against the provided signature. There are no copies exchanged or persisted, just a temporary copy made in memory to strip the signature and run the canonicalization process.

Eric Haas (Sep 28 2021 at 01:32):

If I understand it correclty, I think the envelope solution you mentioned avoids these issues so if you get around to suing or being sued it seems this would be clear what was exchanged. I'm sure there are other tradeoffs.

Eric Haas (Sep 28 2021 at 01:45):

Element Id Bundle.signature
Definition
Digital Signature - base64 encoded. XML-DSig or a JWT.

A signed JWT is composed of three elements: the header, the payload, and the signature

I understand the payload to be "the canonicalized bundle" which is essential the official the copy of the bundle being exchanged.

Lloyd McKenzie (Sep 28 2021 at 01:46):

Usually you would sign a hash of the payload, not the whole payload. There's zero reason to re-transmit the whole thing...

Eric Haas (Sep 28 2021 at 01:46):

and as an aside apart from the fhir specification, I have been unable to locate any guidance on how exactly this is done or examples

Eric Haas (Sep 28 2021 at 01:50):

aha...a hash makes more sense... I still like John's envelope solution

Eric Haas (Sep 28 2021 at 01:56):

... what we have proposed and what Josh is proposing for resources are disparate solutions for similar if not the same problem.

Lloyd McKenzie (Sep 28 2021 at 02:01):

A Bundle is and envelope. We don't want to create any more layers than are strictly necessary. We want to transmit the data that would normally be transmitted. Many systems will totally ignore the signature, so the mode of transmission can't be changed by whether or not a signature happens to be affixed.

Eric Haas (Sep 28 2021 at 02:12):

I understand those tradeoffs but we are already proposing a lot of other tradeoffs too. Besides we agreed that the default is unsigned data and signature is upon request so the requester would be prepared for it. right?

Lloyd McKenzie (Sep 28 2021 at 02:57):

For the signed documents, yes. For the query responses, no - though there might be pre-negotiation. Also, for query responses, there's no option other than to return a regular query response - returning anything else would be non-conformant. There's zero reason to have an extra wrapper layer here.

Eric Haas (Sep 28 2021 at 03:38):

other options discussed

contained Provenance/resource
meta.security/resource
http signature header/transaction

Josh Mandel (Sep 28 2021 at 12:54):

For JWS, keep in mind that a payload can be attached or detached @Eric Haas

Lloyd McKenzie (Sep 28 2021 at 14:32):

It's a Bundle - either a searchset or a document. Bundle has Bundle.signature. That's what it's for. I don't understand why we'd be looking for alternatives?

Eric Haas (Sep 28 2021 at 16:13):

The existing Bundle.signature element and datatype has some significant issues that Josh has pointed out ... Maybe I am paranoid, but those who implement the spec are going to be faced these same issues and ask similar questions so is best to anticipate them.
We are creating bundles for the purpose of adding signatures. I think we need to justify this approach and consider the alternatives.

John Moehrke (Sep 28 2021 at 17:04):

there is much mixing solutions in this thread. It seems Lloyd wants to not discuss anything except Bundle.signature. so, Lloyd is fully correct in how that works. But, that leaves room for malicious insertion in the Bundle.signature element, in addition to anywhere else that the canonicalization has excluded.

John Moehrke (Sep 28 2021 at 17:06):

As to Search Sets... are we talking about synchronous return of a search set from a http GET/POST search request? If so, then what is wrong with the authenticity and integrity protection that the TLS provides? It is a form of signature, by the server, for the purpose of communicating results, at that instant in time.

John Moehrke (Sep 28 2021 at 17:07):

or are we talking about Search Sets as persisted Bundles? -- aka a document (note lowercase 'd', not to be confused with HL7 definition of a Document)... but certainly within the scope of documentReference resource.

John Moehrke (Sep 28 2021 at 17:08):

With Lloyds focus on Bundle.security... is this signature going to include both encodings? That is a signature for the FHIR xml encoding, and a signature for the FHIR json encoding? Is that signature going to be in JWS form, XML-Signature form, or something else?... or is it going to be ALL of the above, just to be sure.

John Moehrke (Sep 28 2021 at 17:14):

note, that last question applies to all forms of signature, not specific to Lloyds focus on Bundle.signature

Lloyd McKenzie (Sep 28 2021 at 17:24):

Insertion of elements in the Bundle.signature element that aren't signed doesn't much matter. We can just highlight the issue and indicate that they SHALL be ignored if a digital signature is present. Alternatively, we could define a canonicalization that signs everything except the Signature.data

The requirement for search-set signatures is the need to be able to persist the search-set with a non-repudiatable proof that might not come into play for years. TLS allows you to verify that something hasn't changed in transit, but doesn't give you a token that you can use years later to prove what came over the wire. We don't know (or care) how the receiving system stores the search-set Bundle, only that they receive it as a regular search set. There's zero expectation that the stored search set will be available for subsequent query. It'll only see the light of day if lawyers need to be involved.

Da Vinci is talking about standardizing on JSON, but until they do so, presumably we'd need to support both forms of signature - and a system that requests the data in a syntax other than was used would need to convert it before canonicalizing and verifying the signature. That's a decision we'll need to land on as a project.

John Moehrke (Sep 28 2021 at 17:32):

the search-set signature sounds like a recipient responsibility. It will be received as protected by TLS, it is up to local requirements to further protect it. One method might be to have an import Provenance created that cover it. Would seem the interoperability requirement is satisfied by TLS.

John Moehrke (Sep 28 2021 at 17:33):

Yes, one mitigation for the risk of insertions is to REQUIRE everyone, regardless of if they care about signatures, to ignore/blank the Bundle.signature element. Anyone not explicitly ignoring it, could be duped into using data they "presume" is authentic.

Eric Haas (Oct 02 2021 at 04:40):

The JSON Signature rules specified in the FHIR specification has this bullet which I don't understand:

The Signature SHALL include a "CommitmentTypeIndication" element for the Purpose(s) of Signature. The Purpose can be the action being attested to, or the role associated with the signature. The value shall come from ASTM E1762-95(2013). The Signature.type shall contain the same values as the CommitmentTypeIndication element.

does it mean there is a CommitmentTypeIndication" element for the Purpose(s) of Signature in the JWS itself? if so where would that go?

Eric Haas (Oct 02 2021 at 04:41):

should is say the FHIR Signature element SHALL ... ?

John Moehrke (Oct 02 2021 at 12:44):

it was aspirational that someone would define this element in terms of JWS. Since that time there is now a a ETSI standard for long term JSON signature, a profile on JWS - https://www.sciencedirect.com/science/article/abs/pii/S0920548919300960

John Moehrke (Oct 02 2021 at 12:45):

https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf

John Moehrke (Oct 02 2021 at 12:49):

that defines the purpose of signature is within a JAdES tag "srCms"

John Moehrke (Oct 02 2021 at 12:50):

so this specification is the JSON signature equivalent of the XaDES that we specify for XML-Signature. These ETSI specifications are Implementation Guides for specific use-cases of digital signature. In EU and Asia they are required by regulation.

John Moehrke (Oct 02 2021 at 12:53):

Would like to have someone review this specification for applicability to FHIR Signature. Better to use standards developed by experts, than to invent them. Especially when those experts are experts in digital signatures, and we are not. -- but, I have not had time to fully review this JAdES specification (it was just published in March 2021).

Last updated: Apr 12 2022 at 19:14 UTC

Main menu