Skip to content

Commit

Permalink
Merge pull request #6 from ritikarawlani/main
Browse files Browse the repository at this point in the history 
Draft updates 24 april
  • Loading branch information
@ritikarawlani
ritikarawlani authored May 1, 2024
2 parents a4b80c0 + ebd920c commit 085bc2f
Show file tree
Hide file tree
Showing 3 changed files with 91 additions and 25 deletions.
10 changes: 7 additions & 3 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -24,18 +24,22 @@ It is presumed that the deviations from profile will yield implementations non c

<p><strong>Removed Paragraph Content</strong></p>
<span><i>
"Note that Content Creators and Content Consumers should be capable of being configured to other conformance policies to support local policy. For example, some environments may choose a different <mark>JAdES</mark> 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 can validate these Digital Signature blocks, and be capable of configured behavior according to the local policy. Deviations from these guidelines would need to be expressed in site policy and would be enumerated in the JWS-Signature block. For example, some environments may choose a different hashing algorithm, policy identifier, or signature purpose vocabulary. Some regions also require conformance to ISO 17090, which includes additional Certificate issuing, content, and validation rules."
"Note that Content Creators and Content Consumers should be capable of being configured to other conformance policies to support local policy. For example, some environments may choose a different JAdES 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 can validate these Digital Signature blocks, and be capable of configured behavior according to the local policy. Deviations from these guidelines would need to be expressed in site policy and would be enumerated in the JWS-Signature block. For example, some environments may choose a different hashing algorithm, policy identifier, or signature purpose vocabulary. Some regions also require conformance to ISO 17090, which includes additional Certificate issuing, content, and validation rules."
</i></span>

#### 2. Usage of DSG with MHD (ref transaction no) would not be covered as DSG does not address signature for a FHIR Bundle, is not directly supported, but a result of that ends up as a serialized blob that can be signed -> volume 1
#### 2. Usage of DSG with MHD (ITI-105) is not covered as it is not in the scope of DSG. FHIR bundle signatures are not directly supported, but it would be supported as a two step process with a serialized blob that could be signed.

#### 3. DSGj does not contain guidance around homeCommunityID, as the uniqueId is globally unique and knowing the homeCommunityID is a nice-to-have

## Issues Identified in XML DSG chapter 5.5

#### 1. Notes about deviation from profile to be reviewed if they need to be present

#### 2. The requirement of "Shall use the canonicalization algorithm “Canonical XML 1.1 with Comments” ( http://www.w3.org/2006/12/xml-c14n11#WithComments )." needs to be reviewed
<span>The JADES specification is proposing that the signature is applied across a bytestream and makes no assumptions about the canonicalization applied and that canonicalization recommendations are made consistent by PCC dev1</span>
<span>The JADES specification is proposing that the signature is applied across a byte stream and makes no assumptions about the canonicalization applied and that canonicalization recommendations are made consistent by PCC dev1</span>

#### 3. Table 5.5.2-1: Digital Signature Purposes from ASTM E1762-95(2013) to be replaced by FHIR Signature Type Value Set

#### 4. Rename the volume 3 to include XML-Signature

