kenji-lightship
commented
1 year ago Comment 22: This sounds like it is related to TD0669, but the comment doesn't seem to match the NDcPP SFR. The SFR does not discuss "invalid revocation status information." Even if it did, I believe invalid revocation status should be treated the same way as inability to contact the revocation server. If an attacker is in a position inject invalid revocation responses, the attacker should also be able to block revocation checks.
Comment 23: I agree this is an inconsistency although it doesn't seem to have caused problems in the past.
Location: FCS_(D)TLSSEXT.2; A.7.1.2; C.2.2.2 / FCS(D)TLSC_EXT.1.3; B.3.1.5; C.2.2.1
Comment 22: The override exceptions are much too broad. Also, a TOE should reject invalid revocation status information, but continue looking for valid information. This requirement that defines a different response for (any) invalid response could be interpreted to prevent the TOE from continuing to look for valid information. Suggested Change: Consider omitting these exceptions altogether, or refining the allowance so that the administrator exceptions are limited to specific certificates / circumstances and the first three selections in the second selection are removed.
Comment 23: Elements 2 and 3 of this SFR appear to be contradictory: Element 3 does not allow an exception that might be defined in element 2. Suggested Change: Preference is to omit the exception in element 2 – it might be more reasonable for the TSF to alert (or fail and log the event to allow) an administrator to reconfigure the reference ID than to allow override of the check.