RE: TSS Level of Detail/PD 0063: What Information Must Be Provided in the TSS

["YOKOTA HIROFUMI" <yokota-hirofumi@jqa.jp>]

Hi,

My opinions on this thread:

-----------------------------------
PD0063 says:

> The TSS Rationale must describe the mechanisms provided by the
>  TSF to address the TSF's SFRs, as well as a high-level desctiption
>  of how these mechanisms are implemented. The description of the
>  mechanisms should be from the perspective of the TOE user.

I agree (at present).
Although the original intention of the CC was to share the common
understanding on the security functional requirements in the SFRs among
readers,
 those specifications are very hard to read.

So, I agree that the TSS provides the story-like explanation of the security
functionalities being written by the more friendly natural language.
However, I think, the TSS would not be necessary when ( in the future ) the
SFRs became really valued as a common language to be shared by all readers.

> The level at which this must be decribed will necessarily vary
>  depending upon the complexity of both the product's functions
>  and its implementation of those functions, however it shall be
>  at least as detailed as the SFRs.

I disagree.
I think the level of the description would be sufficient if it is described
as detailed as the SFRs.
Some portions might be less detailed than the User's Guidance, but, that
should not be a problem as long as they are detailed as the SFRs.

-------------------------------------------
For example:
Let's see the Access Control SFRs in a ST, and think about "(5)W(1)H".

Who: -  subjects are specified.
Where: -  objects are specified.
What: -  permit/deny actions are specified.
When: -  access operations are specified:
Why: -  security requirement rationales are provided.
How: -  rules are specified.

All those "(5)W(1)H" are specified using the terms of  the TOE in the SFRs
sections in the ST.
We may even find "additional rules (additional hows)" in the access control
SFRs.
And, we could see the exact assertions of those in the TSS.

Also, we might see FMT_MOF/ MSA/MTD/REV/SMF/SMR that have relations with the
Access Control SFRs.
And, we could see their assertions in the TSS, too.

Then, what else may we need additionaly in the TSS?

Yes, you may oppose, "this is not what "how" does mean. What "how" does mean
is the implementation mechanism".
Okey! Then, could we say that those security functions are coded by C
language, compiled and implemented?
Unlikely!

Then, could we need to describe the internal data structure? internal queues
and stacks? internal call/return mechanisms?, and generated error messages?
Unlikely! You should find them in the HLD, in the source codes, or in the
User's Guidance manuals if they are truly required, and if the correct one
is required.

------------------------------------
Daniel says:
> All the details don't have to be spelled out. What is needed is
>  one or two lines of a very-high-level implementation summary.
>  The proprietary specifics are in the HLD and LLD.

Only for the category of Access Control SFRs, solely the exact assertions of
functionality seems likely to need several pages of redundant
translations(mostly copied assertions) from the SFRs into the TSS.
I wonder what does the summary of one or two additional lines in the TSS
mean.
Of course, we could say the mechanism of implementation ("how") in only one
line.
"those security functions are coded by C language, compiled and implemented
in the TOE".

Regards,
Hirofumi Yokota