Comments on the Draft CIMC PP

Refs: A. Draft Certificate Issuing and Management Components Protection
Profile, July 7, 2000

B. ISO/IEC PDTR 15446, Information technology -- Security techniques --
Guide for the production of protection profiles and security targets,
January 4, 2000

Following are comments on the reference A, which are presented in order
of importance:

# Major

1.  The CIMC PP is missing the "rationale" for the augmented assurance
    requirements for each Security Level and the evidence that the
    assurance component dependencies are satisfied for these additional
    assurance requirements.

2.  Sections 1.2.4 and 6.2, it is suggested that a Table mapping the
    various "functions" to "roles" for each Security Level would be
    appropriate under Section 6.2. Although it is clear that the
    Operator performs the function of system backup and recovery for
    Security Level 4, the Table would need to clarify which role(s) can
    or can not perform this function for Security Levels 1, 2 and 3.
    Similarly, although it is clear that the Auditor performs the
    function of viewing and maintaining audit logs for Security Levels 3
    and 4, the Table would need to clarify which role(s) can or can not
    perform this function for Security Levels 1 and 2. Depending on how
    these two particular functions are allocated to different roles,
    this will probably impact Section 1.2.4. For example, under
    paragraph 1.2.4.1, which role would be responsible for system backup
    and recovery and for viewing and maintaining audit logs?

3.  Section 2 and the security functional component FMT_SMR.2.3 from
    Section 6.2 mandates for all Security Levels that individual users
    must be assigned a unique identifier to support individual
    accountability. However, it is only at Security Level 3 and above
    that FIPS 140 requires identity-based authentication, but not for
    Security Levels 1 and 2, where it only mandates role-based
    authentication. The security functional component FMT_SMR.2.3 for
    Security Levels 1 and 2 should probably be modified.

4.  Section 6, why doesn't the CIMC PP contain any security functional
    component(s) from the TSF physical protection (FPT_PHP) and the fail
    secure (FPT_FLS) security families, which would seem to apply to a
    CIMC based on Annex C of reference B?

5.  Paragraph 6.1, security functional component FPT_CIMC.TSP.2 mandates
    that the TSF shall obtain a digitally signed third party timestamp.
    Although Table 4 mentions that "the capability to change the
    frequency of the timestamping event or the source of the timestamp
    shall be restricted to Administrators (Level 4)", nowhere in the
    document is it mentioned what security requirements should apply to
    a third party producing these timestamps. It is accepted that it is
    not within the scope of this CIMC PP to provide all the detailed
    security requirements for such a third party, but it should at least
    provide some minimal guidance.

6.  Paragraph 6.6, the security functional component FCO_NRO.CIMC.3
    could instead have been added through a refinement of the
    non-repudiation of origin (FCO_NRO) security functional family.

7.  Paragraph 6.6, the security functional component FCO_NRO.CIMC.4
    could instead have been added through a refinement of the import of
    user data with security attributes (FDP_ITC.2) security functional
    component.

8.  Paragraph 6.6.1, the security functional component FDP_CIMC.CSE.1
    should instead have been added through a refinement of the
    cryptographic key distribution (FCS_CKM.2) security functional
    component as discussed at paragraph 604.d of reference B.

9.  Section 6.7 fails to mention and mandate any security requirements
    for the generation, validation, protection, storage, import and/or
    export of "domain parameters" that are needed by some asymmetrical
    algorithms (e.g. DSA, Diffie-Hellman, Elliptic Curve, etc.), and how
    tightly should domain parameters be bound to public/private keys.
    Should "domain parameters" be generated/validated/stored within a
    cryptographic module that is in an FIPS-approved mode of operation?
    Should "domain parameters" be generated/validated/stored within the
    same cryptographic module generating cryptographic keys or in
    another cryptographic module, if so how should they be imported,
    exported, protected and/or bound to public/private keys? What
    Security Level would be required for the
    generation/validation/storage of "domain parameters"?

