IHE ITI TF Vol3

5.5Document Digital Signature (DSG) XML Signature

Document Digital Signature content shall conform to XAdES schema for signatures, with extensions and restrictions defined in the following. IHE is not changing any optionality, prohibiting use of options, or mandating options. Issues such as long-term archival management of certificates are out of scope of this profile.

5.5.1 References

5.5.1.1 Normative References

[XAdES] XML Advanced Electronic Signatures XAdES http://www.w3.org/TR/XAdES/ -- aka. ETSI TS 101 903

[W3C XMLDSIG] XML-Signature Syntax and Processing. W3C Recommendation. Donald Eastlake. June 2008. https://www.w3.org/TR/xmldsig-core/

5.5.1.2 Informative References

[ISO14533-2] ISO 14533-2:2012 - Process, data elements and documents in commerce, industry and administration - Long term signature profiles - Part 2: Long term signature profiles for XML Advanced Electronic Signatures (XAdES)

[ETSI TS 119 172-1] ETSI Technical Specifications 119 172-1 v1.1.1, Electronic Signatures and Infrastructures (ESI); Signature Policies; Part 1: Building blocks and table of contents for human readable signature policy documents; Annex B: Commitment types. https://www.etsi.org/deliver/etsi_ts/119100_119199/11917201/01.01.01_60/ts_11917201v010101p.pdf

[ETSI TS 101 903] ETSI Technical Specifications 101 903, XML Advanced Electronic Signatures, Section 7.2.6, The CommitmentTypeIdentificationElement. http://uri.etsi.org/01903/v1.1.1/ts_101903v010101p.pdf

[ETSI TS 101 733] ETSI Technical Specifications, commitment-type-indication Attribute 101 733, Electronic Signature and Infrastructures (ESI); CMS Advanced Electronic Signature (CAdES). https://www.etsi.org/deliver/etsi_ts/101700_101799/101733/02.02.01_60/ts_101733v020201p.pdf

[ASTM-E1762-05] ASTM E1762-95(2013) - Standard Guide for the Authentication of Health Care Information

5.5.2 Signature Specification

The following constraints define the Digital Signature block. This block is common to the detached signature and Enveloping signature.

