Common Criteria compliant installation

PKIF Users:

• Application developers -- Persons who will be developing applications that use PKIFv2.
• System administrators -- In most cases application developers will be administrators on their development machines, if this is not the case PKIF users are system administrators who administer development machines.
• System administrators -- In this case PKIF user is the system administrator who administers a machine that has an application installed which uses PKIFv2.  In this case the administrator will have to follow guidance provided by application developers which should include PKIFv2 guidance.
  

PKIFv2 can be downloaded from source forge website at http://pkif.sourceforge.net/.   To verify the integrity of PKIFv2 distribution users (application developers) can contact PKIFv2 development team at pkif_support@cygnacom.com to request hash value for PKIFv2 distribution package and hash calculating tool to be sent via a signed email.

PKIFv2 is undergoing Common Criteria evaluation on two Operating Systems:

Microsoft Windows Server 2003; SP 1

Red Hat Enterprise Linux 4 (RHEL) WS Update 1

For PKIFv2 to be in evaluated configuration it has to be installed on one of the Operating Systems listed above.  Installation instructions for PKIFv2 can be found here.

PKIFv2 users (application developers) can subscribe to PKIFv2 user list at http://pkif.sourceforge.net/support.html to receive  security-related notifications.  PKIFv2 user can report security-related flaws using email pkif_support@cygnacom.com address.   

Assumptions placed on IT and Non-IT environment

• It is assumed that PKIFv2 will be properly installed and configured to address the objective of PKIFv2 being installed and configured properly for start up in a secure state.
• It is assumed that the attack potential ( perceived potential for success of an attack, should an attack be launched, expressed in terms of an attacker's expertise, resources and motivation) on PKIFv2 will be low to address the objective of having Identification and Authentication functions of PKIFv2 being designed for a minimum attack potential.
• It is assumed that  environment provides PKIFv2 with appropriate physical security, commensurate with the  value of the IT assets protected by the PKIFv2.  This addresses the objective that an acceptable level of physical security will be provided so that the TOE cannot be tampered with or be subject to side channel attacks such as the various forms of power analysis and timing analysis.
• It is assumed that administrators are non-hostile, appropriately trained and follow all administrator guidance to address the objectives that the sites which are using PKIFv2 will ensure that administrators are non-hostile, appropriately trained and follow all administrator guidance.
• It is assumed that TOE users (application developers) are non-hostile and follow all user guidance to address the objective that sites using the TOE will ensure that TOE users are non-hostile and follow all user guidance. 
• Security Objectives for IT Environment can be found here

Important Notes:

• PKIFTSP (Timestamp functionality)  is not part of evaluated PKIFv2.
• It is the responsibility of the developer to check the sizes of the objects passed to a Decode operation.  PKIFv2 loads all objects into memory to perform decoding.  Thus, the size of object that can be handled is highly dependent on the platform on which the application using PKIFv2 is deployed, e.g. the acceptable size for an application running on a machine with 1GB of RAM will be significantly larger than the acceptable size for an application running on a machine with 64MB of RAM.  If a machine doesn't have big memory and a large object is passed to the Decode function the system will slow down and might become unresponsive due to insufficient memory.
• Users (application developers, system administrators) in their administrative capacity should periodically monitor the event log (for trust anchor-related application pop-up system events) as well as monitor the contents of the trust anchor store to verify that  an attacker did not gain control of the store.  If an unauthorized user gains access to the the trust store all certificate verification operations will be suspect because the root might have been introduced by the unauthorized user. 
• Users (application developers, system administrators) in their administrative capacity should periodically confirm the system time is correct.  If the system time is incorrect the results of certificate validation might not be correct because at the correct time the certificate might be expired/revoked but at the incorrect time the certificate might be good.
• PKIFv2 does not perform any checks to ensure that en application has provided an invalid pointer to an object that should be used as a parameter.  If an invalid pointer is provided to PKIF it will throw an exception and not complete desired operation.
• CRLs retrieved via LDAP and HTTP may not exceed 100MB,  certificates retrieved via HTTP may not exceed 7MB, certificated retrieved from an LDAP directory may not exceed 20k.   If any of the objects are greater then the limit PKIF does not process them.  The reason for the limit is denial of service attack.
• Access to system critical items such as LDAP, CSPs, NSS, etc must be restricted to system administrators.  Any modifications to these systems components should be done by authorized personnel only.  If any of the items above are modified the results of certificate verification might not be trusted because the crypto, access to LDAP, might be compromised.
• PKIFv2 uses cryptographic functionality provided by Microsoft CAPI and NSS.  Both Microsoft CAPI CSP and NSS CSP are FIPS 140-2 validated.
• Only the electronic download of the guidance documentation should be used in the evaluated configuration.  The guidance documentation download is provided with a SHA1 hash value to verify the integrity of the download