8.3 Draft October 2011 Updates to sections 1.3.6, 1.5.2, 3.3.1, 4.9.7, 6.1.5, 10 and 10.8 -- LM PMA 8.4 April 2012 Updates to sections 1.2, 2.2.1, 3.2.3.1, 5.3.2, 6.1.5, 7.1.6, and 8.4 to improve alignment with CertiPath’s recent CP revisions; and minor grammatical changes throughout which add clarity to the existing requirements. Updates made to Bibliography to add references and to correct broken hyperlinks. -- LM PMA 8.5 November 2012 Updates to improve alignment with CertiPath’s CP, incorporating many of their 2012 revisions. -- LM PMA 8.6 August 2013 Updates to improve alignment with CertiPath’s CP, incorporating many of their 2013 revisions. -- LM PMA 8.7 April 2014 Updates to improve alignment with CertiPath’s CP, incorporating many of their later-2013 revisions. -- LM PMA 8.8 April 2015 Changes to numerous sections to support policy updates to the LM CP which were brought about due to the establishment of a new Bridge relationship with TSCP. -- LM PMA
OCSP Request Format Requests sent to Issuer PKI OCSP Responders are not required to be signed, but may be at the discretion of the Issuer PKI. See RFC2560 for detailed syntax. The following table lists the fields that are expected by the OCSP Responder. Field Value Version V1 (0) Requester Name DN of the requestor (required) Request List List of certificates as specified in RFC 2560 Request Extension Value None None Request Entry Extension Value None None OCSP Response Format See RFC2560 for detailed syntax. The following table lists which fields are populated by the OCSP Responder. Field Value Response Status As specified in RFC 2560 Response Type id-pkix-ocsp-basic {1 3 6 1 5 5 7 48 1 1} Version V1 (0) Responder ID Octet String (same as subject key identifier in Responder certificate) Produced At Generalized Time List of Responses Each response will contain certificate id; certificate status, thisUpdate, nextUpdate, Responder Signature sha-1WithRSAEncryption {1 2 840 113549 1 1 5} or sha256 WithRSAEncryption {1 2 840 113549 1 1 11} Certificates Applicable certificates issued to the OCSP Responder Response Extension Value Nonce c=no; Value in the nonce field of request (required, if present in request) Response Entry Extension Value None None
CA entries shall be populated with the caCertificate, crossCertificatePair, certificateRevocationList, cPCPS attributes, as applicable. User entries shall be populated with the userCertificate attribute containing the user’s encryption certificate. Signature certificate need not be published to the PKI Repository. BIBLIOGRAPHY The following documents were used in part to develop this CP: ABADSG Digital Signature Guidelines, 1996-08-01. ANSI X9.62 Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA), 2005-03-11 ANSI X9.63 Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport using Elliptic Curve Cryptography, 2001-11-20 CHARTER CertiPath PMA Charter FIPS 140-2 Security Requirements for Cryptographic Modules, 1994-01 FIPS 186-3 Digital Signature Standard, 2000-01-27 PKCS #12 Personal Information Exchange Syntax Standard, April 1997. RFC 2510 Certificate Management Protocol, Adams and Farrell, March 1999. RFC 2527 Certificate Policy and Certificate Practices Framework, Chokhani and Ford, March 1999. RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP, Myers et. al., June 1999. RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002 RFC 3647 Certificate Policy and Certificate Practices Framework, Chokhani, Ford, Sabett, Merrill, and Wu. November 2003. LM PMA Charter Lockheed Martin Public Key Infrastructure Policy Management Authority Charter For Operations CertiPath CP CertiPath Certificate Policy RFC 4122 A Universally Unique Identifier (UUID) URN Namespace, Leach, Mealling, and Salz, July 2005
Firewall Gateway that limits access between networks in accordance with local security policy. Inside threat An entity with authorized access that has the potential to harm an information system through destruction, disclosure, modification of data, and/or denial of service. Integrity Protection against unauthorized modification or destruction of information. A state in which information has remained unaltered from the point it was produced by a source, during transmission, storage, and eventual receipt by the destination. Intellectual Property Useful artistic, technical, and/or industrial information, knowledge or ideas that convey ownership and control of tangible or virtual usage and/or representation. Intermediate CA A CA that is subordinate to another CA, and has a CA subordinate to itself. Key Escrow A deposit of the private key of a certificate holder and other pertinent information pursuant to an escrow agreement or similar contract binding upon the certificate holder, the terms of which require one or more agents to hold the certificate holder's private key for the benefit of the certificate holder, an employer, or other party, upon provisions set forth in the agreement. [adapted from ABADSG, "Commercial key escrow service"] Key Exchange The process of exchanging public keys in order to establish secure communications. Key Generation Material Random numbers, pseudo-random numbers, and cryptographic parameters used in generating cryptographic keys. Key Pair Two mathematically related keys having the properties that (1) one key can be used to encrypt a message that can only be decrypted using the other key, and (ii) even knowing one key, it is computationally infeasible to discover the other key. Local Registration Authority (LRA) A Registration Authority with responsibility for a local community. Master Service Agreement Agreement between LM and Certipath. Memorandum of Agreement (MOA) Agreement between the LM PMA and an Entity allowing interoperability between the Entity Principal CA and the LM CA. Mission Support Information Information that is important to the support of deployed and contingency forces. Mutual Authentication Occurs when parties at both ends of a communication activity authenticate each other (see authentication).