10. Paragraph 6.7.1 fails to mention and mandate any security
    requirements for the validation of keys (public or private) and when
    they should be validated. Should keys be validated within a
    cryptographic module that is in an FIPS-approved mode of operation?
    Should keys be validated within the same cryptographic module
    generating cryptographic keys or in another cryptographic module?
    What Security Level would be required for the validation of keys?

11. Paragraph 6.7.2, the security functional component FDP_ACF.CIMC.2
    could have instead been created through a refinement of the import
    from outside TSF control (FDP_ITC) security functional family as per
    paragraph 611 of reference B.

12. Paragraph 6.7.2 should mention something about how domain parameters
    should be bound to private keys while imported and during storage.

13. Paragraph 6.7.3 should mention something about how domain parameters
    should be bound to public keys during storage.

14. Paragraph 6.7.5, the security functional element FCS_CKM.CIMC.5.1
    should mention under what circumstances the TSF capability to
    zeroize plaintext secret and private keys within the TOE would
    apply.

15. Paragraph 6.10, although the three bullets are mentioned as examples
    of values that may be covered by a certificate revocation list
    profile, the value "extensions" is not being mandated in the two
    security functional components that follow.

# Minor

16. Many Tables in the document do not have a Title and are not
    numbered.

17. The Table of Contents should include a "List of Tables".

18. Paragraph 1.2.1, subparagraph 2 on "component keys" should indicate
    if component keys are "private" and/or "secret" keys.

19. Paragraph 1.2.1, subparagraph 3 on "certificate subject private
    keys" should have a third bullet explicitly addressing a CIMC that
    "generate public/private key pairs" and also "hold private keys" to
    enable key recovery since the exclusive "or" between the two
    existing bullets would seem to exclude this particular scenario.

20. Section 6, the second paragraph mentions that this section includes
    the "basic security requirements", a notion that is no longer
    applicable to this document.

21. Table 1 is missing the security functional elements FDP_ACF.1 from
    Section 6.4, FDP_CIMC_OCSP.1 from Section 6.13 and FMT_MOF_CIMC.6
    from Section 6.11. The security functional elements FDP_CIMC_CER.1
    and FDP_CIMC_CRL.1 are referring to the wrong CIMC PP Sections. The
    first security functional element FPT_CIMC_TSP.2 is in reality
    FPT_CIMC_TSP.1.

22. Paragraph 6.1, security functional component FAU_GEN.1.1,
    subparagraph b) still contains question marks after the word
    "basic".

23. Table 2 is missing the security functional elements FPT_CIMC_TSP.2,
    FDP_CIMC_OCSP.1 and FMT_MOF_CIMC.6. The security functional elements
    FDP_CIMC_CER.1 and FDP_CIMC_CRL.1 are referring to the wrong CIMC PP
    Sections.

24. Table 4 is missing the security functional element FMT_MOF_CIMC.6.
    The Identification and Authentication, the Certificate Registration
    and the Certificate Profile Management functions are referring to
    the wrong CIMC PP Sections.

25. Table 5, many functions are referring to the wrong CIMC PP Sections.

26. Paragraph 6.9, some FMT_MOF.CIMC.3.x security functional elements
    are wrongly numbered.

27. Paragraph 6.16.2.1.1 is missing the security functional elements
    FDP_SDI_CIMC.3 and FPT_CIMC_TSP.2.

28. Paragraphs 6.16.2.1.2 and 6.16.2.1.4 are missing the security
    functional element FPT_CIMC_TSP.1. In addition, some security
    functional elements are not in the right alphabetical appropriate
    order (i.e. FDP_SDI_CIMC.3 and FCO_NRO_CIMC.4).

29. Paragraph 8.3, the first three items in the table are security
    assurance components and are not security functional components,
    which is the intent for this particular rationale table. The next
    three security functional elements have since been deleted. The
    security functional elements FDP_ACF.1, FDP_CIMC_OCSP.1,
    FMT_MOF_CIMC.6 and FPT_CIMC_TSP.2 are missing.