| 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-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-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-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 |
|
| ITI19 | ITI19-28 | reviewed | Testable |
0
|
0
| | For SMTP communications, the sender and receiver shall both support the S/MIME_RSA_WITH_3DES_128_CBC_SHA ciphersuite. | 135 | Section 3.19.6.5 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-29 | reviewed | Testable |
0
|
0
| | For SMTP communications, Receivers must be able to receive encryption methods odler than S/MIME_RSA_WITH_3DES_128_CBC_SHA ciphersuite. | 135 | Section 3.19.6.5 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-30 | reviewed | Testable |
0
|
0
| | For SMTP communications and IHE Authenticate Node compliance, the sender will use AES ciphersuite. | 135 | Section 3.19.6.5 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-31 | reviewed | Testable |
0
|
0
| | For SMTP communications, the email shall be digitally signed by the sender, by a one level only detached signature, applied BEFORE the encryption. | 135 | Section 3.19.6.5 | 4/30/19 4:50:25 PM by NicolasBailliet |
|
| ITI19 | ITI19-35 | reviewed | Testable |
0
|
0
| | Identities must be unique across the secure domain. | 136 | Section 3.19.7 | 4/30/19 4:50:25 PM by NicolasBailliet |
|