Subject: Re: [cicm] Logical Model, PKCS#11 & FIPS-140-2

From: "Lanz, Dan" <[email-masked]>
Date: Mon, 7 Jun 2010 11:55:36 -0400

Ludovic,

Your concern regarding allocation of functions to only the domain (red or black) in which they are "required" is one that the CICM development team considered extensively last year.  The chosen approach was to not constrain functions to one domain or the other.  Instead, we allowed the developer to allocate where specific functions were needed, with the caveat that the developer had to explicitly state what functions were implemented (see CICM "Conformance" section).  However, upon further review, the Conformance section does not require the developer to state in which domain a particular function was implemented.  This was a significant oversight.

However, since you've raised the issue, we should explore this further.  Should the specification state explicitly whether a function is a red function, a black function, or both?  Or should this not be explicitly stated (instead, presumably, the specification would only require a developer to state in the conformance statement where a function was implemented--red, black, or both)?  Or is there another better approach?

This question will take some thought.  Consider the ::import_key function.  CICM allows both red and black key to be imported via this interface.  Many modules will disallow the importation of red key on the black side, or may disallow the importation of red key altogether.  Should ::import_key be broken up into red and black domain versions, to allow its use to be constrained to only one domain?  There are a number of functions with similar circumstances.

This is significant architecturally to the interface so comments/suggestions from the community would be very helpful.

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ludovic Jacquin
Sent: Wednesday, May 19, 2010 4:58 AM
To: The Common Interface to Cryptographic Modules discussion list is focused on APIs for High assurance cryptographic modules.
Subject: Re: [cicm] Logical Model, PKCS#11 & FIPS-140-2

Hello Lev,

> Indeed, that is a critical component of domain separation. However,
> since CICM doesn't specify hardware requirements (it's a software 
> interface), perhaps we should only mention that in passing when
> dealing with the logical model.
> 
> * Is that sufficient, does anything else need to be specified?

Yes, we agree and maybe it can be mentioned in an introductory/context
part. As we concentrate on high assurance and interface definition, this
kind of discussion may contain a TODO  and a NOT TODO list for developers
because bad implementations or usage can significantly weaken the whole
system.

Another point: Charles recently highlighted the fact that having a single
large IDL file was not recommended. There's another motivation, beyond
dead code considerations. Because of our domain separation constraint,
we largely prefer to have separate subsets of functionalities.
In our case, the cryptographic module is at the boundary between the
black domain (that manages ciphered packets, in the unsafe area) and
the red domain (that manages cleartext packts, in the safe area). And
the two security domains cannot communicate with each other directly
since the cryptographic module creates a breaking point between them.
Therefore the API (and thus the IDL) should be divided into parts that
represent the subsets of functionalities required by each security
domain.

Cheers,

    Ludovic and Vincent
_______________________________________________
cicm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cicm