cPP-Module or PP-Module?

[woodbe]

Fiona pointed out that we should title the documents from "collaborative Protection Profile Module" to "collaborative PP-Module". Now I think that changing that in the title is fine, but what about the rest of the document(s)?

There are many places where I see "cPP Module" which I would say should be "cPP-Module", but I'm wondering if it should just be "PP-Module" because the collaborative part is, to some extent, only a descriptive term and not an actual type of document.

I'm willing to do the search and replace to get this consistent on the documents, but I want to have an agreed-to text to use first.

[The-Fiona]

I thought about the term "cPP module" because I have not seen it used anywhere before. This does not make it wrong. a "cPP" is a term used only by the CCRA. (A PP that is developed collaboratively). The terms in the new revision (and the existing CC) are pure: "PP" and "PP-Module".

I easily deduced what was meant by a "cPP-Module". It's just a term that I have not seen used before.

[The-Fiona]

Sorry - I thought "close" meant to close the commenting box.

[nils-tekampe]

I still think that we should move forward as a cPP and not as a module. For this reason, I think that this goes into the wrong direction. The terms that you are discussing here are not defined anywhere, are they?

[The-Fiona]

cPP is defined in the CCRA PP and PP-Module are defined in CC 3.1 R5

[The-Fiona]

Nils has a point. If it is a PP-Module then there is no point is mentioning in the cover letter that AVA_VAN is excluded. Since in a PP-Module it would not be mentioned (since SARs are assumed to be inherited from its base PP).

If it is to be a PP (cPP) then that is valid text.

I remember a discussion on this topic, and I even remember suggesting that we could produce both. I don't recall if we came to a conclusion, there seemed to be less than a full consensus.

[woodbe]

So the current conclusion is that US, Japan and Germany are trying to talk to settle how to best handle the question to everyone's satisfaction. I spoke with Mary Baish about this last week and she said they were trying to get a call setup (I also volunteered to attend if it would help). So basically she asked that we hold off on making any decisions about this issue and how to proceed until they had talked, with the goal of providing us direction that satisfies all concerned parties.

So with that in mind, I think it is valid to mention it, especially since we do have to explain how we will handle AVA_VAN from the MDFPP to our component (which is why I mention those sections in the document as being potentially unfinished). The explanation can certainly be more limited if that is felt to be better, but since everything else should stay the same, I want to get the rest reviewed soon.

[nils-tekampe]

As I pointed out before, I am against any kind of publication now.

@The-Fiona I am really struggling to understand the status of the document that we would produce here. It would be a PP module for a base PP that by itself has never been certified nor the status of a cPP. Would a PP module in this situation have any kind of formal/official status? Or would it rather become a kind of template for ST writer which may or may not be followed?

[nils-tekampe]

@woodbe the feedback that you describe from Mary is almost identical to wat I heard from BSI. But the way I understood the feedback is that a publication at this Moment would be counter-productive (even if accompanied by such an explanation)

[woodbe]

@nils-tekampe Interesting, because what I took from Mary was that the sooner we review the better, and noting where there are still open issues would allow us to proceed on the rest of the document. This is at Review Draft stage, but the problem is we now only have 4 people regularly reviewing at this point, so not getting it out there, especially if the scheme decision takes a long time, really makes any progress questionable. If this takes another 6 months, it will be tough to keep anyone involved, and having to wait until then before getting any comments on the rest of a document specifically listed as a draft seems very odd.

Again, my point is that this is a DRAFT (and maybe we need to call that out more clearly in the title and such in the actual document), but waiting until the schemes come to a conclusion before proceeding at all seems a waste of time. I would say that we expect a second review period after the schemes have completed their work, and that should allow for the explicit flexibility to make further changes.

[The-Fiona]

