Search Criteria : 30 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-10reviewedTestable 0 0 The Secure Node or Secure Application shall not reject certificates that contain unknown attributes or other parameters.141Section 3.19.6.1.32/5/16 12:27:23 PM by aboufahj
ITI19ITI19-11reviewedTestable 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.141Section 3.19.6.1.32/5/16 12:27:23 PM by aboufahj
ITI19ITI19-12reviewedTestable 0 0 The IHE Technical Framework recommends a maximum expiration time for certificates of 2 years.141Section 3.19.6.1.32/5/16 12:27:23 PM by aboufahj
ITI19ITI19-13reviewedTestable 0 0 Using a certificate chain back to an external trusted certificate authority to determine authorizations is strongly discouraged.141Section 3.19.6.1.32/5/16 12:27:23 PM by aboufahj
ITI19ITI19-16reviewedTestable 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.141Section 3.19.6.22/5/16 12:27:23 PM by aboufahj
ITI19ITI19-17reviewedTestable 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. 141Section 3.19.6.22/5/16 12:27:23 PM by aboufahj
ITI19ITI19-18reviewedTestable 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.141Section 3.19.6.22/5/16 12:27:23 PM by aboufahj
ITI19ITI19-19reviewedTestable 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.141Section 3.19.6.22/5/16 12:27:23 PM by aboufahj
ITI19ITI19-20reviewedTestable 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.142Section 3.19.6.42/5/16 12:27:23 PM by aboufahj
ITI19ITI19-21reviewedTestable 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).142Section 3.19.6.52/5/16 12:27:23 PM by aboufahj
ITI19ITI19-22reviewedTestable 0 0 For SMTP communications on a network that is not physically secured, the message shall be signed using the signedData format.142Section 3.19.6.52/5/16 12:27:23 PM by aboufahj
ITI19ITI19-23reviewedTestable 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.142Section 3.19.6.52/5/16 12:27:23 PM by aboufahj
ITI19ITI19-24reviewedTestable 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).142Section 3.19.6.52/5/16 12:27:23 PM by aboufahj
ITI19ITI19-25reviewedTestable 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.142Section 3.19.6.52/5/16 12:27:23 PM by aboufahj
ITI19ITI19-26reviewedTestable 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.142Section 3.19.6.52/5/16 12:27:23 PM by aboufahj
ITI19ITI19-27reviewedTestable 0 0 For SMTP communications, the sender shall support the S/MIME_RSA_WITH_AES_128_CBC_SHA ciphersuite.142Section 3.19.6.52/5/16 12:27:23 PM by aboufahj
ITI19ITI19-28reviewedTestable 0 0 For SMTP communications, the sender and receiver shall both support the S/MIME_RSA_WITH_3DES_128_CBC_SHA ciphersuite.142Section 3.19.6.52/5/16 12:27:23 PM by aboufahj
ITI19ITI19-29reviewedTestable 0 0 For SMTP communications, Receivers must be able to receive encryption methods odler than S/MIME_RSA_WITH_3DES_128_CBC_SHA ciphersuite.142Section 3.19.6.52/5/16 12:27:23 PM by aboufahj
ITI19ITI19-30reviewedTestable 0 0 For SMTP communications and IHE Authenticate Node compliance, the sender will use AES ciphersuite.142Section 3.19.6.52/5/16 12:27:23 PM by aboufahj
ITI19ITI19-31reviewedTestable 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.142Section 3.19.6.52/5/16 12:27:23 PM by aboufahj