net.ihe.gazelle.assets.SearchCriteria : 27 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.134Section 3.19.6.1.34/30/19 4:50:25 PM by NicolasBailliet
ITI19ITI19-12reviewedTestable 0 0 The IHE Technical Framework recommends a maximum expiration time for certificates of 2 years.134Section 3.19.6.1.34/30/19 4:50:25 PM by NicolasBailliet
ITI19ITI19-13reviewedTestable 0 0 Using a certificate chain back to an external trusted certificate authority to determine authorizations is strongly discouraged.134Section 3.19.6.1.34/30/19 4:50:25 PM by NicolasBailliet
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.135Section 3.19.6.24/30/19 4:50:25 PM by NicolasBailliet
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. 135Section 3.19.6.24/30/19 4:50:25 PM by NicolasBailliet
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.135Section 3.19.6.24/30/19 4:50:25 PM by NicolasBailliet
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.135Section 3.19.6.24/30/19 4:50:25 PM by NicolasBailliet
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.135Section 3.19.6.44/30/19 4:50:25 PM by NicolasBailliet
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).135Section 3.19.6.54/30/19 4:50:25 PM by NicolasBailliet
ITI19ITI19-22reviewedTestable 0 0 For SMTP communications on a network that is not physically secured, the message shall be signed using the signedData format.135Section 3.19.6.54/30/19 4:50:25 PM by NicolasBailliet
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.135Section 3.19.6.54/30/19 4:50:25 PM by NicolasBailliet
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).135Section 3.19.6.54/30/19 4:50:25 PM by NicolasBailliet
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.135Section 3.19.6.54/30/19 4:50:25 PM by NicolasBailliet
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.135Section 3.19.6.54/30/19 4:50:25 PM by NicolasBailliet
ITI19ITI19-27reviewedTestable 0 0 For SMTP communications, the sender shall support the S/MIME_RSA_WITH_AES_128_CBC_SHA ciphersuite.135Section 3.19.6.54/30/19 4:50:25 PM by NicolasBailliet
ITI19ITI19-28reviewedTestable 0 0 For SMTP communications, the sender and receiver shall both support the S/MIME_RSA_WITH_3DES_128_CBC_SHA ciphersuite.135Section 3.19.6.54/30/19 4:50:25 PM by NicolasBailliet
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.135Section 3.19.6.54/30/19 4:50:25 PM by NicolasBailliet
ITI19ITI19-30reviewedTestable 0 0 For SMTP communications and IHE Authenticate Node compliance, the sender will use AES ciphersuite.135Section 3.19.6.54/30/19 4:50:25 PM by NicolasBailliet
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.135Section 3.19.6.54/30/19 4:50:25 PM by NicolasBailliet
ITI19ITI19-35reviewedTestable 0 0 Identities must be unique across the secure domain.136Section 3.19.74/30/19 4:50:25 PM by NicolasBailliet