Search Criteria : 37 assertions found for this search Review filtered assertions

Assertion

Applies to

Applied to
Not applied to

Coverage

Covered by
Not covered by
Id scheme
Assertion id
Status
Testable?
#Coverage
#Applies to
Comment
Predicate
Page
Tags
Last changed
Actions
ITI19ITI19-1to be reviewedTestable 0 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.134Section 3.19.6.11/29/19 2:23:58 PM by Abderrazek Boufahja
ITI19ITI19-10to be reviewedTestable 0 0 The Secure Node or Secure Application shall not reject certificates that contain unknown attributes or other parameters.135Section 3.19.6.1.31/29/19 2:23:47 PM by Abderrazek Boufahja
ITI19ITI19-11to be reviewedTestable 0 0 The certificates used for mutual authentication shall be X509 certificates based on RSA key with key length in the range of 1024-4096.135Section 3.19.6.1.31/29/19 2:23:47 PM by Abderrazek Boufahja
ITI19ITI19-12to be reviewedTestable 0 0 The IHE Technical Framework recommends a maximum expiration time for certificates of 2 years.135Section 3.19.6.1.31/29/19 2:23:47 PM by Abderrazek Boufahja
ITI19ITI19-13to be reviewedTestable 0 0 Using a certificate chain back to an external trusted certificate authority to determine authorizations is strongly discouraged.135Section 3.19.6.1.31/29/19 2:23:47 PM by Abderrazek Boufahja
ITI19ITI19-14to be reviewedTestable 0 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.136Section 3.19.6.21/29/19 2:23:47 PM by Abderrazek Boufahja
ITI19ITI19-15to be reviewedTestable 0 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.136Section 3.19.6.21/29/19 2:23:58 PM by Abderrazek Boufahja
ITI19ITI19-16to be reviewedTestable 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.136Section 3.19.6.21/29/19 2:23:58 PM by Abderrazek Boufahja
ITI19ITI19-17to be reviewedTestable 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. 136Section 3.19.6.21/29/19 2:23:47 PM by Abderrazek Boufahja
ITI19ITI19-18to be reviewedTestable 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.136Section 3.19.6.21/29/19 2:23:47 PM by Abderrazek Boufahja
ITI19ITI19-19to be reviewedTestable 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.136Section 3.19.6.21/29/19 2:23:47 PM by Abderrazek Boufahja
ITI19ITI19-2to be reviewedTestable 0 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.134Section 3.19.6.11/29/19 2:23:58 PM by Abderrazek Boufahja
ITI19ITI19-20to be reviewedTestable 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.136Section 3.19.6.41/29/19 2:23:47 PM by Abderrazek Boufahja
ITI19ITI19-21to be reviewedTestable 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).136Section 3.19.6.51/29/19 2:23:47 PM by Abderrazek Boufahja
ITI19ITI19-22to be reviewedTestable 0 0 For SMTP communications on a network that is not physically secured, the message shall be signed using the signedData format.136Section 3.19.6.51/29/19 2:23:47 PM by Abderrazek Boufahja
ITI19ITI19-23to be reviewedTestable 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.136Section 3.19.6.51/29/19 2:23:47 PM by Abderrazek Boufahja
ITI19ITI19-24to be reviewedTestable 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).136Section 3.19.6.51/29/19 2:23:47 PM by Abderrazek Boufahja
ITI19ITI19-25to be reviewedTestable 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.136Section 3.19.6.51/29/19 2:23:58 PM by Abderrazek Boufahja
ITI19ITI19-26to be reviewedTestable 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.136Section 3.19.6.51/29/19 2:23:47 PM by Abderrazek Boufahja
ITI19ITI19-27to be reviewedTestable 0 0 For SMTP communications, the sender shall support the S/MIME_RSA_WITH_AES_128_CBC_SHA ciphersuite.136Section 3.19.6.51/29/19 2:23:47 PM by Abderrazek Boufahja