#### 5. There is no guidance on encryption algorithms in the chapter at the moment. Review 5.10.2.1.1. "Alg" parameter guidance around "RS256", "ES256" to see if XML needs similar updates
39 changes: 26 additions & 13 deletions ch-37.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@
</div>
<div class="top-bar-right hide-for-small-only">
<ul class="menu">
<li class="menu-text tf-version">IHE IT Infrastructure (ITI) Technical Framework, Volume <span id="volumeNo"></span><br /><mark>Revision 20.0, August 4, 2023 – Final Text</mark></li>
<li class="menu-text tf-version">IHE IT Infrastructure (ITI) Technical Framework, Volume <span id="volumeNo"></span><br />Revision 20.0, August 4, 2023 – Final Text</li>
</ul>
<ul class="menu align-right">
<li><input id="ihe-search-field" type="search" placeholder="Search"></li>
Expand Down Expand Up @@ -121,23 +121,35 @@ <h2 id="37.1">37.1 DSG Actors/Transactions</h2>
</thead>
<tbody>
<tr>
<td>Content Creator</td>
<td rowspan="2">Content Creator</td>
<td>Document Digital Signature</td>
<td>R</td>
<td>O</td>
<td>
<a href="../Volume3/ch-5.5.html#5.5">ITI TF-3: 5.5</a>
</td>
<tr>
<td>Document Digital Signature in JSON</td>
<td>O</td>
<td>
<a href="../Volume3/ch-5.10.html#5.10">ITI TF-3: 5.10</a>
</td>
</tr>
</tr>
<tr>
<td>Content Consumer</td>
<td rowspan="2">Content Consumer</td>
<td>Document Digital Signature</td>
<td>R</td>
<td>O</td>
<td>
<a href="../Volume3/ch-5.5.html#5.5">ITI TF-3: 5.5</a>
</td>
<tr>
<td>Document Digital Signature in JSON</td>
<td>O</td>
<td>
<a href="../Volume3/ch-5.10.html#5.10">ITI TF-3: 5.10</a>
</td>
</tr>
</tr>
</tbody>
</table>
<h3 id="37.1.1">37.1.1 Actor Descriptions and Actor Profile Requirements</h3>
Expand Down Expand Up @@ -224,12 +236,12 @@ <h2 id="37.2">37.2 DSG Actor Options</h2>
</tr>
</tbody>
</table>
<p class="note">Note 1: Content Creator Actors and Content Consumer Actors shall support at least
<p class="note">Note 1: Content Creator Actors and Content Consumer Actors SHALL support at least
one option.</p>
<h3 id="37.2.1">37.2.1 Detached Signature Option</h3>
<p>
Content Creators that support the Detached Signature Option shall have the capability to create a
Detached Signature document that is composed of the Signature block as specified in
Detached Signature document that is composed of the XML Signature block as specified in
<a href="../Volume3/ch-5.5.html#5.5.2">ITI TF-3: 5.5.2</a>
and <a href="../Volume3/ch-5.5.html#5.5.3">ITI TF-3: 5.5.3</a>, and a manifest of references to the signed documents. The signature document does not include the content of the documents that are signed. The Detached Signature Option supports the
signing of multiple documents with one signature
Expand All @@ -246,7 +258,7 @@ <h3 id="37.2.1">37.2.1 Detached Signature Option</h3>
for documents signed with a Detached Signature.
</p>
<h4 id="37.2.1.1">37.2.1.1 SubmissionSet Signature Option</h4>
<p>The SubmissionSet Signature Option is a variant on the Detached Signature Option.</p>
<p>The SubmissionSet Signature Option is a variant on the Detached Signature Option using the XML Digital Signature.</p>
<p>The Content Creator shall have the ability to create a Detached Signature document that includes
reference to all the documents included in the SubmissionSet, except for the Detached Signature
document itself; and a reference to the
Expand All @@ -261,7 +273,7 @@ <h4 id="37.2.1.1">37.2.1.1 SubmissionSet Signature Option</h4>
<h3 id="37.2.2">37.2.2 Enveloping Signature Option</h3>
<p>
Content Creators that support the Enveloping Signature Option shall have the capability to create
an Enveloping Signature document that is composed of the signature block as specified in
an Enveloping Signature document that is composed of the XML signature block as specified in
<a href="../Volume3/ch-5.5.html#5.5.2">ITI TF-3: 5.5.2</a>
and <a href="../Volume3/ch-5.5.html#5.5.4">5.5.4</a>, and the document that is signed. The Enveloping Signature Option only supports one document per signature document.
</p>
Expand All @@ -286,8 +298,7 @@ <h3 id="37.2.3">37.2.3 JSON Detached Signature Option</h3>
document.
</p>
<p>
The digital signature document, when published using Document Sharing profiles (e.g., XDS, XDR,
XDM, XCA, etc.), shall conform to the Document Sharing metadata rules identified in
The digital signature document, when published using Document Sharing profiles (e.g., XDS, XCA, XDM, XDR, and MHD), shall conform to the Document Sharing metadata rules identified in
<a href="../Volume3/ch-5.10.html#5.10.6">ITI TF-3: 5.10.6</a>.
</p>
<p>
Expand Down Expand Up @@ -515,6 +526,10 @@ <h3 id="37.4.4">37.4.4 Sign a document by Enveloping - Use Case Description</h3>
<p>Since it is unclear whether (or which) metadata should refer to the signed document or to the
enveloping signature document, IHE does not specify metadata to be used for an Enveloping
Signature document in a Document Sharing infrastructure.</p>

<h3 id="37.4.5">37.4.5 Sign using both XML and JSON options</h3>
<p>When the signer does not know which signature technology stack the validator is using, then the signer can choose to sign with both options; or the validator support both options</p>

