FDP_CER_EXT.1.4/OLTleaf may be too limited

[jfisherbah]

FDP_CER_EXT.1.4/OLTleaf does not currently account for situations where the TOE obtains certificates directly from an embedded CA. The only options permitted for determining the certificate identifiers in this element's second selection block are to match it with a certificate request validated by some specified process in the third selection block.

While the validation process has an open-ended assignment that would allow the ST author to describe how a direct connection to an embedded CA validates the certificates it is issuing, there is no selection or open-ended assignment defined in the second block to allow a similar specification, which may be necessary to support session proxying.

In the current STIP module, FDP_CER_EXT.2's Application Note says that "an automatically approved certificate request is implied by the validated certificate" but does not explicitly require PKCS-10 as the mechanism the TSF must use to issue itself the imitation of the original server certificate used for proxying.

If this is only ever expected to be done by the TSF parsing out the original server certificate as inputs to make a PKCS10 request to its embedded CA, then FDP_CER_EXT.1.4/OLTleaf is fine as-is for this purpose. However, if there are other methods by which a STIP product could do this, and it is not the intent to prohibit those methods, FDP_CER_EXT.1.4/OLTleaf should add the ability to specify them.

Note that this issue is also not resolved by simply iterating FDP_CER_EXT.1 because the selection is "hard coded" to be the same in the extended component definition for the SFR.