Re: PD-0101: Level of Detail Necessary for Assurance Requirements on Third Party Products

[Magosányi Árpád <mag@bunuel.tii.matav.hu>]

Hi!

I don't like this approach as it still have the concept of
underlying abstract machine blurred, which should be made
clear to allow further development of TOE composition.

Regarding the development tools -which is a newly brought
in point of view for me, nonetheless a valid one-:

The adequateness of the development tools is assured by the
outcome of the tests conducted in the evaluation: if the
development tools have some shortcomings, it should come
out there theoretically.

Note that the libraries used are not part of the development
tools; they are part of the underlying abstract machine, and
should be handled accordingly.

I guess we should have clearly defined concepts of underlying
abstract machine, development tool, and physical part, if we
want the TOE boundaries and its interdependencies with other
TOEs to be tractable.
Your approach acts against this, this is I don't like it.

A levelezőm azt hiszi, hogy Dr.Ir. D.J. Out a következőeket írta:
> 
> After some internal discussion in the lab, how about this tack:
> 
> Whenever I compile a fairly trivial program with a modern compiler,
> I can get a fairly hefty executable as many libraries get linked in.
> 
> I have never seen the source of these libraries, don't know if they are 
> any good, in fact I have two things to go on:
> - their Interface Specification (otherwise I can't use them)
> - the fact that I somehow have faith in the compiler
> 
> The CC handles this currently under ALC_TAT:
> - the Interface specification (ALC_TAT.1.2C and 3C)
> - the faith (it uses the word "well-defined" in ALC_TAT.1C)
> 
> However, there is a blurry line here, if I would buy a compiler with an 
> extensive cryptographic library attached to it, and all my cryptographic 
> TOE would do is simply translate external calls to it into library 
> calls, and have it evaluated on EAL4, many schemes would not allow me to 
> get away with this.
> 
> This line is subjective: you cannot push overly much into TAT, then 
> again, you are not required to evaluate your compiler.
> 
> ===============================
> 
> If I draw a parallel to hardware, it would say:
> 
> You are allowed to use 3rd party hardware in the TOE as long as:
> - it is well-defined and documented as to what it does
> - it doesn't straddle the blurry line into "doing major security for me"
> 
> This would allow you to use RAM chips and screws and the like in the 
> TOE. Other cases may be more difficult:
> 
> If my hardware security module TOE would run on a 80386 processor and 
> this is just used for execution, I might normally allow this to be 
> defined as a tool/technique.
> 
> However, if there were several users running simultaneously on my HSM 
> TOE, and I was using the 80386 virtual machiens to keep them part, I 
> might not.
> 
> Would this be the start of a viable RI? or are there immediate problems 
> associated with it that I have once again forgotten?
> 
> Dirk-Jan
> 
> 
> 
> 
> -- 
> TNO ITSEF BV
> P.O. Box 96864          tel +31 70 374 0304
> 2509 JG The Hague       fax +31 70 374 0651
> The Netherlands         www.commoncriteria.nl
> 
> 
> 
> 
> 
> 

-- 
GNU GPL: csak tiszta forrásból