<h2 id="37.5">37.5 Security Considerations</h2>
<p>Digital Signatures rely on a Private Key / Public Key Management Infrastructure (aka PKI) that
must exist and be configured. The definition and configuration of PKI is outside the scope of
Expand All @@ -532,8 +547,6 @@ <h2 id="37.5">37.5 Security Considerations</h2>
<ins><p>Content Creator implementing the JSON Detached Signature or the JSON Enveloping Signature Options shall have access to a Time Stamping Authority (TSA) Service that meets the JSON Signature <code>tstVD</code> requirement and local policy requirements for Time Stamping Authority.</p></ins>
<p>Content Creator and Content Consumer should be grouped with ATNA Secure Node or Secure
Application to record an Audit Message when a signature is created or validated.</p>
<h3 id="37.4.5">37.4.5 Sign using both XML and JSON options</h3>
<p>When the signer does not know which signature technology stack the validator is using, then the signer can choose to sign with both options.or the validator support both options</p>
<h2 id="37.6">37.6 Cross Profile Considerations</h2>
<p>When used with a Document Sharing infrastructure (e.g., XDS, XCA, XDM, XDR, and MHD):</p>
<ul>
Expand Down
67 changes: 58 additions & 9 deletions ch-5.10.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@
</div>
<div class="top-bar-right hide-for-small-only">
<ul class="menu">
<li class="menu-text tf-version">IHE IT Infrastructure (ITI) Technical Framework, Volume <span id="volumeNo"></span><br /><mark>Revision 1.0, March 4, 2024 – Initial Draft</mark></li>
<li class="menu-text tf-version">IHE IT Infrastructure (ITI) Technical Framework, Volume <span id="volumeNo"></span><br />Revision 1.0, April 24, 2024 – Initial Draft</li>
</ul>
<ul class="menu align-right">
<li><input id="ihe-search-field" type="search" placeholder="Search"></li>
Expand Down Expand Up @@ -61,7 +61,7 @@
</div>
</div>
<div id="main-top" class="cell medium-10 large-10">
<h2 id="5.10">5.10 Document Digital Signature in JSON (DSGj) Document Content</h2>
<h2 id="5.10">5.10 Document Digital Signature (DSG) JSON Signature Document Content</h2>
<p>Document Digital Signature content shall conform to JAdES 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. Shall there be a conflict in the requirements specified here versus as specified in JAdES, then the JAdES specification shall be considered as authoritative.</p>
<h3 id="5.10.1">5.10.1 References</h3>
<h4 id="5.10.1.1">5.10.1.1 Normative References</h4>
Expand All @@ -77,7 +77,6 @@ <h4 id="5.10.1.1">5.10.1.1 Normative References</h4>
<a href="https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf">https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf</a>
<span> -- aka. ETSI TS 119 182-1</span>
</p>
<h4 id="5.10.1.2">5.10.1.2 Informative References</h4>
<p>
<span style="font-weight:bold">[RFC 7797]</span>
<span>JSON Web Signature (JWS) Unencoded Payload Option</span>
Expand All @@ -96,6 +95,24 @@ <h4 id="5.10.1.2">5.10.1.2 Informative References</h4>
<a href="https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/01.04.03_60/ts_119312v010403p.pdf">https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/01.04.03_60/ts_119312v010403p.pdf</a>
<span />
</p>
<h4 id="5.10.1.2">5.10.1.2 Informative References</h4>
<p>
<span style="font-weight:bold">[ASTM-E1762-05]</span>
<span>ASTM E1762-95(2013) – Standard Guide for the Authentication of Health Care Information</span>
<span />
</p>
<p>
<span style="font-weight:bold">[ETSI TS 119 511]</span>
<span>Electronic Signatures and Infrastructures (ESI); Policy and security requirements for trust service providers providing long-term preservation of digital signatures or general data using digital signature techniques</span>
<a href="https://www.etsi.org/deliver/etsi_ts/119500_119599/119511/01.01.01_60/ts_119511v010101p.pdf">https://www.etsi.org/deliver/etsi_ts/119500_119599/119511/01.01.01_60/ts_119511v010101p.pdf</a>
<span />
</p>
<p>
<span style="font-weight:bold">[ETSI ES 201 733]</span>
<span>Electronic Signatures Formats</span>
<a href="https://www.etsi.org/deliver/etsi_es/201700_201799/201733/01.01.02_50/es_201733v010102m.pdf">https://www.etsi.org/deliver/etsi_es/201700_201799/201733/01.01.02_50/es_201733v010102m.pdf</a>
<span />
</p>
<h3 id="5.10.2">5.10.2 JSON Signature Specification</h3>
<p>The following constraints define the <a href="https://datatracker.ietf.org/doc/html/rfc7515#section-3.2">JWS JSON</a> object. This block is common to the detached signature and Enveloping signature.</p>
<ul>
Expand All @@ -107,9 +124,37 @@ <h3 id="5.10.2">5.10.2 JSON Signature Specification</h3>
<h4 id="5.10.2.1">5.10.2.1 Protected Header</h4>
<h5 id ="5.10.2.1.1">"alg" (Algorithm) Header Parameter</h5>
<ul>
<li class="bullet-list1">SHALL have "alg" as "HS256" (must support), "RS256" (recommended) and more algorithm options can be supported as specified in JSON Web Algorithms (JWA) (see <a href="https://www.rfc-editor.org/rfc/rfc7518.html#section-3.1">RFC 7518</a>)</li>
<li><mark>Its value should be one of the algorithms for digital signatures recommended by in ETSI TS 119 312 [21].</mark></li>
<li class="bullet-list1">SHALL be present</li>
<li> It is recommend to use algorithms as specified in <a href="https://www.rfc-editor.org/rfc/rfc7518.html#section-3.1">RFC 7518</a> and <a href="https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/01.01.01_60/ts_119312v010101p.pdf">ETSI TS 119 312</a></li>
</ul>
<table>
<thead>
<tr>
<th></th>
<th>RFC 7518</th>
<th>ETSI TS 119 312 (Table 4.a)</th>
</tr>
</thead>
<tbody>
<tr>
<td>required</td>
<td>RS256</td>
<td>sha256-with-rsa</td>
</tr>
<tr>
<td>recommended</td>
<td>ES256</td>
<td>sha256-with-ecdsa</td>
</tr>
<tr>
<td>required by RFC 7518*</td>
<td>HS256</td>
<td>-</td>
</tr>
</tbody>
</table>
<p class="note">* HS256 is required by RFC 7518 and not by this specification, it is only mentioned here for consistency purposes</p>

