Transcription
InCommon CertificationPractices StatementforCode Signing Certificates7 June 2011Version 1.0Latest version:7 June 2011This version:7 June 2011
Table of Contents1 INTRODUCTION. 41.1 Overview. 41.2 Document Name and Identification. 41.3 PKI Participants. 51.4 Certificate Usage. 51.5 Policy Administration. 61.6 Definitions and Acronyms. 62 PUBLICATION AND REPOSITORY RESPONSIBILITIES. 82.1 Repositories. 82.2 Publication of Certification Information. 82.3 Time or Frequency of Publication. 82.4 Access Controls on Repositories. 83 IDENTIFICATION AND AUTHENTICATION. 93.1 Naming. 93.2 Initial Identity Validation. 103.3 Identification and Authentication for Re-key Requests. 113.4 Identification and Authentication for Revocation Request. 114 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS. 114.1 Certificate Application. 114.2 Certificate Application Processing. 124.3 Certificate Issuance. 124.4 Certificate Acceptance. 124.5 Key Pair and Certificate Usage. 124.6 Certificate Renewal. 134.7 Certificate Re-key. 134.8 Certificate Modification. 144.9 Certificate Revocation and Suspension. 144.10 Certificate Status Services. 154.11 End of Subscription. 164.12 Key Escrow and Recovery. 165 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS. 165.1 Physical Controls. 165.2 Procedural Controls. 175.3 Personnel Controls. 175.4 Audit Logging Procedures. 185.5 Records archival. 195.6 Key changeover. 195.7 Compromise and disaster recovery. 195.8 CA or RA termination. 196 TECHNICAL SECURITY CONTROLS. 196.1 Key pair generation and installation. 206.2 Private Key Protection and Cryptographic Module Engineering Controls.206.3 Other aspects of key pair management. 21Page 2
6.4 Activation data. 216.5 Computer security controls. 226.6 Life cycle technical controls. 226.7 Network security controls. 226.8 Time-stamping. 227 CERTIFICATE, CRL, AND OCSP PROFILES. 227.1 Certificate profile. 227.2 CRL profile. 237.3 OCSP profile. 238 COMPLIANCE AUDIT AND OTHER ASSESSMENTS. 248.1 Frequency or Circumstances of Assessment. 248.2 Identity/Qualifications of Assessor. 248.3 Assessor’s Relationship to Assessed Entity. 248.4 Topics Covered by Assessment. 248.5 Actions Taken as a Result of Deficiency. 248.6 Communication of Results. 249 OTHER BUSINESS AND LEGAL MATTERS. 249.1 Fees. 249.2 Financial Responsibility. 259.3 Confidentiality of Business Information. 259.4 Privacy of Personal Information. 259.5 Intellectual Property Rights. 269.6 Representations and Warranties. 279.7 Disclaimers of Warranties. 279.8 Limitations of Liability. 279.9 Indemnities. 279.10 Term and Termination. 289.11 Individual notices and Communications with Participants. 289.12 Amendments. 289.13 Dispute Resolution Provisions. 289.14 Governing Law. 299.15 Compliance with Applicable Law. 299.16 Miscellaneous Provisions. 299.17 Other Provisions. 29. 30Page 3
1 INTRODUCTIONInCommon (“InCommon”) is an identity and trust community and services provider that offers optionalsubscription services for X.509 PKI certificates issued by an InCommon certification authority.Subscribers are institutions as defined in the InCommon Cert Services website (incommon.org/cert).InCommon verifies the identity of each Subscriber and the Internet domains for which they areauthoritative. InCommon outsources functions associated with public key operations which includereceiving certificate signing requests, requests for revoking and renewing digital certificates, and themaintenance, issuance, and publication of Certificate Revocation Lists (“CRLs”) and the operation of anOnline Certificate Status Protocol (“OCSP”) responder.1.1 OverviewThis InCommon Certification Practices Statement (CPS) outlines the legal, commercial, and technicalprinciples and practices InCommon employs in approving, issuing, and managing its certificate servicesunder the Intermediary CA Agreement (“Comodo Agreement”) between Comodo CA Limited (“Comodo”)and University Corporation for Advanced Internet Development (d/b/a Internet2) and its single-memberLLC, InCommon. Under this agreement, Comodo provides full operational support, under its own CPS,for a CA that is subordinate to the Comodo “AddTrust External CA.” This CA signs end-user certificatesfor entities authenticated by subscribing institutions. Subscribing institutions will take appropriate technicaland non-technical means to ensure that only properly identified entities are issued certificates.InCommon’s sole responsibilities are to verify the identity of the subscribing institution; identify specific individuals at the institution who will be responsible for how certificates willbe requested; and ensuring that subscribing institutions abide by the terms of their Subscriber Agreement withInCommon.The CPS is formatted and maintained in accordance with IETF PKIX RFC 3647. To preserve the formatof RFC 3647, some section headings do not apply and will contain the text “Not applicable” ("n/a") or “Nostipulation”. The RFC 3647 format is preserved to assist the reader in comparing and contrasting thevarious CPS documents provided by various CAs.Sections of this CPS refer to services or practices provided by Comodo under the Comodo Agreementand in accord with provisions with the Comodo AddTrust External CA “Certification Practice reements.php). Such sections will contain the text “Providedby Comodo as stated in the Comodo CPS and binding upon the Subscriber.” The phrase “issued byInCommon” is to be interpreted as “issued by the Comodo CA under the Comodo Agreement.”1.2 Document Name and IdentificationThis document is the InCommon Code Signing Certificate CPS version 1.0, which was approved forpublication on 7 June 2011 by InCommon's certification Policy Authority. There is no separateCertification Policy document; policy is incorporated within this document.The object identifier (cpOID) for this CPS is identified in Appendix B and will be included in end-entitycertificates issued by InCommon. The current version of the CPS is made available to the public throughInCommon's repository as described in Section 2 below.Revisions not deemed significant by InCommon's Policy Authority have minimal or no impact onsubscribers and relying parties using certificates, the CRLs, or the OCSP responder. Insignificantrevisions may be made without changing the version number of the CPS.Revisions that are deemed significant or may affect the use or trustworthiness of certificates will result inassignment of a new cpOID to this document.Page 4
Revisions to this document have been made as follows:DateChangesVersion1.3 PKI Participants1.3.1 Certification AuthoritiesCertification authorities issue public key certificates to subscribers. A certification authority: Conforms its operations to this CPS as amended, Revokes certificates upon request by an authorized person, Maintains and updates its OCSP on a regular basis, Publishes CRLs on a regular basis, Distributes issued certificates, and Notifies subscribers via email of expiring certificates that it has issued to them.1.3.2 Registration AuthoritiesInCommon manages its own Registration Authority (RA). Each Subscriber organization also managesand operates a delegated RA – comprising its Subscriber Registrars and any Delegated SubscriberRegistrars – that is responsible for activities under its own management control for its own organization.1.3.3 SubscribersSubscribers are research and education institutions, organizations, or other entities that use InCommon'sPKI services to acquire certificates that support transactions and communications.Subjects are identified in an issued certificate. The Requester controls the private key corresponding tothe public key listed in an issued certificate.Regardless of the Subject listed in the Certificate, the Subscriber always has the responsibility of ensuringthat the Certificate is only used appropriately.1.3.4 Relying PartiesRelying parties use InCommon's PKI service certificates to perform transactions, communications, orother functions at their own discretion.Digital certificates do not guarantee that a certificate holder has good intentions or that the certificateholder will be ethical. It is the Relying Parties‘ responsibility to independently examine each certificateholder to determine whether the certificate owner is ethical and trustworthy.1.4 Certificate UsageA digital certificate is formatted data that cryptographically binds an identified Subject to a public key. Adigital certificate allows an entity taking part in an electronic transaction to assert its identity to the otherparticipants in such a transaction. Certificates will only be issued to end users under this CPS.1.4.1 Appropriate Certificate UsesDepending on the certificate type, the certificates issued from an InCommon CA may be used forauthentication, encryption, access control, and digital signature purposes.1.4.2 Prohibited Certificate UsesCertificates may only be used in accordance with their intended purpose and in compliance with allapplicable laws and regulations including export laws as described in the Subscriber Addendum.Page 5
Certificates may not be used to complete or assist in performing any transaction that is prohibited by law.Digital certificates do not guarantee that a certificate holder has good intentions or that the certificateholder will be ethical.Certificates may not be used for any application requiring fail-safe performance systems such as theoperation of nuclear power facilities, air traffic control systems, weapon control systems, or any othersystem where a failure of the system could cause loss of life or property.1.5 Policy Administration1.5.1 Organization Administering the DocumentThis CPS is administered by the InCommon Policy Authority (PA). The InCommon PA is described in adocument available in the InCommon CA repository as described in Section 2.1.5.2 Contact PersonInCommon:Chief Operating Officer, InCommonc/o Internet21000 Oakbrook Dr, Suite 300Ann Arbor, MI 48104Email: incommon-admin@incommon.orgPhone: 734.913.42501.5.3 Person Determining CPS Suitability for the PolicyThere is no separate Certificate Policy document. The CPS combines both policy and practices.1.5.4 CPS Approval ProceduresInCommon's CPS (and any amendments made to it) are reviewed and approved by InCommon's PolicyAuthority with concurrence from its legal adviser and from Comodo. Amendments to the CPS may bemade by reviewing and updating the entire CPS or by publishing an addendum.1.6 Definitions and AcronymsAcronyms:CACertification AuthorityCPSCertification Practice StatementCRLCertificate Revocation ListCSRPKCS#10 Certificate Signing RequestMDCMultiple Domain CertificateOCSP Online Certificate Status ProtocolPKIPublic Key InfrastructurePKCS Public Key Cryptography StandardRARegistration AuthoritySGCServer Gated CryptographySSLSecure Sockets LayerTLSTransaction Layer SecurityURLUniform Resource LocatorX.509 The ITU-T standard for Certificates and their corresponding authentication frameworkPage 6
Definitions:ApplicantThe entity applying to become a Subscriber to the InCommon PKIservices. May also be used to refer to an individual submitting arequest for a certificate (see Requester below).CertificateA message that, at least, states a name or identifies the CA,identifies the Subject, contains the Subject’s public key, andcontains a serial number.Delegated SubscriberRegistrarAny other individual to whom the Subscriber Registrar subdelegates his or her permissions.Master RegistrarIndividuals within InCommon's Registration Authority who candelegate authority for certain Internet domains to up to 3 individualswithin a Subscriber organization.Registration AuthorityThe InCommon officer(s) who identify Subscriber Registrars and vetthe Internet domains for which Subscriber may issue CSRs.RegistrarThe generic term for an individual who may approve submittal of aCSR to the CA and has certain privileges to manage the certificatelife cycle. Master Registrar, Subscriber Registrar and DelegatedSubscriber Registrar are collectively Registrars and individually aRegistrar.Relying PartyAn entity that relies upon the information contained within theCertificate.Relying Party AgreementAn agreement that must be read and accepted by a Relying Partyprior to validating, relying on or using a Certificate and is availablefor reference in the InCommon PKI repository as described inSection 2.RequesterAn individual who submits a CSR either via the Comodo UserInterface (UI) or indirectly via the Comodo Application ProgrammingInterface (API).SubjectThe entity that has been named in a Certificate.SubscriberAn entity that has entered into an agreement with InCommon tomake use of InCommon PKI services.Subscriber AddendumA legal addendum to the InCommon Participation Agreement thatmust be read and accepted by an Applicant before becoming aSubscriber. The Subscriber Addendum binds the Subscriber and allagents of the Subscriber that manage or acquire certificates fromInCommon to its terms and conditions.Subscriber ExecutiveThe management officer at the Subscribing organizationresponsible for designating the organization's SubscriberRegistrars. The Executive is authorized as such in the InCommonparticipation agreement or by succession and is typically be filled bya CIO, VP of IT, or other senior administrative officer responsible forthe organization's information technology assets.Subscriber RegistrarAn individual that the Subscriber’s executive contact identifies toInCommon and InCommon registers with Comodo and providescredentials to allow approval of CSRs on behalf of Subscriber. ASubscriber Registrar may delegate his or her permissions toanother individual whom the institution wishes to allow to approvecertificate requests and manage certificate lifecycle generally.Page 7
Credentials may also be installed in an automated system for theissuance of end-entity certificates.2 PUBLICATION AND REPOSITORY RESPONSIBILITIESThis CPS is only one of a set of documents relevant to InCommon's certificate services. The list ofdocuments below is a non-exhaustive list of other relevant documents. The document name, location of,and status, whether public or private, are detailed below.Document Status LocationStatusLocationInCommon Code Signing CertificationPractices Statement (This document)PublicInCommon RepositoryInCommon Certificate Service SubscriberAddendum and InCommon ParticipationAgreementPublicInCommon RepositoryInCommon Certificate Service RelyingParty AgreementPublicInCommon RepositoryInCommon Policy AuthorityPublicInCommon RepositoryCode signingCA and Certificate ProfilesPublicInCommon Repository2.1 RepositoriesInCommon publishes this CPS, related documents and certificates in its PKI services repository athttps://www.incommon.org/cert/repository/. The InCommon Operations group maintains the repository.InCommon makes reasonable efforts to ensure that the information in its repository is accurate, updated,and correct. However, in no event shall InCommon be liable for any amounts beyond the limits set forthin this CPS.Parties accessing the repository agree to the terms posted in the repository in regard to its use of thedocuments and information on the repository. InCommon may revoke repository privileges for any partyfailing to comply with the terms on InCommon's website.2.2 Publication of Certification InformationCertificate information is published in accordance with the provisions of the CPS relevant to such acertificate. Certificate content is published by issuing the certificate. Revoked certificate information ispublished in CRLs by InCommon’s CA service provider and is available also by OCSP. Users and relyingparties should consult the CRLs or OCSP server prior to relying on information featured in a certificate.2.3 Time or Frequency of PublicationUpdates to the CPS are published in accordance with Section 9.12. Updates to the SubscriberAgreement, Relying Party Agreements, and other agreements posted in the repository are published asoften as necessary. Certificates are published upon issuance.2.4 Access Controls on RepositoriesThe information published in the InCommon repository (refer to section 2.1) is public information and maybe accessed freely by anyone visiting the site, provided they agree to the site’s terms and conditions asposted thereon. Read-only access to the information is unrestricted except as stated in section 2.1above. InCommon has implemented logical and physical security measures to prevent unauthorizedadditions, modification, or deletions of repository entries.Page 8
3 IDENTIFICATION AND AUTHENTICATION3.1 Naming3.1.1 Types of NamesInCommon Certificates are issued with an X.501 compliant non-null Distinguished Name (DN) in theIssuer and Subject Fields. Issuer Distinguished Names will identify Internet2 (InCommon's parentorganization) as the primary organization and InCommon as the organizational unit and common name.Certificate Subject Distinguished Names will identify the Subscriber as the primary organizational unit andoptionally may contain an organizational subordinate unit. The Subject will be in a name space owned byor under the administrative control of the Subscriber Institution which requested the issuance of the codesigning certificate.1 Details of certificate profiles for certificates may be found in the InCommon PKIrepository as stated in Section 2.Enhanced naming uses an extended organization field in an X.509v3 certificate to convey informationthrough an organizational unit field. InCommon certificates may include a brief statement describinglimitations of liability, limitations in the value of transactions to be accomplished, validation period, andintended purpose of the certificate and any disclaimers of warranty that may apply. The lack of suchinformation does not mean it does not apply to that certificate.To communicate information InCommon may define: An organizational unit attribute. An InCommon standard resource qualifier to a certificate policy. Proprietary or other vendors’ extensions.3.1.2 Need for Names to be MeaningfulInCommon uses non-ambiguous designations and commonly used semantics to identify both the Issuerof the Certificate and the Subject of the Certificate.3.1.3 Anonymity or Pseudonymity of SubscribersAnonymity is not allowed. For pseudonymity, no specification.3.1.4 Rules for Interpreting Various name FormsDistinguished Names in Certificates are X.501 compliant. For information on how X.501 Distinguishednames are interpreted, please see RFC 2253 and RFC 2616.3.1.5 Uniqueness of NamesCampuses should use Subject DNs that map uniquely to a single person/entity in perpetuity. However, ifthis is not possible, a campus must ensure that no two valid certificates containing the same Subject DNmap to different persons/entities. While Subject DNs in expired or revoked certificates may map todifferent persons/entities than currently valid certificates, this practice should be avoided wheneverpossible. Multiple certificates with different Subject DNs may map to the same person/entity.The use of the SubjectAlt Email address and/or SubjectAlt/OtherName/PrinipalName is optional inInCommon certificates. However, if these fields are used, InCommon requires that these fields bepopulated with identifiers such that each field maps uniquely to the same single person/entity.Campuses must ensure that all SubjectAltName identifiers map to a single person/entity throughout thelife of any valid certificate.InCommon recommends the use of the email field in the Subject DN to guarantee uniqueness but acampus may use any appropriate mechanism to guarantee that the Subject DN uniquely maps to a singleperson/entity for the period of time that a certificate is valid. If an email address is used in the Subject DN,the email address must also be populated in the appropriate SubjectAltName field.1 The Subject Name of a Certificate will at least contain a Country and Organization field, the exactcontents for any Subscribing Institution will be determined at registration time.Page 9
InCommon’s CA assigns certificate serial numbers, which appear in InCommon certificates and which areunique across all certificates issued by that CA.3.1.6 Recognition, Authentication, and Role of TrademarksInCommon does not permit the use of a name or symbol that infringes upon the intellectual propertyrights of another as stated in its subscriber agreements. However, InCommon does not verify or checkthe name appearing in a certificate for non-infringement. Subscribers are solely responsible for ensuringthe legality of any information presented for use in an InCommon CA issued certificate. When submittingor approving a CSR, InCommon subscribers represent that they are not interfering with or infringing uponthe rights of any third parties.InCommon does not arbitrate, mediate, or otherwise resolve any dispute concerning the ownership of anyintellectual property or a domain’s use of any infringing material. InCommon’s CA may reject a CSR orrevoke a certificate if it believes that any information in the certificate may be subject to infringementclaims or ownership disputes.3.2 Initial Identity ValidationInCommon validates the identity of Institutions that intend to issue end-user certificates. Institutions agreeto only issue end-user certificates that indicate affiliation with the identified organization. InCommon orComodo may refuse to issue an end-user certificate if it appears to be fraudulently issued. However itremains the Institution's responsibility to ensure that code signing certificates are issued to onlyappropriately
This document is the InCommon Code Signing Certificate CPS version 1.0, which was approved for publication on 7 June 2011 by InCommon's certification Policy Authority. There is no separate Certification Policy document; policy is incorporated within this document.