Shall conform to XAdES-X-L - for support of Long Term signatures. The XAdES-X-L specification adds the timestamp of the signing and inclusion of the certificate and statement of revocation.
Shall implement the hash algorithm sha256 and RSA signature algorithm for the purpose of interoperability testing. However, implementors SHOULD take into account additional considerations such as jurisdictional policies, quantum safe computing, and evolving guidance from XAdES. https://www.w3.org/2001/04/xmlenc#sha256 https://www.w3.org/2001/04/xmldsig-more#rsa-sha256
Shall use the canonicalization algorithm "Canonical XML 1.1 with Comments" ( http://www.w3.org/2006/12/xml-c14n11#WithComments ) across the XML-Signature.
The policy may be identified as urn:ihe:iti:dsg:detached:2014 when the signature document is a Detached Signature and urn:ihe:iti:dsg:enveloping:2014 when the signature document is an Enveloping Signature to indicate that the signature document complies with the DSG Profile.
Shall include a "CommitmentTypeIndication" element for the Purpose(s) of Signature (aka purposeOfSignature). The Purpose can be the action being attested to, or the role associated with the signature. The value should come from ASTM E1762-95(2013) if applicable. The coding scheme for ASTM is 1.2.840.10065.1.12. The Signature Purposes is available in a FHIR ValueSet and CodeSystem - http://hl7.org/fhir/ValueSet/signature-type

Note that Content Creators and Content Consumers might be capable of being configured to other conformance policies to support local policy. For example, some environments may choose a different XAdES profile, hashing algorithm, policy identifier, or signature purpose vocabulary. Content Creators would thus create Digital Signature blocks that are not conformant to this profile. Content Consumers might validate these Digital Signature blocks, and be capable of configured behavior according to the local policy.

Some regions also require conformance to ISO 17090, which includes additional Certificate issuing, content, and validation rules.

5.5.3 Detached Signature

The Detached Signature utilizes the XML Signature - Reference element (ds:reference) to identify and provide a hash for each document that is signed. This set of Reference elements is considered the manifest. The URI attribute shall be used and hold the document uniqueID. For documents that do not use a URI as the uniqueId, the Affinity Domain should determine an appropriate way to encode the DocumentEntry.uniqueId.

5.5.3.1 SubmissionSet Signature

The SubmissionSet Signature is a variant of the Detached Signature used to digitally sign a complete SubmissionSet. The signature can later be validated to assure that the SubmissionSet is complete and the same as when it was created.

The SubmissionSet Signature shall be a Detached Signature that has Reference elements for:

the SubmissionSet uniqueID with a hash value of "0"
the document uniqueID for each of the documents contained in the SubmissionSet not including the SubmissionSet Signature document

The SubmissionSet Signature creation is informatively described here with the Content Creator grouped with an XDS Document Source and is equally applicable with grouping the Content Creator with the other Document Sharing infrastructure (e.g., XDR, and XDM). The document publication transaction is not specific to the SubmissionSet Signature process or content, and is included here only to show overall workflow.

Informative process for creating a SubmissionSet Signature:

A set (n) of Documents of interest are gathered, or generated to be published
A SubmissionSet is created for the Documents, for example in preparation for using the Provide and Register Document Set-b [ITI-41] transaction or equivalent
A Digital Signature document is created which includes Reference elements of:

The SubmissionSet.uniqueId is included in the manifest, with a zero hash value (the value "0").
All of the (n) documents to be included in the SubmissionSet, other than the signature document, are listed in the manifest with their hash.
The signature document is processed according to Section 5.5.2, and thus signed.

The signature document would be added to the SubmissionSet according to Section 5.5.6. The SubmissionSet may, but is not required, include all the "SIGNS" association defined in Section 5.5.6.4 with associations to all the other documents in the SubmissionSet. The "SIGNS" association is redundant in this case as the SubmissionSet already groups these documents.
The SubmissionSet with the (n) documents and the Digital Signature document is submitted using the Provide and Register Document Set-b [ITI-41] transaction, or equivalent from the other Document Sharing infrastructures.

5.5.4 Enveloping Signature

The Enveloping Signature utilizes the XML Signature - "Include" capability where the full content of the signed document is encoded inside the signature document in the Object element (ds:object).

The signed document shall be base64 encoded, unless some other policy overrides.

The object element Encoding shall be specified (http://www.w3.org/2000/09/xmldsig#base64).

5.5.5 Signature Verification

There are three levels of signature verification:

verifying that the Digital Signature block itself has integrity through verifying the signature across the XML-Signature,
confirming that the signer was authentic, not revoked, and appropriate to the signature purpose,
confirming that the signed Documents of interest are unmodified using the hash algorithm.

The Content Consumer shall verify the Digital Signature block has integrity.

The Content Consumer shall be able to be configured with local policy on PKI trust models, and management that supports the confirmation that the signer was authentic, not revoked, and appropriate to the signature purpose. The Content Consumer shall use this configuration when confirming the validity of the signature.

The Content Consumer shall be able to confirm the validity of the documents that are signed.

Workflow or local policy may direct that all or a subset of the signed documents be validated. There are use cases where only one document within a signed set of documents is all that is called for by the workflow.
Workflow or local policy may direct that all or a subset of the signatures found within a Digital Signature Document be validated. The Digital Signature Document may contain signatures for purposes that are not relevant to the Content Consumer purpose that may not be possible to fully validate. A Content Consumer should silently ignore signatures that are not necessary to the purpose of the Content Consumer. For example, a signature may be from a different organization.
The document may not be accessible to the user, for example authorization denied, so confirmation of valid signed content may be impossible.
If there is a SubmissionSet unique ID included in the manifest, then the Content Consumer shall be able to verify that the submission set reference in the manifest is the one containing the documents which are listed in the manifest and the documents listed in the manifest are the complete list of documents in the submission set on the XDS Registry.

The decision on what degree of verification is needed is determined by the application and use case.

The Content Consumer shall be able to validate content that uses SHA256 as well as SHA1.

5.5.6 Document Sharing Metadata

This section applies when the Content Creator or Content Consumer is utilizing a Document Sharing Profile for transport. This section defines the source for all required Document Sharing attributes and as many optional attributes as makes sense for implementers' applications.

5.5.6.1 Document Sharing - DocumentEntry Metadata

The Signature Document shall have a compliant DocumentEntry with the following constraints:

5.5.6.1.1 XDSDocumentEntry.formatCode

The formatCode shall be urn:ihe:iti:dsg:detached:2014 when the signature document is a Detached Signature and urn:ihe:iti:dsg:enveloping:2014 when the signature document is an Enveloping Signature. The formatCode codeSystem shall be 1.3.6.1.4.1.19376.1.2.3.

5.5.6.1.2 XDSDocumentEntry.classCode

The classCode value will be a value representing the high-level classification of Digital Signature type documents within the XDS Affinity Domain or Community.

5.5.6.1.3 XDSDocumentEntry.typeCode

Where policy does not define a workflow specific typeCode, the following code should be used:

Coding schema = ASTM

Code value = E1762

Code value display name = "Full Document"

5.5.6.1.4 XDSDocumentEntry.author

The author should represent the signer.

5.5.6.1.5 XDSDocumentEntry.eventCodeList

The eventCodeList shall contain the signature Purpose(s) from the Digital Signature block "CommitmentTypeIndication" element.

5.5.6.1.6 XDSDocumentEntry.mimeType

Shall be text/xml

5.5.6.1.7 XDSDocumentEntry.title

Should be the same as the display name for the signature purpose

5.5.6.1.8 XDSDocumentEntry.language

The language of the signature content shall be art as in "artificial".

5.5.6.2 Document Sharing - SubmissionSet Metadata

This document content profile makes no changes to the structure of Submission Sets.

5.5.6.3 Document Sharing - Folder Metadata

This document content profile makes no changes to the structure of Folders.

5.5.6.4 Document Associations

When Detached Signature Option is used, the Content Creator shall use the SIGNS associationType Document Relationship to associate the signature (sourceObject) to the documents that it signs (targetObjects). See Section 4.2.2 Association Types.

When SubmissionSet Signature Option is used, the Content Creator may use the SIGNS associationType Document Relationship to associate the signature (sourceObject) to the documents that it signs (targetObjects). See Section 4.2.2 Association Types.

5.5.7 Security Considerations

See XAdES specification for risk assessment and mitigation plan on Digital Signatures.

5.5.7.1 Content Creator

When a Content Creator is grouped with an ATNA Secure Node or Secure Application, it shall create an Audit Message indicating the Signature Creation event.

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(113031, DCM, "Signed Manifest")
	EventActionCode	M	"C" (Create)
	EventDateTime	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV("urn:ihe:iti:dsg", "IHE Transactions", "Document Digital Signature")
Audit Source (Content Consumer) (1)
ActiveParticipant (User/System that requested Signature Creation) (0..n)
ActiveParticipant (Patient indicated in the Signature Document) (0..n)
ParticipantObjectIdentification (Digital Signature Document) (1)

5.5.7.2 Content Consumer

When a Content Consumer is grouped with an ATNA Secure Node or Secure Application, it shall create an Audit Message indicating the Signature Verification event.

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(110007, DCM, "Report Verification")
	EventActionCode	M	"R" (Read)
	EventDateTime	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV("urn:ihe:iti:dsg", "IHE Transactions", "Document Digital Signature")
Audit Source (Content Consumer) (1)
ActiveParticipant (User/System that requested Signature Validation) (0..n)
ActiveParticipant (Patient indicated in the Signature Document) (0..n)
ParticipantObjectIdentification (Digital Signature Document) (1)