This section explains the architecture underlying the distribution of VeriSign's public certification services, as well as certificate classes, certificate extensions, time stamping, and the VeriSign repository.
2.1.1 General Discussion of Certificate Issuance and Management
2.3 Certificate Class Properties
2.3.3 Certificate Subscriber (and Applicant) Private Key Protection
2.4 Extensions and Enhanced Naming
VeriSign's public certification services (PCS) are designed to support secure electronic commerce and other general security services to satisfy users' technical, business, and personal needs for digital signatures and other network security services. To accomplish this, VeriSign-authorized issuing authorities (IAs: see definitions) serve as trusted third parties, issuing, managing, suspending, and revoking certificates in accordance with published practices.
The management and administrative functions of VeriSign's PCS are established to accommodate a large, public, and widely distributed community of users with diverse needs for communications and information security. To assure users that VeriSign services are substantially uniform, a general statement of the management and administrative practices used to protect the integrity of VeriSign's PCS is described in the CPS. As a result of such practices, VeriSign's PCS accommodate a large and geographically dispersed community, enhancing users' trust in these services. The various logical entities of the system implementation of the PCS are described in CPS Section 2.5.
An IA acts as a trusted third party to facilitate the confirmation of the relationship between a public key and a named entity (see definition for naming). Such confirmation is expressly represented by a certificate: a message which is digitally signed and issued by an IA (see CPS Section 2.5). The high-level management of this certification process includes registration, naming, appropriate applicant authentication, issuance, revocation, suspension, and audit-trail generation. Naming may be performed principally by VeriSign or by another party. Naming of subscribers includes a registration process distinct from that used for certificate management which determines when certificates are valid and operational.
VeriSign currently offers three distinct levels of public certification services. Each level, or class, of certificate provides specific functionality and security features. Certificate applicants choose from this set of service qualities according to their needs; they must specify which class of certificate they desire. Depending on the class of certificate desired, certificate applicants may apply electronically or in writing to an IA, or they may be required to apply in person by contacting a local registration authority (LRA). Each certificate issued by an IA corresponds to a specific PCS trust level. There may be many IAs issuing certificates for a given trust level; these IAs may be differentiated by value-added services and practices suitable for differing communities.
In response to a certificate application, a certificate is then issued to the certificate applicant, or a draft of the certificate contents is sent to the certificate applicant. The certificate applicant must review the certificate or draft, determine its suitability for the certificate applicant's intended purpose, and, if satisfied, accept the certificate via the certificate registration process. The new subscriber agrees to be bound by the continuing obligations of this CPS.
Certificate management also includes the deactivation of certificates and the decommission of the corresponding private keys, through a process involving the revocation and suspension of certificates. Additional IA services may include the listing, distribution, publication, storage, and retrieval of certificates in accordance with their particular intended use.
VeriSign's public certification services support a variety of security mechanisms to protect communications and information assets. Certificates alone do not, however, constitute such a mechanism. Rather, VeriSign's PCS provide a framework within which security services may be used by other communicating parties. This framework uses digital signatures and their verification to facilitate the protection of communication and computer-based trade and commerce over open data networks and provide a means for determining whether security services are in fact providing the intended assurances.
Certificate-based security services may be used to counter threats to security in a user-defined environment. Users select security mechanisms, security technology, security service agreements, and PCS suitable for the users' anticipated levels of risk, to protect users' communications environments from compromise.
VeriSign's PCS currently use the RSA public key system for all certification-related purposes. However, VeriSign is committed to supporting other digital signature standards as market demand materializes for alternatives.
VeriSign's PCS are administered in such a way that certain PCS activities may be performed by parties other than VeriSign. Uniform quality of service is maintained, despite functional and physical distribution of service provision. The underlying principle of domain administration relies upon a strict delegation of authority. To accomplish this, VeriSign relies upon decentralized, auditable IA agreement for the performance of specific published practices.
Each IA is authorized by a superior IA to perform certain PCS in a prescribed manner. Each IA also acts as an LRA unless it delegates such responsibility. Some of these functions concern the creation of IAs, while others concern the execution of authorized procedures by an IA once a superior IA has granted approval. To enhance uniformity of PCS, superior IAs delegate specific duties. VeriSign's administration policies ensure that autonomous parties agree to execute practices, including the issuance and management of certificates, in a manner that will maintain the uniformity of VeriSign's PCS.
VeriSign currently supports three distinct certificate classes within its PCS. Each class provides for a designated level of trust. The following subsections describe each certificate class. Also, further detail is provided in Table 2 (Certificate Attributes Affecting Trust).
THE DESCRIPTIONS FOR EACH CERTIFICATE CLASS (INCLUDING WITHIN TABLE 2, BELOW) REFLECT APPLICATIONS AND COMMUNICATIONS SYSTEMS THAT HAVE BEEN OR ARE IN THE PROCESS OF BEING IMPLEMENTED BY USERS. THEY DO NOT REPRESENT AN ENDORSEMENT OR RECOMMENDATION BY VERISIGN OR BY ANY IA FOR ANY PARTICULAR APPLICATION OR PURPOSE, AND THEY MUST NOT BE RELIED UPON AS SUCH. USERS MUST INDEPENDENTLY ASSESS AND DETERMINE THE APPROPRIATENESS OF EACH CLASS OF CERTIFICATE FOR ANY PARTICULAR PURPOSE.
Description:Class 1 certificates are issued to individuals only. Class 1 certificates confirm that a user's name (or alias) and E-mail address form an unambiguous subject within the VeriSign repository. Class 1 certificates are communicated electronically to subscribers and added to his or her set of available certificates. They are typically used primarily for Web browsing and personal E-mail, to modestly enhance the security of these environments. They are also used to establish continuity in the sequence of communications (providing assurances that follow-up communications are from the same user). Class 1 certificates may also facilitate the provision of special benefits by certain third-party service providers such as Web site hosts when a certificate applicant optionally submits certain designated "Registration Field Information" (country, zip code, age, and gender) in the certificate application during enrollment, and such information is then made available to third party service providers via the subscriber's certificate.
Assurance level:Class 1 certificates do not facilitate the authentication of the identity of the subscriber. Rather, they merely represent a simple check of the non-ambiguity of the subject name within the VeriSign repository, plus a limited verification of the E-mail address. The subscriber's common name (and, when submitted, Registration Field Information) contained in a Class 1 certificate is considered nonverified subscriber information (NSI). THESE CERTIFICATES PROVIDE THE LOWEST LEVEL OF ASSURANCE OF ALL VERISIGN CERTIFICATES. THEY ARE NOT INTENDED FOR COMMERCIAL USE WHERE PROOF OF IDENTITY IS REQUIRED AND SHOULD NOT BE RELIED UPON FOR SUCH USES.
Description: Class 2 certificates are currently issued to individuals only. Class 2 certificates confirm that the application information provided by the subscriber does not conflict with information in well-recognized consumer databases. Class 2 certificates are typically used primarily for intraorganizational and interorganizational E-mail; small, "low-risk" transactions; personal/individual E-mail; password replacement; software validation; and on-line subscription services. VeriSign also offers different types of specialized-use Class 2 certificates intended to support other features such as software validation or object signing. Class 2 certificates may also facilitate the provision of special benefits by certain third-party service providers such as Web site hosts when a certificate applicant optionally submits Registration Field Information in the certificate application during enrollment, and such information is then made available to third party service providers via the subscriber's certificate.
Following the on-line submission of a Class 2 subscriber agreement to a VeriSign Class 2 local registration authority (LRA), pertinent certificate applicant enrollment data is confirmed against third-party databases. Based upon such confirmation, the LRA will either approve or reject the application (see CPS Section 5: Validation of Certificate Applications). Upon such approval, a postal address confirmation procedure is invoked by the IA (see CPS Section 5.1.4) except for certificates issued to non-VeriSign organizational LRAs.
Assurance level: Class 2 certificates may provide reasonable, but not foolproof, assurance of a subscriber's identity, based on an automated on-line process that compares the applicant's name, address, and other personal information on the certificate application against widely referenced databases. Confirmation is based upon VeriSign proprietary matching criteria of third-party databases against the information in the application.
ALTHOUGH VERISIGN'S CLASS 2 ON-LINE IDENTIFICATION PROCESS IS AN ADVANCED AUTOMATED METHOD OF AUTHENTICATING A CERTIFICATE APPLICANT'S IDENTITY, IT DOES NOT REQUIRE THE APPLICANT'S PERSONAL APPEARANCE BEFORE A TRUSTED PARTY (SUCH AS A LOCAL REGISTRATION AUTHORITY OR NOTARY). CONSEQUENTLY, THE DECISION TO OBTAIN, USE, OR RELY UPON A CLASS 2 CERTIFICATE SHOULD TAKE INTO ACCOUNT ITS RELATIVE BENEFITS AND LIMITATIONS, AND THE CERTIFICATE SHOULD BE USED ACCORDINGLY. FURTHER INFORMATION ABOUT THIS ON-LINE AUTHENTICATION PROCESS IS ACCESSIBLE FROM THE VERISIGN REPOSITORY AT https://www.verisign.com.
When submitted, Registration Field Information contained in a class 2 certificate is considered NSI.
Description: Class 3 certificates are issued to individuals and organizations.
Assurance level:Individual Class 3 certificate processes utilize various procedures to obtain probative evidence of the identity of individual subscribers. These validation procedures provide stronger assurances of an applicant's identity than Class 2 certificates. The practical uses and reliability of Class 3 certificates are bolstered by utilizing notaries (an existing, important, and legally-recognized authentication process). For business entity Class 3 certificates, the requirement for "out-of-band" communication with the business organization and confirmation of business entity information via third parties provide further assurance of trustworthiness.
2.2.4 Test Certificates
Test certificates may be issued by VeriSign for authorized testing purposes only. Test certificates are issued from the VeriSign Test CA, which is independent of the PCS and is controlled by the VeriSign Test CA CPS .Only authorized persons may use test certificates. Note: The information contained within a test certificate shall be considered NSI.
Table 2 describes certain properties of each certificate class. Each of the table's headings is described below.
|
Summary of Confirmation of Identity |
IA Private Key Protection |
Certificate Applicant and Subscriber Private Key Protection |
Applications implemented or contemplated by Users -See CPS Section 2.2. Disclaimer and Section 2.3.5. |
|
|
Class 1 |
Automated unambiguous name and E-mail address search | PCA: trustworthy hardware; CA: trustworthy software or trustworthy hardware | Encryption software (PIN protected) recommended but not required | Web-browsing & certain E-mail usage |
|
Class 2 |
Same as Class 1, plus automated enrollment information check plus automated address check | PCA & CA: trustworthy hardware | Encryption software (PIN protected) required | Individual and intra- and inter-company E-mail, on-line subscriptions, password replacement, software validation |
|
Class 3 |
Same as Class 1, plus personal presence & ID documents plus Class 2 automated ID check for individuals; business records (or filings) for organizations | PCA & CA: trustworthy hardware | Encryption software (PIN protected) required; hardware token recommended but not required | E-banking, corp. database access, personal banking, membership-based on-line services, content integrity services, E-commerce server, software validation; authentication of LRAAs; and strong encryption for certain servers |
TABLE 2 - CERTIFICATE PROPERTIES AFFECTING TRUST
Each class of certificate is characterized by a different level of the following properties: confirmation of identity (such as through personal presence or investigation), IA private key protection (and assurance of appropriate use), certificate applicant and subscriber private key protection, and operational controls. While the certificates (and VeriSign's supporting products and services) possess many other properties, those listed in Table 2 provide a framework for distinguishing some of their aspects that affect their relative trust. Each property is explained below:
This refers to various actions taken by the IA to validate certificate applicants' identity and confirm the information they provide during the application process. The type, scope, and extent of confirmation depends upon the class of certificate, the type of applicant, and other factors. The particular confirmation methods and their rigor depend upon the class of certificate. Confirmation is further described in CPS Section 5.
Each IA's private key is secured against compromise via trustworthy hardware products. However, Class 1 IAs (see Figure 4) may secure the secrecy of their private keys via encryption software alone. See CPS Section 4.1 (Key Generation and Protection).
The secrecy of the private keys of certificate subscribers (and applicants) must be protected through the use of encryption software or hardware tokens (such as smart cards or PC cards) as specified in this CPS. See CPS Section 4.1 (Key Generation and Protection) and the Key Protection FAQ at https://www.verisign.com/repository/PrivateKey_FAQ.
As VeriSign observes new PCS usage patterns, it will consider providing a specific infrastructure that responds to such patterns.
VeriSign will provide extended warranty protection under the NetSureSM Protection Plan to subscribers obtaining certificates on or after its effective date. Subject to the terms and conditions of the NetSureSM Protection Plan and CPS Section 11.2:
The NetSureSM Protection Plan is backed by United States Fidelity and Guaranty Company (USF&G). USF&G is an A rated insurance company and one of the top 25 largest insurers in the United States. See the NetSureSM Protection Plan for important details.
The NetSureSM Protection Plan is available in the VeriSign repository at https://www.verisign.com/repository/netsure. For further information, see the FAQ regarding the NetSureSM Protection Plan at https://www.verisign.com/repository/netsure_faq/.
Operational controls refer to the organizational, human resources, and other management-oriented controls implemented for each class of certificate. Such controls include limits on who is permitted to obtain certificates, requirements concerning the training and education of IA personnel, policies establishing the separation of duties within IAs, documentation requirements, and prescribed procedures and audits. Many of these controls are identified in CPS Section 3 (Foundation for Certification Operations).
The PCS facilitate the use of X.509 v1, v2, and v3 certificates. X.509 v3 certificates expand the capabilities of v1 and v2, including the ability to add certificate extensions. This capability, a standard component of VeriSign's PCS, augments the standard authentication services model.
The X.509 "Amendment 1 to ISO/IEC 9594-8:1995" defines a number of extensions. These provide various management and administrative controls useful for large-scale and multipurpose authentication. VeriSign's PCS exploit a number of these controls for the purposes intended by X.509. (Note: X.509-compliant user software is assumed to enforce the validation requirements of this CPS. IAs and VeriSign cannot guarantee that such software will support and enforce these controls.)
In addition, this CPS allows users to define additional "private" extensions for purposes or modes of use specific to their application environment. Definitions for service-oriented extensions to and practices for handling such information during certificate application, approval, and issuance, are specified in the VSP and in publicly available documents from relevant sponsoring organizations. Examples of private extensions implemented within the PCS for service-specific purposes include the software validation scheme exploited by some versions of Microsoft Windows® software and the Netscape Communications Corporation's scheme for SSL security technology.
The function of each extension is indicated by a standard OBJECT IDENTIFIER value (see definition for X.509). Additionally, each extension in a certificate is assigned a "criticality" true/false value. This value is set by the IA, possibly on the basis of information provided by the certificate applicant on the certificate application. This value must conform to certain constraints imposed by the organization responsible for the extension definition.
The presence of a criticality value of true upon a specific extension requires all persons validating the certificate to consider the certificate invalid if they lack knowledge of the purposes and handling requirements for any specific extension with criticality value of true. If the criticality value of such extension is false, all persons shall process the extension in conformance with the applicable definition when performing validation or else ignore the extension.
VeriSign's PCS use chains of certificates. Each IA in a VeriSign certificate chain performs particular procedures according to its assigned role in the VeriSign PKI (see CPS Section 2.5). There are three generic roles an IA may play: root registration authority, IA for another IA, and IA for subscribers. An IA must be a subscriber of another IA. Where an IA is its own root, its self-signed public key shall conform to X.509 v1 format. It can potentially be trusted (based-upon out-of-band authentication mechanisms) without recourse to additional validation during verification of digital signatures (see CPS Section 8 - Use of Certificates). When registered by a root registration authority, however, the IA's certificate may contain extensions.
IAs serving end-user subscribers may issue certificates containing extensions defined both by the X.509 Amendment 1 to ISO/IEC 9594-8:1995 and by sponsoring organizations such as Microsoft and Netscape (see CPS Section 2.4.2). ISO-defined extensions used in the VeriSign PCS, whose content is assigned by the applicable IA, are currently limited to the following extensions:
Briefly, the use of these extensions control the process of issuing and validating certificates. Table 3 describes which extensions are present in particular certificates.
The basic constraints extension serves to delimit the role and position an IA or end-user subscriber certificate plays in a chain of certificates. For example, certificates issued to CAs and subordinate CAs contain a basic constraint extension that identifies them as IA certificates. End-user subscriber certificates contain an extension that constrains the certificate from being an IA certificate.
The key usage extension serves to limit the technical purposes for which a public key listed in a valid certificate may be used within the VeriSign PCS. IA certificates may contain a key usage extension that restricts the key to signing certificates, certificate revocation lists, and other data.
The certificate policy extension limits a certificate to the practices required by (or indicated to) relying parties. The certificate policy extension, as implemented in the PCS, points its users to this CPS and qualifies appropriate usages (see CPS Section 2.4.9.1).
All end-user subscriber certificates, except for certain S/MIME v1 certificates, contain an additional "Organizational Unit" field: -an X.520 attribute- that contains a brief statement regarding liability and incorporates by reference the complete CPS, such as "OU= www.verisign.com/repository/CPS Incorp. by Ref.,LIAB.LTD(c)97 " (this references the primary URL of the CPS, notes that liability is limited, and includes a copyright notice). This or comparable information may be present in application-defined X.509 v3 extensions for display to users by "local" (non-VeriSign vendor controlled) means. Note: the content of this Organizational Unit field is abbreviated because of the X.509 limitation of 64 bytes. This usage of an Organizational Unit field will be retired when functional and consistent use of X.509 v3 extensions become ubiquitous.
When digital signature-verifying software or hardware (collectively, "verifying software") facilitates the acceptance and use of v3 certificate extensions, the verifying software will display both a reference to the CPS and a set of extensions that describe important portions of it. If the verifying software supports only limited or privately defined v3 extensions, the verifying software may then make use of those application-specific extensions, as appropriate, to equivalently disclose certain critical practice statement sections.
Figure 3 illustrates how VeriSign has implemented this approach within v3 certificates. Key elements in the figure are explained below.
FIGURE 3 - CERTIFICATES AND INFORMATION INCORPORATED BY REFERENCE
Extensions and enhanced naming are either fully expressed within a certificate or they are at least partially expressed in a certificate with the balance expressed in an external document incorporated by reference in the certificate (see definition of INCORPORATE BY REFERENCE).
The information contained in the enhanced Organizational Unit field is also present in the certificatePolicy extension, when present in a certificate. This CPS constitutes a "certificate policy" as defined by X.509 Amendment 1 to ISO/IEC 9594-8:1995. VeriSign, acting as a policy-defining authority, has assigned to the CPS an object identifier value which is present in the certificatePolicy extension. The definition of this "certificate policy" requires the use of a policy qualifier which VeriSign has defined to include pointer values, warnings, liability limitations, and warranty disclaimers as described in Table 3 and as follows.
Both computer-based pointers (using URLs or other identifiers and mechanisms) and English (human-readable) text or pointers are used, so that certificate users can easily locate and access the CPS and other relevant information.
Each certificate includes a brief statement detailing applicable limitations of liability and disclaimers of warranty, with a pointer to the full text of such warnings, limitations, and disclaimers in the CPS. Alternatively, such information may be displayed by a certificate-viewing function, possibly following a hypertext link to a message accessible by users or agents, rather than being embedded in the certificate.
The methods of communicating information (to be displayed by a user) are as follows: an enhanced naming organizational unit attribute; a VeriSign standard qualifier to a VeriSign-registered certificate policy (using a standard v3 extension); and other vendors' registered extensions (such as a Netscape-registered "Comment" extension).
An "enhanced" organizational unit attribute contains the string "OU= www.verisign.com/repository/CPS Incorp. by Ref.,LIAB.LTD(c)97", or similar string.
Table 3 describes the typical contents of certificate extensions and the qualifier types defined for the VeriSign CPS certificate policy identifier.
|
Name/Cert. Extension Fields |
Purpose & Description |
Accompanying English (or other human-readable) Text |
| General Extensions for CA and Subordinate CA | ||
| basicConstraints |
See CPS
Section 2.4.6 |
Non-Critical cA=TRUE |
| keyUsage |
See CPS
Section 2.4.7 |
Non-Critical keyCertSign (Bit 5 Set) cRLSign (Bit 6 Set) |
| General Extensions for End-User Subscriber | ||
| basicConstraints |
See CPS Section 2.4.6 | Non-Critical cA=FALSE |
| certificatePolicy | See CPS Section 2.4.8 |
Non-Critical See CPS Section 2.4.9.3 |
| VeriSign standard qualifier-Practices
Reference |
Contains text referring to the VeriSign repository (and in future versions of this CPS, certain non-VeriSign repositories), which holds the VeriSign CPS, CRL, and other information. | "This certificate incorporates by reference, and its use is strictly subject to, the VeriSign Certification Practice Statement (CPS), available in the VeriSign repository at: https://www.verisign.com; by E-mail at CPS-requests@verisign.com; or by mail at VeriSign, Inc., 2593 Coast Ave., Mountain View, CA 94043 USA Copyright (c)1996 VeriSign, Inc. All Rights Reserved. CERTAIN WARRANTIES DISCLAIMED AND LIABILITY LIMITED." (As of 5/15/97, the CPS is available by mail at VeriSign, Inc., 1390 Shorebird Way, Mountain View, CA 94043 USA) |
| VeriSign standard qualifier-cpsURLs | A single uniform resource locator indicating the source of this CPS. | "https://www.verisign.com/repository/CPS" or similar URL |
| VeriSign standard qualifier-NoticeID | An object identifier referring to a registered string whose content indicates information about warnings, cautions, warranty disclaimers, and limitations of liability regarding the use of VeriSign PCS certificates. It is intended to be displayed with every certificate within the user agent (e.g., computer or terminal) certificate viewing function (but it is not embedded in any certificate). | Registered string of value "WARNING: USE OF THIS CERTIFICATE IS STRICTLY SUBJECT TO THE VERISIGN CERTIFICATION PRACTICE STATEMENT. THE ISSUING AUTHORITY DISCLAIMS CERTAIN IMPLIED AND EXPRESS WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, AND WILL NOT BE LIABLE FOR CONSEQUENTIAL, PUNITIVE, AND CERTAIN OTHER DAMAGES. SEE THE CPS FOR DETAILS." |
| VeriSign standard qualifier-NSINotice | An object identifier referring to a registered string whose content indicates that the certificate contains data for which the IA provides no assurances of accuracy. | Registered string of value "Contents of the VeriSign registered nonverifiedSubjectAttribute extension value shall not be considered as information confirmed by the IA." |
TABLE 3: VERISIGN CERTIFICATE EXTENSIONS
Alternatively a certificate contains, in a User Notice certificate policy qualifier, a reference to the following text which is displayed by certain products:
This certificate incorporates the VeriSign Certification Practice Statement (CPS) by reference. Use of this certificate is governed by the CPS.
The CPS is available in the VeriSign repository at https://www.verisign.com/repository/CPS and ftp://ftp.verisign.com/repository/CPS; by E-mail at CPS-requests@verisign.com; and by mail at VeriSign, Inc., 1390 Shorebird Way, Mountain View, CA 94043 USA, Attn: Certification Services.
THE CPS DISCLAIMS AND LIMITS CERTAIN LIABILITIES, INCLUDING CONSEQUENTIAL AND PUNITIVE DAMAGES. THE CPS ALSO INCLUDES CAPS ON LIABILITY RELATED TO THIS CERTIFICATE. SEE THE CPS FOR DETAILS.
The CPS and this certificate are copyrighted: Copyright (c) 1997 VeriSign, Inc. All Rights Reserved
VeriSign's public certification services are implemented within a PKI-entity hierarchy composed of the following IAs:
Within the PKI-entity hierarchy, IAs are interrelated via the relationship of "location subordinate to", which indicates that one IA serves on behalf of another. An IA shall issue IA certificates using either general or enhanced authentication procedures (for IA validation), depending upon the certificate class of the end-user subscriber certificates issued by the last IA in the hierarchy.
In addition, IAs may delegate certain registration functions to one or more LRAs. The VeriSign PKI also includes the VeriSign naming authority and VeriSign repository. Figure 4 provides an overview of the VeriSign PKI. (LRAs are not included in Figure 4, to further simplify the figure).
Note: Figure 4 does not necessarily include all issuing authorities and other entities within the hierarchy. An updated topology of the hierarchy, including naming and configuration of its components is available at https://www.verisign.com/repository/hierarchy.
FIGURE 4 : SIMPLIFIED VERISIGN PKI HIERARCHY
The VeriSign root (VR) is a VeriSign-owned and -operated entity that issues certificates for PCA public keys. The VR approves the distinguished names of PCAs. The VR also serves as the apex of trust within the VeriSign PCS. Each PCA also self-signs its own public key and provides such self-signed public key to the VR during registration. Both parties also complete the then-currently required procedures specified in the VeriSign Security Policy (VSP).
The VeriSign root (VR) is a VeriSign-owned and -operated entity that registers PCAs by registering their public keys. The VR's duties are limited to approving the distinguished name of PCAs and validating PCAs (registering their self-signed public keys). The VR also serves as the apex of trust within the VeriSign PCS. It registers the certificate of each PCA by digitally signing each PCA certificate. Each PCA also self-signs its own public key and provides such self-signed public key to the VR during registration. Both parties also complete the then-currently required procedures specified in the VeriSign Security Procedures (VSP).
The VR's initial RSA key size is 2048 bits. A trustworthy hardware device (FIPS 140-1 Level 3 certifiable) is used to create, protect, and destroy the VR's private key. The VR's key pair may be replaced and the replacement public key published in the VeriSign repository. Certain shares (see CPS Section 3.17 - Secret Sharing) of the VR's private key are retained by non-VeriSign employees to enhance the trustworthiness and security of the VR, in accordance with the secret-sharing procedures detailed in this CPS.
Note: the VR is not yet implemented because its 2048 bit key size is not recognized by all necessary end-user software, among other reasons. Currently, each PCA acts as a root.
The PCAs serve as the highest-level active certification entities within the VeriSign PCS. The PCAs issue, suspend, and revoke certificates for all CAs within VeriSign's PCS. All PCAs are subordinate to the VR within VeriSign's PKI. Each PCA is owned and operated by VeriSign.
Each PCA's initial key size is 1024 bits. A trustworthy hardware device (FIPS 140-1 Level 3 certifiable) is used to create, protect, and destroy each PCA's private key. The purposes, assurances, services, and obligations of each PCA (and the rights and responsibilities of its certificate applicants, subscribers, certificate recipients, relying parties, and CAs/subordinate CAs within its certification chain) are presented in this CPS.
Cross-certification between VeriSign PCAs and comparable entities within non-VeriSign PKIs is permitted if (i) VeriSign determines that the non-VeriSign entity provides at least a comparable function and level of assurance and trustworthiness, (ii) cross-certification is expected to enhance the value of VeriSign's certificates to VeriSign subscribers, (iii) both entities have executed an appropriate VeriSign cross-certification agreement, (iv) VeriSign and the non-VeriSign entity have issued certificates to the other, (v) each party has accepted such certificate, and (vi) revocation and repository procedures are agreed upon between the parties.
Each CA is subordinate to one PCA and operates in accordance with this CPS and any specific constraints imposed by that PCA (which are consistent with this CPS). Class 1-3 CAs may issue, manage, and revoke end-user subscriber certificates, as permitted by this CPS. Class 2-3 CAs may also issue IA certificates to subordinate CAs, at VeriSign's sole discretion. Subordinate CAs may issue, manage, and revoke end-user subscriber certificates, as permitted by this CPS.
Each CA's (and subordinate CA's) initial key size is 1024 bits. A trustworthy hardware device (FIPS 140-1 Level 3 certifiable) is used to create, protect, and destroy the private keys of Class 2, and 3 CAs. CAs and subordinate CAs are generally owned and operated by VeriSign, but upon agreement between VeriSign and the other entity, VeriSign may authorize non-VeriSign CAs and their subordinate CAs (or non-VeriSign subordinate CAs that are subordinate to a VeriSign CA) to join the VeriSign PCS (see CPS Section 3.1).
Local registration authorities (LRAs) are entities that evaluate and approve or reject certificate applications. LRAs also have the authority to approve the revocation (or where authorized, suspension) of certificates. LRAs may employ LRA Administrators (LRAAs) to perform the work of the LRA. LRAs operate on behalf of and (within the context of the CPS) under the exclusive authority of a single IA (the VR, PCA or CA that actually issues the certificates). An IA may have more than one LRA.
Without otherwise limiting their authority, LRAs may rely upon the following for confirming certificate applicant information: (i) notarial acts that reasonably appear to be performed in good order and (ii) well-recognized forms of identification, such as passports and driver's licenses. Notaries may serve as LRAs if so designated by the applicable IA, but notaries are otherwise generally independent (they are not agents of LRAs, since they provide services to certificate applicants directly) and support certain validation functions for certificate applications see CPS Section 2.6 - Notaries; the Notary FAQ in the VeriSign repository at https://www.verisign.com).
Non-VeriSign organizational LRAs are LRAs not affiliated with VeriSign that are authorized to approve the issuance and revocation of certificates to affiliated individuals within the LRAÆs organization. For example, a company may become a non-VeriSign organizational LRA in order to approve (or disapprove) the issuance of certificates to its own employees and other affiliated individuals and may not approve the issuance of certificates to the general public.
Certificates issued by non-VeriSign organizational LRAs may only be issued to individuals whose affiliation with the LRA is ascertainable by the LRAA via appropriate internal documentation (such as human relations (HR) employee and independent contractor rolls). All certificates issued as a result of a non-VeriSign organizational LRA's approval of a certificate application shall contain a distinguished name that states the affiliation of its subject. Non-VeriSign organizational LRAs are exclusively responsible for approving or not approving certificate applications. Consequently, VeriSign and IAs disclaim all such responsibility.
LRAA requirements are presented in CPS Section 3.20.
A naming authority, called the VeriSign naming authority, coordinates the issuance of relative distinguished names (RDNs) for all VeriSign IAs. The VeriSign naming authority may also specify naming conventions for subject names within the VeriSign Repository which may vary by certificate class and by IA. These naming conventions may also vary between issuance and re-issuance/re-enrollment. Non-VeriSign IAs must either use the VeriSign naming authority, or establish or otherwise use a naming authority whose procedures are not in conflict with those of the VeriSign naming authority and do not register RDNs by the VeriSign naming authority.
The VeriSign repository is a publicly available collection of databases for storing and retrieving certificates and other information related to certificates. All IAs must utilize the VeriSign repository as the primary and official repository for all VeriSign PCS purposes. The VeriSign repository's content includes but is not limited to the following: certificates, CRLs and other suspension and revocation information, current and prior versions of the VeriSign CPS, and other information as prescribed by VeriSign from time to time.
The VeriSign repository will not alter any certificate or any notice of certificate suspension or revocation it receives in proper form from an IA, and it will accurately represent the content of such materials.
The VeriSign repository will act promptly to publish certificates, amendments to the CPS, notices of certificate suspension or revocation, and other information, consistent with this CPS and applicable law. The VeriSign repository is accessible at https://www.verisign.com and by other communications methods as may be designated by VeriSign from time to time.
VeriSign may publish both within and outside of the VeriSign repository a subscriber's certificate and CRL-related data. This CPS prohibits accessing any data in the repository (or data otherwise maintained by an IA) that is declared confidential by the CPS and/or by the VeriSign repository, unless authorized by VeriSign.
Notaries are generally outside of VeriSign's PKI (except as provided
in this CPS). However, notaries do serve identity-confirming and other
traditional notarial roles, such as by acknowledging certain types
of certificates (such as Class 3 individual certificates) and non-VeriSign
CA applications (see CPS
Section 3.1.1). For non-U.S. jurisdictions without notarial institutions,
any requirement in this CPS for the use of a notary must be witnessed by
an attorney, solicitor, embassy official, or other comparable authorized
legal professional. VeriSign reserves the right to determine whether any
particular notary or notarial institution satisfies the requirements of
this CPS.