@nils-tekampe. My understanding is the PP-Module would be used with a base PP. We have discussed the MDF PP (From NIAP) and the OS PP as base PPs. I believe that both of these are validated PPs. (Although I saw that OS PP was updated this week and haven't checked yet if a validation cert is available for that new version.). You can check the cert for MDF PP here.

The status as a cPP has got nothing to do with this. CCRA recognizes cPPs as well as "regular" PPs. MDF PP is currently a national PP, not a cPP. That does not by itself stop it's recognition under the CCRA. Many nations have PPs with such a status. and as you can see from recent evaluations is often used with PP-Modules.

-Fiona

[nils-tekampe]

Ok, assuming that the base PPs are certified, we would be writing a „classical“ PP module as defined in the CC. Understood. So, I guess that this would have to undergo certification as well, right?

I am honestly a bit (looking for a word, let’s use surprised for now): the one major argument that was used in the discussion on whether to include AVA VAN or not, has been, that the CCRA rules for cPPs say that a cPP must include VAN. If I understand you correctly, we could also easily go an write a regular PP. The CC themselves allow to write it without VAN and then the CCRA could decide to endorse the PP. Am I getting this right?

[The-Fiona]

I don't believe that PP-Modules are separately certified. Instead they are evaluated through the PP-Configuration. See the ACE class in CC part 3.

https://www.commoncriteriaportal.org/files/ccfiles/CCPART3V3.1R5_marked_changes.pdf

I think that the latter, a "regular" PP with no AVA_VAN, was exemplified in the PP you shared with us earlier. Although I still do not understand how this could be recognised  under the  CCRA  since in the "regular" PP scenario the PP must be at EAL 1 or 2, and both of these include AVA_VAN. (CCRA Scope item 2) )

I am very grateful for the involvement and advice from both BSI and NIAP. I am sure that will help us get to the bottom of this. You and I can speculate together for a very long time, but at the end of the day it is what will satisfy the needs of the schemes that count!

Again, I see no reason why we could not produce two documents:

1) a cPP with assurance activities selected from Evaluation Assurance Levels up to and including level 4. (Presumably you would suggest one that did not include AVA_VAN)

AND

2) a PP-Module. This would contain the same SFRs and would inherit the SARs from it's base PPs. Both could have the same SPD.

It would not be intended that these two documents ever be used together.

So, those schemes that wanted to use the cPP could do so, and those that wanted to use the PP-Module in a PP-Configuration with a base PP could do so too.

The SFRs and SD would be the same in each document.

I am supporting Brian and Mary in terms of getting this out for public review as soon as possible.

• Fiona

On 2019/05/01 16:37, Nils Tekampe wrote:

Ok, assuming that the base PPs are certified, we would be writing a „classical“ PP module as defined in the CC. Understood. So, I guess that this would have to undergo certification as well, right?

I am honestly a bit (looking for a word, let’s use surprised for now): the one major argument that was used in the discussion on whether to include AVA VAN or not, has been, that the CCRA rules for cPPs say that a cPP must include VAN. If I understand you correctly, we could also easily go an write a regular PP. The CC themselves allow to write it without VAN and then the CCRA could decide to endorse the PP. Am I getting this right?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/biometricITC/cPP-biometrics/issues/160#issuecomment-488439610, or mute the thread https://github.com/notifications/unsubscribe-auth/AJBFWYOBIGUKQVKDURKS2RLPTIEQLANCNFSM4HJVDIRQ.

-- Fiona Pattinson, CISSP atsec information security corporation Cell:+1 512 8253083 / Office:+1 512 6157382

[nils-tekampe]

Just a short note: In the German scheme PP-modules are evaluated and certified (usually along with their base PP)

[woodbe]

So as for whether AVA_VAN needs to be mentioned if we are a PP-Module or not, I think it still does as we have to explain what we think that means for the biometric system (or at least we have the ability to, I think). @n-kai has some descriptions already in the document about how it applies, and I think this is part of the discussion in the context of AVA_VAN.

[The-Fiona]

Thank you Nils, I didn't know that. I am happy to hear that.

Yes, if they are "flattened" with their base PP, then the APE criteria can be used.

• Fiona

On 2019/05/03 02:16, Nils Tekampe wrote:

Just a short note: In the German scheme PP-modules are evaluated and certified (usually along with their base PP)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/biometricITC/cPP-biometrics/issues/160#issuecomment-488978999, or mute the thread https://github.com/notifications/unsubscribe-auth/AJBFWYJTW3G3JZ7RW2GL3MLPTPRDVANCNFSM4HJVDIRQ.

-- Fiona Pattinson, CISSP atsec information security corporation Cell:+1 512 8253083 / Office:+1 512 6157382

[n-kai]

I don't know the final conclusion of this issue but I approved all PRs created by @woodbe because all changes can be undone easily and moving to public review is more important for me.

[woodbe]

Closing as current path is PP-Module