<h5 id="5.10.2.1.2">5.10.2.1.2 "crit" (Critical) Parameter</h5>
<ul>
<li>The header SHALL include the crit header parameter and conform to specifications as per JAdES</li>
Expand Down Expand Up @@ -156,12 +201,13 @@ <h5 id="5.10.3.1.1">5.10.3.1.1 "sigD" Header Parameter</h5>
<li>sigD parameter shall be included as per 5.2.8.1 of the JAdES Specification</li>
<li>mID member shall be present and set to "http://uri.etsi.org/19182/ObjectIdByURIHash"</li>

<li class="bullet-list1"><mark>
pars member shall 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</mark>
<li class="bullet-list1">
The pars member shall be an array of strings that contain references to each data object* being signed. This array is considered the manifest of the data objects being signed. Each string in this array shall be an URI. See <a href="5.10.6.1.9">Section 5.10.6.1.9</a> for more details.
</li>
<li>ctys member shall be present</li>
<li>hashV, and the hashM members shall be present</li>
</ul>
<p class="note">* Note: Data Objects refer to the binary representations of document, or any other content on which the digital signature is captured and verified</p>
<h5 id="5.10.3.1.2">5.10.3.1.2 "cty" (content type) Header Parameter</h5>
<ul><li>SHALL not be included</li></ul>
<h5 id="5.10.3.1.2">5.10.3.1.2 "b64" Header Parameter</h5>
Expand Down Expand Up @@ -230,12 +276,15 @@ <h5 id="5.10.6.1.7">5.10.6.1.7 XDSDocumentEntry.title</h5>
<p>Should be the same as the display name for the signature purpose</p>
<h5 id="5.10.6.1.8">5.10.6.1.8 XDSDocumentEntry.language</h5>
<p>The language of the signature content shall be ‘art’ as in “artificial”.</p>
<h5 id ="5.10.6.1.9">5.10.6.1.9 XDSDocumentEntry.uniqueId</h5>
<p>
Shall use an URI format to 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. See ebRIM Representation <a href="https://profiles.ihe.net/ITI/TF/Volume3/ch-4.2.html#4.2.3.2.26">Section 4.2.3.2.26</a></p>
<h4 id="5.10.6.3">5.10.6.3 Document Sharing - Folder Metadata</h4>
<p>This document content profile makes no changes to the structure of Folders.</p>
<h4 id="5.10.6.4">5.10.6.4 Document Associations</h4>
<p>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). <mark>See Section 4.2.2.</mark></p>
<p>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 ebRIM Representation <a href="https://profiles.ihe.net/ITI/TF/Volume3/ch-4.2.html#4.2.2">Section 4.2.2</a>.</p>
<h3 id="5.10.7">5.10.7 Security Considerations</h3>
<p><mark>See JAdES specification for risk assessment and mitigation plan on Digital Signatures.</mark></p>
<p>See ETSI ES 201 733 and ETSI TS 119 511 specifications for risk assessment and mitigation plan on Digital Signatures. Note that Content Creators and Content Consumers should be capable of being configured to other conformance policies to support other jurisdictional policies.</p>
<h4 id="5.10.7.1">5.10.7.1 Content Creator</h4>
<p>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.</p>
<table cellspacing="0" cellpadding="0">
Expand Down

0 comments on commit 085bc2f

Please sign in to comment.