Re: RESUME REQUEST: [cip-core] Package Proposal #1 (Security packages)

Kento Yoshida

Hello and thank you for your comment, Punit,

-----Original Message-----
From: Punit Agrawal <>
Sent: Monday, January 20, 2020 7:29 PM
To: Kento Yoshida <>
Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1 (Security

Hello Yoshida-san,

Kento Yoshida <> writes:


I would like to resume our proposal from security working group.
As you know, Kazu has modified the script to generate a proposal and posted the
minimum base system proposal, and then I created the new proposal.

The difference from the original (rev01) proposal is below:
1. We remove 'duplicity', 'google-authenticator', 'pam-shield' and 'suricata' in the
new proposal because they have an issue such as non-well maintained, python
version, too much dependencies and so on. We'll separately propose them after
solved these issues.
2. The new proposal shows all source package as flat. Thanks to the new script,
3. Actually several packages overlap with the proposed packages for minimum
base system in Debian, so I added comment them like that.,
Would you check this proposal and set the due date to review it?

Please reply if you have any comments or questions.
I have a comment about packages in the proposal that depend on hardware /
system features -

* Some packages in the proposal depend on special purpose hardware to
provide their functionality. e.g., TPM.

In systems, where TPM is not present (or similar functionality is
provided by alternate mechanisms), the TPM related packages will not
be useful. e.g., the non-x86 platforms in the CIP reference hardware

* Similarly, some packages require the system to be connected to the

In both of these situations, I am wondering what is the impact on compliance? Is
there a need to also define minimal set of hardware features expected from
reference hardware to be able to meet compliance requirements?
How each reference hardware satisfies the requirements should be considered by each reference hardware provider.
If we provide hardware mechanisms similar with TPM to protect credentials and authentications, we can meet compliance requirements.
TPM related packages are options in only systems where TPM is implemented as you said. If supporting these packages require too much costs, the necessity of them will diminish.
Actually the standard lists TPM as a typical example, so we thought it will be useful to maintain TPM related packages for many users, but their necessities depend on supporting cost.

To help review the package list (and also discuss alternatives), it would help to
define the underlying functionality that is required in more detail, e.g., secure key
storage, verified boot, etc. It'll make it possible review the proposal more




Join to automatically receive all group messages.