This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "FHIR Digital Signature Working Page"

From HL7Wiki
Jump to navigation Jump to search
Line 2: Line 2:
  
 
This topic is formally around coming to a resolution for Change Proposal tracker [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3746&start=0 3746]
 
This topic is formally around coming to a resolution for Change Proposal tracker [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3746&start=0 3746]
 
Advice is needed for how to create a Provenance.signature and how to validate one so that the signature survives various movements. Or do we just indicate that signatures are not intended to survive movements?
 
  
 
=Specifically troubling=
 
=Specifically troubling=
Line 9: Line 7:
 
Many of the problems identified are exactly the kind of 'problem' that a Digital Signature is intended to protect against. That is, the purpose of a Digital Signature is to verify that the content has not changed. Determining which kinds of changes are allowed is 'policy', meaning a decision that element XYZ is allowed to change and not break the signature is declaring a policy that XYZ element is not important. However to enable broad interoperability some decisions need to be made.
 
Many of the problems identified are exactly the kind of 'problem' that a Digital Signature is intended to protect against. That is, the purpose of a Digital Signature is to verify that the content has not changed. Determining which kinds of changes are allowed is 'policy', meaning a decision that element XYZ is allowed to change and not break the signature is declaring a policy that XYZ element is not important. However to enable broad interoperability some decisions need to be made.
  
 +
* Advice is needed for how to create a Provenance.signature and how to validate one so that the signature survives various movements. Or do we just indicate that signatures are not intended to survive movements?
 
* How are signatures to be handled by a receiving system that imports the resource for use? That is it incorporates the resource content, and likely fixes up the References to local copies of the resource?
 
* How are signatures to be handled by a receiving system that imports the resource for use? That is it incorporates the resource content, and likely fixes up the References to local copies of the resource?
 
** Should a counter-signature be used? That is the importing system will validate the incoming signature, and then counter sign the fixed-up resource, which should be a new version with a new Provenance.
 
** Should a counter-signature be used? That is the importing system will validate the incoming signature, and then counter sign the fixed-up resource, which should be a new version with a new Provenance.

Revision as of 14:04, 16 December 2014

This page documents a series of proposals arising out of the digital signature implementation project

This topic is formally around coming to a resolution for Change Proposal tracker 3746

Specifically troubling

Many of the problems identified are exactly the kind of 'problem' that a Digital Signature is intended to protect against. That is, the purpose of a Digital Signature is to verify that the content has not changed. Determining which kinds of changes are allowed is 'policy', meaning a decision that element XYZ is allowed to change and not break the signature is declaring a policy that XYZ element is not important. However to enable broad interoperability some decisions need to be made.

  • Advice is needed for how to create a Provenance.signature and how to validate one so that the signature survives various movements. Or do we just indicate that signatures are not intended to survive movements?
  • How are signatures to be handled by a receiving system that imports the resource for use? That is it incorporates the resource content, and likely fixes up the References to local copies of the resource?
    • Should a counter-signature be used? That is the importing system will validate the incoming signature, and then counter sign the fixed-up resource, which should be a new version with a new Provenance.
  • How to handle when References are included in the resource being signed?
    • Do they get turned into relative URLs?
      • If a system imports the resource and 'fixes up' the References to point at local copies of the referenced resource, then the signatures will fail to validate
    • Do they get turned into just the unique part, without the URL root?
    • Do they get turned into _id?
    • Do they get nulled?
    • How are versioned Referenced resources identified?
    • Do you serialize the Referenced resource along with the resource? If so how deep?
  • How to handle metadata?
    • Which metadata is included in the signature? Which is not?
  • How are signatures to be handled when the resource server gets re-located, changing the URL root?

Signature Need

The discussions to date in Security, CBCC, FM etc. can be boiled down to the need for 2 types of signatures:

integrity Signatures: Purpose to determine if content altered through a defined period (e.g. in transit). This signature is allowed to break if the resource is moved, or updated. Operation sign over all content in the resource. Should be able to apply to a bundle.

documentation Signature: Purpose to determine if content altered over time regardless of movement, should not break if moved. Operation: sign over immutable portions of current resource, and follow references in the order encountered and include either: if the referred to resource has a documentation signature include the documentation signature string if any (more efficient than harvesting the Signed-hash from the string) and do not follow references for this resource; if the referred to resource does not then include the immutable elements from the referred to resource and follow the references for this resource applying this same logic as you go. This means there needs to be a specific signature transform canonicalization that isolates the portions needing signature while allowing others to change.

Document Signature: This is not 'needed' as it is already available and not a FHIR specific capability, let me explain. This is a signature across a whole Document that is managed as a whole document. This may be a FHIR document or other. Given that this document is managed as a whole document, then Document centric signatures already can be applied. See IHE-Document Digital Signature (DSG) profile for a profile of XAdES-X-L. The resulting signature is either Encapsulating the signed document, or is another document that must be managed in relationship (See DocumentReference).


Some proposals

Provenance Signature - clarification

The current text was carefully crafted, but clearly we need to clean up the signature definition in Provenance. This signature was only intended to bind the specific versioned content to the provenance that describes the 'provenance' of that versioned content. Therefore it should be a more simple flavor of a digital signature. However it does still suffer from many of the issues.

Proposal 1 : A page for digital signature implementation notes

We should add a digital signature page that:

  • describes the use cases that we support
  • details general implementation considerations & where to look for support
  • describes a profile on xml digital signatures
  • describes some FHIR specific transforms that when used with FHIR resources confer robustness against format changes, and meet the use cases
  • deals with xml vs json

Proposal 2

We should add a note to both the xml and json pages describing signature ready xml and json. Implementers are recommended to conform to this

XML ready for Digital Signature

  • default namespaces - only use default namespaces for fhir and xhtml namespaces
  • outside the xhtml, no whitespace except in attributes
  • no processing instructions, no xml comment

JSON ready for digital Signature

  • all unimportant whitespace removed from the JSON representation

XML/JSON that conforms to this profile can be reproduced exactly from the data in the resource, without needing to store the actual XML (or can be recreated correctly from the JSON)

Proposal 3

That we define a standard transform