| ITI19 | ITI19-1 | reviewed | Testable |
2
|
0
| | When Authenticating the Remote Secure Node, the Local Secure Node shall be able to perform certificate validation based on signature by a trusted CA. | 133 | Section 3.19.6.1 | 3/8/24 9:20:47 AM by vhofman |
|
| ITI19 | ITI19-10 | reviewed | Testable |
0
|
0
| | The Secure Node or Secure Application shall not reject certificates that contain unknown attributes or other parameters. | 134 | Section 3.19.6.1.3 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-11 | reviewed | Testable |
1
|
0
| | The certificates used for mutual authentication shall be X509 certificates based on RSA key with key length in the range of 1024-4096. | 134 | Section 3.19.6.1.3 | 7/11/19 7:33:08 PM by ceoche |
|
| ITI19 | ITI19-12 | reviewed | Testable |
0
|
0
| | The IHE Technical Framework recommends a maximum expiration time for certificates of 2 years. | 134 | Section 3.19.6.1.3 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-13 | reviewed | Testable |
0
|
0
| | Using a certificate chain back to an external trusted certificate authority to determine authorizations is strongly discouraged. | 134 | Section 3.19.6.1.3 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-14 | reviewed | Testable |
1
|
0
| | For all connections carrying Protected Information (PI) and when configured for use not on a physically secured network, implementations shall use the TLS protocol. | 135 | Section 3.19.6.2 | 8/26/19 5:25:26 PM by ceoche |
|
| ITI19 | ITI19-15 | reviewed | Testable |
1
|
0
| | For all connections carrying Protected Information (PI) and when configured for use not on a physically secured network, implementations shall support TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. | 135 | Section 3.19.6.2 | 8/26/19 5:25:26 PM by ceoche |
|
| ITI19 | ITI19-16 | reviewed | Testable |
0
|
0
| | For all connections carrying Protected Information (PI), the recommended "well-known port 2762" as specified by DICOM shall be used when the Secure node is configured for use not on a physically secured network. | 135 | Section 3.19.6.2 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-17 | reviewed | Testable |
0
|
0
| | For all connections carrying Protected Information (PI), and when the secure node is configured for use on a physically secured network, a different port number shall be used, preferably the standard port 104. | 135 | Section 3.19.6.2 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-18 | reviewed | Testable |
0
|
0
| | For all connections carrying Protected Information (PI), the port number used when configured for use on a physically secured network shall be different than the port number used when configured for use not on a physically secured network. | 135 | Section 3.19.6.2 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-19 | reviewed | Testable |
0
|
0
| | For all connections carrying Protected Information (PI), if SN/SA is configured for physical security, then it may use the non-TLS DICOM port and protocol. | 135 | Section 3.19.6.2 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-2 | reviewed | Testable |
1
|
0
| | When Authenticating the Remote Secure Node, the Local Secure Node shall be able to perform direct certificate validation to a set of trusted certificates. | 133 | Section 3.19.6.1 | 8/26/19 5:25:26 PM by ceoche |
|
| ITI19 | ITI19-20 | reviewed | Testable |
0
|
0
| | For all web-services carrying Protected Information(PI), a trusted association shall be established between the two nodes utilizing WS-I Basic Security Profile Version 1.1. | 135 | Section 3.19.6.4 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-21 | reviewed | Testable |
0
|
0
| | For SMTP communications, when configured to use email on a network that is not physically secured, implementations shall use S/MIME (RFC-3851). | 135 | Section 3.19.6.5 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-22 | reviewed | Testable |
0
|
0
| | For SMTP communications on a network that is not physically secured, the message shall be signed using the signedData format. | 135 | Section 3.19.6.5 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-23 | reviewed | Testable |
0
|
0
| | For SMTP communications on a network that is not physically secured, the email shall be digitally signed by the sender, by a one level only detached signature. | 135 | Section 3.19.6.5 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-24 | reviewed | Testable |
0
|
0
| | For SMTP communications on a network that is not physically secured, this digital signature shall be interpreted to mean that the sender is attesting to their authorization to disclose the information to the intended recipient(s). | 135 | Section 3.19.6.5 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-25 | reviewed | Testable |
0
|
0
| | For SMTP communications on a network that is not physically secured, RSA/SHA-1 signature shall be supported by both the sender and the receiver. | 135 | Section 3.19.6.5 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-26 | reviewed | Testable |
0
|
0
| | For SMTP communications on a network that is not physically secured, all the certificates of the "trust chain" shall be contained within the signature when using a PKI or out of bound certificate. | 135 | Section 3.19.6.5 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-27 | reviewed | Testable |
0
|
0
| | For SMTP communications, the sender shall support the S/MIME_RSA_WITH_AES_128_CBC_SHA ciphersuite. | 135 | Section 3.19.6.5 | 4/30/19 4:50:25 PM by NicolasBailliet |
|