search

ND-iTC / Documents

ND iTC Document repository (NDcPP, ND SD, and all related files)
MIT License
5 stars 1 forks source link

FCS_TLSC_EXT.1.5 test 2ii is ambiguous in its request for consistency #266

Closed mclearn closed 1 year ago

mclearn commented 1 year ago

Provide the location of the issue FCS_TLSC_EXT.1.5 test 2ii states the following: "The evaluator shall ensure the test server sends Certificate and Certificate Verify messages that are consistent with the SignatureScheme being tested."

What is the correction request for the cPP? Please describe. It is clear what is meant by the Certificate Verify being consistent. However, it is not clear what it means for the Certificate to be considered consistent. A consistent Certificate could be based on the public key algorithm or it could be based on the signature algorithm of the certificate itself. But those algorithms can be (wildly) different.

There is no fully correct answer, unfortunately because the NDcPP 3.0 is somewhat ambiguous on the interplay expectations between supported_signatures and supported_signatures_cert which are in the RFC. Test case FCS_TLSC_EXT.1.5 test 2ii is for supported_signatures and if we are only looking at it through a small lens, then the (mostly) correct interpretation is that a consistent Certificate is one in which the public key of the Certificate is consistent with the advertised sigalgs.

Describe the solution you'd like Change the language to the following: "The evaluator shall ensure the test server sends a Certificate Verify message that is consistent with the SignatureScheme being tested. The evaluator shall ensure the test server sends a leaf Certificate that has a public key algorithm that is consistent with the SignatureScheme being tested."

FCS_DTLSC_EXT.1.5 would need to be adjusted accordingly.

Describe alternatives you've considered There really is none. Because of the interplay between supported_signatures and supported_signatures_cert, the only correct way is to add additional testing to identify any interplay and then make +ve and -ve test cases for them. That is best left to v3.1.

Additional context N/A

mclearn commented 1 year ago

To blend #267 and this one: "The evaluator shall establish a TLS connection using each of the SignatureSchemes specified by the requirement and observes the session is successfully completed. The evaluator shall ensure the test server sends a leaf Certificate that has a public key algorithm that is consistent with the SignatureScheme being tested. For TLS 1.2 and if the ciphersuite is DHE or ECDHE, the evaluator shall ensure that the server sends Server Key Exchange messages consistent with the SignatureScheme being tested. For TLS 1.3, the evaluator shall ensure that the server sends Certificate Verify messages consistent with the SignatureScheme being tested."

kr15tyk commented 1 year ago

TLSWG agreed to Greg's suggested change on today's call.