Technology Evaluation Centers, Inc. Request for Information/Proposal Requirements Research Instructions RFI Rating Legend Format Response Explanation ● The top of the RFI tab contains six response columns. SUP Supported as delivered "out-of-the-box" ● TEC analysts developed the RFI based on past experience and research into the widest and deepest range of possible requirements. MOD Supported via modifications (screen configurations, reports, GUI tailoring, etc) 3RD Supported via a third party solution CST Supported via customization (changes to source code) FUT Will be supported in a future release NS Not supported Priority 0 to 10, where 10 is most important Mandatory Yes, only for "must-have" factors RFI Example Vendor Responses Hierarchy Criterion ● Complete the RFI worksheet by placing an X in the appropriate column for each criterion. 1 Module 1 ● The Xs represent the current state of a product or service. 1.1 Category of Module 1 1.1.1 Subcategory of Category 1 1.1.1.1 Criterion 1 1.1.1.2 Criterion 2 1.1.1.3 Criterion 3 1.1.1.4 Criterion 4 1.1.1.5 Criterion 5 1.1.1.6 Criterion 615Don't forget to indicate your priorities and mandatory requirements for modules, categories, subcategories, and criteria. RFI Example Priority (0-10) Mandatory (Y/N) SUP MOD 3RD CST FUT NS 9 Y 5 Y 10 Y 1 N X 5 Y X 5 N X 10 N X 7 N X 9 Y X User Responses ● Use the Priority column to indicate how important a particular criterion or entire group of criteria (module or category) is for your organization. ● The Mandatory column is useful for indicating absolute requirements. Note that a "Yes" would mean a vendor/provider fails if it does not support that criterion or group of criteria. It is often useful to use "No" as the general default response and only change to a "Yes" for an absolutely critical item. Technology Evaluation Centers Inc. Public Key Infrastructure (PKI) Functional and Technical Worksheet Hierarchy Criteria Priority (0-10) Mandatory (Y/N) SUP MOD 3RD CST FUT 1 PKI Functionality 1.1 Key Life Cycle Managemnt 1.1.1 Certificate Revocation 1.1.1.1 Certificate Revocation List Support 1.1.1.2 CRL Scalability 1.1.1.3 Off-Line Revocation Checking Capability 1.1.1.4 Handling Revoked and Expired Certificates 1.1.1.5 Verification of Historical signatures 1.1.2 Key and Certificate Update This category contains 5 criteria below it.1.1.3 Key Backup /Recovery This category contains 2 criteria below it. 1.1.4 Password Management This category contains 3 criteria below it. 1.1.5 User Initialization This category contains 2 criteria below it. 1.1.6 Key Pairs This category contains 3 criteria below it. 1.2 Cryptographic Algorithms This category contains 33 criteria below it. 1.3 Policy Management This category contains 27 criteria below it. 1.4 Certification Authority This category contains 3 criteria below it. 1.5 Registration Authority This category contains 3 criteria below it. 1.6 Client Software This category contains 7 criteria below it. 1.7 PKI Management This category contains 15 criteria below it. 1.8 Log Analysis This category contains 2 criteria below it. 1.9 Reporting This category contains 4 criteria below it. 1.1 Administration This category contains 6 criteria below it. 2 PKI Technology 2.1 Architecture 2.1.1 Simple PKI Architectures 2.1.1.1 Single CA 2.1.1.1.1 Single CA Support 2.1.1.1.2 Revocation Support 2.1.1.2 Basic Trust Lists This category contains 2 criteria below it. 2.1.2 Enterprise PKI Architectures This category contains 6 criteria below it. 2.1.3 Hybrid PKI Architectures This category contains 11 criteria below it. 2.2 Platforms This category contains 28 criteria below it. 2.3 Applications Support This category contains 92 criteria below it. 2.4 Smart Card /Biometric Support This category contains 5 criteria below it. 2.5 Scalability This category contains 2 criteria below it. 2.6 Interoperability This category contains 54 criteria below it. 2.7 Regulatory Compliance This category contains 5 criteria below it. 2.8 Outsourced certificate services This category contains 4 criteria below it. 2.8.5 WAP Server CertificatesNS Comment Certificate revocation is an extremely important capability, as this is the primary means by which user certificates are removed from the PKI. Revoked certificates should be placed on a certificate revocation list (CRL), which is then distributed through a public directory (typically the same directory as the valid public key certificates). It is important to note that merely publishing a CRL is not sufficient; the appropriate application security software must verify whether a certificate is still valid by checking the CRL. Certificate revocation is necessary when a user loses their private key material, or such material is otherwise compromised, stolen, etc. The PKI should provide the ability to automatically issue a certificate revocation list containing all revoked certificates. PKI should provide a revocation solution that is scalable to millions of users (i.e. CRL distribution points). PKI should allow users to perform revocation checking of certificates while off-line (not connected to a network). PKI should ensure that a user cannot make use of a revoked and expired certificate. PKI should allow revoked and expired certificates to be optionally on the CRL to allow verification of historical signatures. Key and certificate update features enable periodic refreshing of keying material, whereby new key pairs are generated to replace existing (expired) keys. This reduces the risk of various attacks on a user’s keys. Certificate expiration also enables certificate issuers to control how long a given user’s certificate will be valid. For example, employee certificates might be issued with a longer lifetime than agent certificates. It is very important to ensure that keys are actually updated prior to their expiration.Key backup/recovery enables a user to recover their key/certificate material when the user forgets his password, which protects material in his local environment. It also enables system administrators to gain emergency access to protected data. A comprehensive PKI architecture will typically employ two key pairs per user. In this case, only the encryption key pair should be backed-up. The signing key pair should never be backed-up in order to support nonrepuddiatio of their digital signature. It is important that password rules exist and enforceable by the administrator. User initialization should be an easy and automated process for users. A PKI solution must provide a minimum of two key pairs: one for signing and one for encrypting. A back-up of the encryption private keys will be securely stored so encrypted documents may be historically retrieved. The signing private key will exist only on the key token or profile issued to the individual. This provides support for both non-repudiation for digital signatures and the key recovery requirements for encrypted documents. The solution must provide a means for archival of private decryption keys, and support for the recovery of a private decryption key on request. An organization needs to establish what its security practices will be and enforce the adherence to those policies. The certification authority is a trusted entity whose responsibility is certifying the authenticity of users. In creating certificates, CA's act as agents of trust in a public key infrastructure. CA's create certificates for users by digitally signing set of data, such as the user’s name, a public key of the user, the validity period and the specific operations for which the key is to be used, among other items. The CA's signature on a certificate ensures that any tampering with the contents of the certificate can be easily detected. As long as users trust a CA and its business policies for issuing and managing certificates, they can trust certificates issued by the CA.Registration authority should be easy to use, accommodate different levels of administration and allow remote administration. The value of a PKI is tied to the ability to use intelligent application software that operates consistently and transparently across the all the applications on the desktop. This client-side software must be able to: validate the CA's signature on certificates and ensure signature validity by checking a CRL every time a certificate is used by a user; support non-repudiation by generating the key pairs used for digital signature on the user’s computer; support non-repudiation by ensuring that the signing keys are never backed-up and remain only under the user’s control at all times; monitor the user’s key pairs to ensure that they are updated before expiry; automatically and transparently handle the updating of the user’s key pairs; keep track of a history (on the user’s desktop) of all the private decryption keys ever used by that user to ensure that the user can decrypt data encrypted with previous key pairs; automatically and transparently navigate the key The most basic PKI architecture is a single CA that provides all the certificates and CRL's for a community of users. In this configuration, all users trust the CA that issued their own certificate. By definition, new CA's cannot be added to the PKI. Since there is only one CA, there are no CA trust relationships. The users accept only certificates and CRL's issued by their CA. As a result, certification paths can be constructed with single certificate and a single CRL. Since all certificates are user certificates, path analysis will not include information that decribes or limits CA trust relationships. It's the most simple form of path analysis. While the simplest to implement, this architecture does not scale easily to support very large or diverse user communities. The single CA PKI presents a single point of failure. Compromise of the CA invalidates the trust point information and all certificates that have been issued in this PKI. Every user must be informed The trust list is the most straightforward enhancements to the single CA architecture. In this architecture, more than one CA provides PKI services but there are no trust relationships between CA's. In this model, for example, Alice maintains a list of CA's that she trusts. She trusts valid certificates issued by any of them. New CA's can be added to the PKI by modifying the trust list. As with a single CA, there are no CA trust relationships. The users accept only certificates and CRL's issued by a CA in their trust list. As a result, one certificate and one CRL are all that is needed for any user. However, this is complicated slightly by the increase in the number of trust points. The primary advantage of this architecture is simplicity. There are no certification paths, just single certificates. In addition, the mechanics of adding a new CA to the PKI are very straightforward, Alice simply adds one more CA to her list of trust CA's. There are important disadvantages, however. Alice added the new CA to her trust list out of expediency because she wanted to communicate with Carol. However, Alice should have investigated the new CA before she added it to her trust list. In addition, It is critical that different modules of the PKI can be hosted on a variety of platforms. This is mainly driven by customer requirements (existing platforms, trained workforce) and marketing factors (partnership, comarkeeting)This public key infrastructure (PKI) will be used to provide authentication, confidentiality, non-repudiation, and privacy for a variety of applications running on multiple hardware platforms. Encryption and digital signature technology provides many security needs such as data confidentiality, integrity, authentication, and non-repudiation. It is important that the company providing this technology is a strong corporate entity. The public key infrastructure will consist of hardware and software to issue and revoke keys mapped to X.500 objects, and software development tool kits for developing client and server applications. The PKI will use public key encryption and digital signature technologies to ensure the authenticity and integrity of sensitive information in electronic transactions, to protect the confidentiality of such sensitive information and to support non-repudiation. It will provide a range of services to its users, including digital signature key management services, confidentiality, certificate management services, directory services, end-entity initialization services, support personal tokens if required, and non-repudiation PKI provides outsourcing services for WAP certificates.