The following terms are frequently used in Mozilla discussions relating to CAs and certificates.
AV (address validation) -- Many CAs issue end entity certificates to individuals for use with S/MIME email for which the applicant need only demonstrate that they own and/or control the email address named in the certificate. For example, the owner of the "email@example.com" address could obtain an AV certificate for that address based on their demonstrating to a CA that they owned or controlled the email address in question, e.g., by responding to email addresses sent to an email sent to that address. We can refer to such certificates as address-validated or AV certificates.
More formally we can define AV certificates as certificates containing an emailAddress attribute or Subject Alternative Name extension with a value (or values) apparently corresponding to an RFC 822 email address, for which the CA makes claims (e.g., in the CPS) that it has in some way validated that that address in question is owned and/or legitimately controlled by the cert subscriber, and for which the CA makes no claims as to the validity of any individual identity stored in the Common Name attribute of the certificate.
Note that "AV" is not a common industry term, but is newly-coined by analogy with "DV", "IV", etc. Some people use the term "DV" loosely to cover this case, but arguably it deserves a term of its own.
DV (domain validation) -- Many CAs issue end entity certificates for SSL/TLS-enabled sites for which the applicant need only demonstrate that they own and/or control the domain in question. For example, the owner of the "example.com" domain could obtain a DV SSL certificate for "www.example.com" based on their demonstrating to a CA that they owned or controlled the domain in question, e.g., by responding to email addresses sent to an email sent to the administrative contact listed in the whois database for that domain. Such certificates are informally referred to as domain-validated or DV certificates.
More formally we can define DV certificates as certificates containing a Common Name (CN) attribute or Subject Alternative Name extension with a value (or values) apparently corresponding to one or more actual Internet domains, for which the CA makes claims (e.g., in the CPS) that it has in some way validated that the domain(s) in question are owned and/or legitimately controlled by the cert subscriber, and for which the CA makes no claims as to the validity of any organizational identity stored in the Organization attribute of the certificate.
EV certificates can be considered a special subset of OV certificates, but in practice the two types of certificates are considered to be distinct.
IV (individual validation or identity validation) -- Many CAs issue end entity certificates to individuals for email, SSL/TLS client authentication, and other uses, for which the applicant is required to supply some sort of evidence as to their identity (e.g., by presenting themselves in person with a copy of their national identity card). These are commonly referred to as identity-validated or IV certificates.
More formally we can define IV certificates as certificates containing a Common Name (CN) attribute with a value apparently corresponding to an actual named individual, for which the CA makes claims (e.g., in the CPS) that it has in some way validated that that value corresponds to the individual identity of the certificate subscriber.
Note that some people use "IV" as a synonym for "OV" when referring to certificates issued to organizations. However it's arguably more clear to use "IV" to refer only to certificates issued to individuals.
Note that an IV certificate could also contain an email address in addition to the individual identity information. Mozilla policy requires that email address to be validated to the same or greater degree as for a AV certificate.
NSS (Network Security Services) -- The open source cryptographic library developed as part of the overall Mozilla project and incorporated into Firefox, Thunderbird, and other Mozilla-based products. NSS includes a built-in list of root CA certificates and associated metadata, most notably the so-called "trust bits"; this data is distributed as a shared library (nssckbi.dll on Windows). Inclusion of particular root CA certificates in NSS and default settings of trust bits are subject to the approval of the Mozilla Foundation according to the Mozilla CA policy.
OV (organization validation) -- Many CAs issue end entity certificates to organizations (corporations, government agencies, NGOs, etc.) for SSL/TLS-enabled sites, code signing, and other uses, for which the applicant is required to supply some sort of evidence that they are authorized to act for the organization in obtaining the certificate. These are informally referred to as organization-validated or OV certificates.
More formally we can define OV certificates as certificates containing an Organization (O) attribute with a value apparently corresponding to an actual organizational entity (i.e., as opposed to a value like "Not validated"), for which the CA is makes claims (e.g., in the CPS) that it has in some way validated that that value corresponds to the organizational identity of the certificate subscriber.
Note that an OV certificate could also contain one or more domain names. Mozilla policy requires those domain names to be validated to the same (or greater degree) as for a DV certificate.
Note that EV certificates are a special subset of OV certificates for which the CA performs the validation according to an industry-wide standard. However in practice OV and EV certificates are treated as distinct and separate certificate types, and "OV" implies "not-EV".
PSM (Personal Security Manager) -- A Mozilla component that provides the UI and other functions by which Firefox and other Mozilla-based client products use the facilities of NSS. In particular, PSM determines whether to present a special UI for EV certificates, and stores metadata (e.g., the EV policy OID) for roots that are approved (per the Mozilla CA policy) to have the EV UI displayed for EV certificates issued under their hierarchies.
Trust bits -- Metadata associated with a root CA certificate in NSS that determines whether end entity certificates issued under that root's hierarchy will be recognized by NSS as valid for various purposes. Currently there are three trust bits, for SSL/TLS, S/MIME email, and code signing.
Registration Authority Terminology
The following terminology is used when discussing Registration Authorities (RAs).
Registration: The tasks surrounding the subscriber account. These tasks typically include application processing, verification, requests for certificates and delivery of certificates. This does not include issuance of certificates (issuance may only be performed by the CA).
Registration Authority: An entity that performs the Registration Role.
In-House: The RA is in the same organization operating the root CA.
Third-Party: The RA is a third party external to the root CA organization.
Private: The RA issues certificates only to entities affiliated with the RA's organization.
Public: The RA issues certificates to entities not affiliated with the RA's organization.
There are three relevant combinations:
- In-house RA: This is the case where both the RA and CA are part of a single legal entity.
- Third-party private (or enterprise) RA: This is the case where the third-party RA may only perform the Registration Role for employees of their organization.
- Third-party public (or reseller) RA: In this case the third-party RA performs the Registration Role for other entities not affiliated with their organization.
Subordinate CA Terminology
The following terminology is used when discussing subordinate CAs. For more information see the Subordinate CA Checklist.
In-House: The subordinate CA is operated by the same organization operating the root CA.
Third-Party: The subordinate CA is operated by a third party external to the root CA organization.
Private: The subordinate CA issues certificates only to entities affiliated with the sub-CA organization.
Public: The subordinate CA issues certificates to entities not affiliated with the sub-CA organization.
There are four possible combinations:
- In-house public subordinate CAs: This is the case where a commercial CA establishes one or more internally-operated subordinates to offer certificates of a particular type (e.g., EV vs. non-EV certificates, or SSL certificates vs. email certificates) to the general public.
- In-house private subordinate CAs: This case would cover CA organizations that establish subordinate CAs for internal testing or other internal purposes.
- Third-party public subordinate CAs: In this case the root signs subordinate CAs for organizations who operate the sub-CA to sign certificates for other entities not affiliated with their organization. One example is a commercial CA which establishes one or more subordinate CAs to be operated by third-party organizations acting as Certificate Service Providers (CSP). Another example is a government-sponsored root CA where the organization running the root CA delegates to other organizations the task of issuing end entity certificates to the general public. For example, there might be a separate organization authorized to issue certificates for general business purposes, another organization issuing certificates specifically within a vertical industry sector like financial services, a third organization to issue certificates to individuals, and so on.
- Third-party private (or enterprise) subordinate CAs: This is the case where a commercial CA has enterprise customers who want to operate their own CAs for internal purposes, e.g., to issue SSL server certificates to systems running intranet applications, to issue individual SSL client certificates for employees or contractors for use in authenticating to such applications, and so on.