Stream: Security and Privacy
Topic: JSON Signature rules question
Eric Haas (Feb 09 2022 at 02:30):
Is this a cut and paste error? I cannot find any reference to "CommitmentTypeIndication" element in JWS. I suspect it is an xml thing.
(http://hl7.org/fhir/datatypes.html#JSON)
Eric Haas (Feb 09 2022 at 02:33):
Should it be instead the "KeyUsage" ? (these do not match CommitmentTypeIndication values )
Lloyd McKenzie (Feb 09 2022 at 02:42):
@John Moehrke
John Moehrke (Feb 09 2022 at 13:12):
I agree that there is no CommittmentTypeIndication in JWS... so what is the element name in JWS that indicates "What is the meaning of this signature"? And would be the indication that this is a author-signature, this is a counter-signature, this is a co-signature, etc?
John Moehrke (Feb 09 2022 at 13:13):
This 'mistake' is indeed a copy from XML-Signature where this is clear... it is sitting here waiting for someone to notice and file a CR... good evidence that no one uses digital-signatures.
Josh Mandel (Feb 09 2022 at 15:20):
Good evidence that nobody is using FHIR's Signature datatype. (I'm saying something that's so obvious to you John it's not worth mentioning, but for others reading along here... of course digital signatures are widely used with FHIR, including in projects like https://spec.smarthealth.cards)
John Moehrke (Feb 09 2022 at 19:00):
so then... has that project provided CR improvement opportunities for the Signature datatype and background?
John Moehrke (Feb 09 2022 at 19:00):
such as... where does the purpose of the signature go?
Josh Mandel (Feb 09 2022 at 19:00):
I did submit several change requests for loosening the data requirements on provenance and signature.
Josh Mandel (Feb 09 2022 at 19:01):
In the contact of that work, the purpose of the signature is not explicitly modeled; it is external context known to participants in exchange
John Moehrke (Feb 09 2022 at 19:01):
if it is understood.. then what is the use of the signature
John Moehrke (Feb 09 2022 at 19:01):
just kidding.
John Moehrke (Feb 09 2022 at 19:01):
but a signature purpose is an important element of a digital signature.
John Moehrke (Feb 09 2022 at 19:02):
overall... yes, i am fishing for feedback. yes Josh did provide some feedback already.
John Moehrke (Feb 09 2022 at 19:10):
that said... the XML-Siganture profiling is based on XaDES.. There is now a JaDES for json digital signatures. I have not looked deeply at it (mostly no spare time). It should give us the same kind of profiling as we used for XML-Signature -- https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf
John Moehrke (Feb 09 2022 at 19:11):
page 55
John Moehrke (Feb 09 2022 at 19:11):
shows that the JAdES equivialnt of the XAdES CommitmentTypeIndication is ..... "srCms"
John Moehrke (Feb 09 2022 at 19:15):
I logged https://jira.hl7.org/browse/FHIR-36000
John Moehrke (Feb 09 2022 at 19:16):
would appreciate feedback on a use of JAdES.. It would not be mandated, just recommended... much like the xml-signature recommends XAdES. These are profiles of the raw digital signature standards for use, and these are refered to often in regulations/laws.
Eric Haas (Feb 09 2022 at 20:17):
Josh brought up a lot of good points btw in his Jira tickects, nevertheless here is what we did for CDEX where we do follow the guidance for the FHIR signature data type - I assumed "KeyUsage" is the closest analog to "CommitmentTypeIndication" :
http://build.fhir.org/ig/HL7/davinci-ecdx/signatures.html
Eric Haas (Feb 09 2022 at 20:18):
We did not look at JAdES
Josh Mandel (Feb 09 2022 at 20:31):
Do you have a reference implementation of this scheme? I'm not seeing the implementation of canonicalization in the example at https://github.com/HL7/davinci-ecdx/blob/master/CDEX-Signatures/Digsig_Searchset_Bundle_Example.ipynb
Josh Mandel (Feb 09 2022 at 20:32):
canonical_bundle = dumps(search_bundle, sort_keys=True,separators=(',', ':'))
I don't think that's going be compatible with the FHIR requirements
Josh Mandel (Feb 09 2022 at 20:33):
(I'm only being difficult here because I don't know that the FHI requirements have ever been fully implemented, and I'm concerned that they are a significant risk here. Using attached signatures avoids this risk, or using a well standardized canonicalization algorithm like the IETF JSON canonical spec defines would be another way to mitigate that risk)
Eric Haas (Feb 10 2022 at 00:13):
I don't know that the FHI requirements have ever been fully implemented, and I'm concerned that they are a significant risk here.
I agree and that is why when I could not find any prior example (except for Healths Cards) , I set out to walk through and document it step by step.
For a simple example the Python json dumps module gets the job done based upon what is documented for FHIR . That does not mean it would work for narratives and complex markdown fields. I agree that canonicalization is tricky subject and it is not fully fleshed out in CDEX. but then again the base definition is no better IMO.
What do you mean by a reference implementation of this scheme? (besides the Jupyter file .... no)
Eric Haas (Feb 10 2022 at 00:15):
I could go back and use a json canonicalization module instead.
The RFC8785 points to : https://github.com/cyberphone/json-canonicalization/tree/master/python3
Eric Haas (Feb 10 2022 at 00:21):
I am not sure if it is compatible with what is documented in FHIR, but are you suggesting CDEX promote ETF JSON canonical spec (RFC 8785)? which I am reading now. Would this be a FHIR tracker too?
Josh Mandel (Feb 10 2022 at 01:37):
Seems reasonable to capture this question in a tracker; just want to avoid our publishing an IG requiring an approach that has never been tested. Better to leave the details out than to include wrong details in our list of requirements
Eric Haas (Feb 10 2022 at 02:31):
In the proverbial cart before the horse scenario. DaVinci project has CDEX RI and there are plans in the works to implement signatures.
Eric Haas (Feb 10 2022 at 02:35):
I created examples using the methods outlined so proof of concept and not entirely made up out of whole cloth.
Eric Haas (Feb 10 2022 at 02:36):
IF you don't think that it should be published as STU then can bring it up on cdex call or when we trot it out to FMG.
Josh Mandel (Feb 10 2022 at 03:12):
Unlikely I'll have bandwidth to engage proactively on CDEX specs, but don't hesitate to ping me with any questions.
John Moehrke (Feb 10 2022 at 14:07):
I am not at all understanding the concern about putting untested things into an IG. That is the whole purpose of an IG, to transition thru STU phase. I encourage this. I just ask that the 'lessons learned' be brought back to the specification for improvement... Much like ALL THE OTHER lessons learned about FHIR.
Josh Mandel (Feb 10 2022 at 15:37):
I'd recommend documenting the things that have been tested, and documenting uncertainty about things that haven't. And giving leeway for implementers to still be "compliant" if they only support the stuff that is known to work well. This is particularly critical for IGs aspiring to regulatory adoption, which I believe is the case for the work Eric is pointing out.
John Moehrke (Feb 10 2022 at 15:40):
we have a confluence page linked to the signature datatype for this purpose. Please do so.
John Moehrke (Feb 10 2022 at 15:40):
https://hl7.org/fhir/signatures.html
John Moehrke (Feb 10 2022 at 15:41):
https://confluence.hl7.org/display/FHIR/Digital+Signatures
Eric Haas (Feb 28 2022 at 17:14):
I have specified and documented the canonicalization. We going to publish CDEX with this as Draft and reballot in May.
Last updated: Apr 12 2022 at 19:14 UTC
