MozillaWiki - User contributions [en]

CA/Required or Recommended Practices

2010-09-01T09:52:09Z

Vargaviktor: proposal section of Domain owned by a Natural Person added

== CA Recommended Practices ==

This page contains a draft set of recommended practices for CAs wishing to have their root CA certificates included in Mozilla products. In some cases these practices are specified or implied by the [http://www.mozilla.org/projects/security/certs/policy Mozilla CA certificate policy] and are mandatory for a CA to have its root certificate(s) included. In other cases the recommended practices are not mandatory per policy, but will help speed up a CA's application for inclusion and maximize the chances of its application being approved.

=== Publicly Available CP and CPS ===

CAs should supply the complete Certification Policy (CP) and Certification Practice Statement (CPS) containing sufficient information to determine whether and how the CA complies with the Mozilla policy requirements.
* The CP/CPS should be publicly available from the CA's official web site.
* The format of the CP/CPS document should be PDF or another suitable format for reading documents. CAs should ''not'' use Microsoft Word or other formats intended primarily for editable documents.
* The CP/CPS should be available in an English version.
* The CA should provide references to the CP/CPS sections (e.g., by section number and/or page number) that address the requirements of the Mozilla policy.

=== CA Hierarchy ===
A hierarchical structure of a single root with intermediate certs (subroots) is preferred. The single top-level root's public certificate is supplied for Mozilla's root list; the subroots are not. See [[CA:Recommendations_for_Roots]]

CAs that issue certificates under multiple subordinate CAs (i.e., under a root CA whose CA certificate is being requested for inclusion) or under multiple CA hierarchies (i.e., rooted at multiple root CAs, one or more of whose certificates is being requested for inclusion) should provide additional information as noted:
* The CA should provide a graphical or textual description of the CA hierarchy or hierarchies, including which subordinates are under which root CAs
* The CA should indicate the general types of certificates (i.e., for SSL/TLS servers, email signing/encryption, and code signing) issued by each subordinate CA under each root.
* Where a CP/CPS applies to multiple subordinate CAs and/or multiple CA hierarchies, the CA should indicate whether particular sections of the CP/CPS apply to different subordinates and/or hierarchies and, if so, what the differences are.

=== Audit Criteria ===
CAs should supply evidence of their being evaluated according to one or more of the criteria accepted as suitable per the Mozilla policy.
* The CA should indicate exactly which criteria they are being evaluated against (i.e., which of the criteria listed in the Mozilla policy).
* All documents supplied as evidence should be publicly available.
* Documents purporting to be from the CA's auditor (or other evaluator) should be available directly from the auditor (e.g., as documents downloadable from the auditor's web site).

=== Document Handling of IDNs in CP/CPS ===
If a CA allows the use of internationalized domain names (IDNs) in certificates (e.g., as issued for SSL/TLS-enabled servers), the CA should address the issue of homographic spoofing of IDNs in their CP/CPS, even if primary responsibility for dealing with this issue falls on domain registries. (This doesn't mean that the CAs must prevent such spoofing. It merely means that a CA should describe how it handles the issue of spoofing when authenticating the owner of a domain.)

=== Revocation of Compromised Certificates ===
CAs should revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid.

=== Verifying Domain Name Ownership ===
We rely on public documentation and audits of those documented processes to ascertain that the requirements of section 7 of the Mozilla CA Certificate Policy are met.

Section 7 of the [http://www.mozilla.org/projects/security/certs/policy Mozilla CA Certificate Policy] states: “for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf"

The CA's public documentation needs to provide sufficient information describing the steps taken by the CA to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the domain name.

[http://en.wikipedia.org/wiki/WHOIS WHOIS] is used by some CAs as a source of information for checking
ownership/control of the domain name for SSL certificate applications. WHOIS information may be subject to compromise. CAs are responsible for implementing appropriate methods to reduce the risk of compromise. For example, direct command line, HTTPS to the original registrar, or correlating multiple sources. The CA should include information in their CP/CPS about the method that they use to validate the integrity of the data.

Many CAs use an email challenge-response mechanism to verify that the SSL certificate subscriber owns/controls the domain to be included in the certificate. Some CAs allow applicants to select an address from a predetermined list to be used for this verification. See [[CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs|Mozilla's restrictions on the set of verification addresses that may be used.]]

=== Verifying Email Address Control ===
We rely on public documentation and audits of those documented processes to ascertain that the requirements of section 7 of the Mozilla CA Certificate Policy are met.

Section 7 of the [http://www.mozilla.org/projects/security/certs/policy Mozilla CA Certificate Policy] states: “for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate”

The CA's public documentation needs to provide sufficient information describing how the email address is verified to be owned/controlled by the certificate subscriber. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the email address.

The recommended way to satisfy this requirement is to perform a challenge-response type of procedure in which the CA sends email to the email address to be included in the certificate, and the applicant must respond in a way that demonstrates that they have control over that email address. For instance, the CA may send an email to the address to be included in the certificate, containing secret unpredictable information, giving the applicant a limited time to use the information within.

=== Verifying Identity of Code Signing Certificate Subscriber ===

We rely on public documentation and audits of those documented processes to ascertain that the requirements of section 7 of the Mozilla CA Certificate Policy are met.

Section 7 of the [http://www.mozilla.org/projects/security/certs/policy Mozilla CA Certificate Policy] states: “for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf; ”

There are various ways to confirm the certificate subscriber's identity and we don't dictate exactly how this should be done for non-EV certificates. However we must be clear that a minimum standard has been reached:
# The organizational information to be included in the cert had been verified.
# The identity of the individual (the person requesting the certificate) has been verified.
# If the request is on behalf of an organization, then the authority of the individual to make that request has been verified.
# The identity and organization validation are tied together so that there is reasonable assurance;
# Sufficient verification procedures are in place such that someone cannot submit forged or stolen documents and receive a certificate in his name (or that of a company).

The CA's public (and audited) documentation must provide sufficient information describing the process to permit us to form an opinion. The documentation needs to be clear about the checks that are performed to confirm the identity of the certificate subscriber as well as establish that the certificate subscriber is authorized by the organization to be referenced in the certificate.

If public resources are used, then there should be a description of the types of public resources that are used, what data is retrieved from public resources, and how that data is used for verification of the entity referenced in the certificate.

Verification procedures often include contacting the organization through an independent means to confirm that the certificate subscriber is authorized by the organization to request the certificate. If this is the case, then it should be stated. The documentation should include information such as how the company's contact information is obtained, the method for contacting the organization, the typical title/position of the person contacted at the organization, and what information they confirm. Note that if the CA issues certificates outside its national area, documentation will need to establish the same minimum standard outside borders.

=== DNS names go in SAN ===

Some CAs mistakenly believe that one primary DNS name should go into the Subject Common Name and all the others into the SAN. That's wrong. ALL should go into the SAN.

=== OCSP ===

Mozilla strongly recommends that OCSP be provided for certificates chaining to CAs that are included in NSS. OCSP responders should be set up to listen on a standard port (e.g. port 80), because firewalls may block ports other than 80/443.

CAs are expected to comply with the current EV Guidelines of the [http://www.cabforum.org/ CA/B Forum.]

Section 11.1.1 of [http://www.cabforum.org/Guidelines_v1_2.pdf version 1.2 of the EV Guidelines] says: ''It is strongly RECOMMENDED that all CAs support OCSP when a majority of deployed Web servers support the TLS 1.0 extension in accordance to RFC 3546, to return “stapled” OCSP responses to EV-enabled applications. CAs MUST support an OCSP capability for Subscriber Certificates that are issued after Dec 31, 2010.''

''Viktor Vargas comment:
Realy this should be followed? OCSP response should be not older than 4 days or CRL not older than one year? Can we have more secure values? Is the OCSP support only for Subscriber certificates enough?
Maybe we should ad the following too:
CAs should include AIA:OCSP after dec 31, 2010 in end entity and subCA certificates.
''

''Kathleen Comments:
According to the EV Guidelines, OCSP responses for end-entity certs should have a maximum expiration time of 10 days. Mozilla recommends this for all end-entity certs (even not EV).
According to the EV Guidelines, the CRL nextUpdate for end-entity certs should not be more than 10 days. Mozilla recommends that the CRL nextUpdate for all end-entity certs (even not EV) be less than 10 days.
''

RFC 2560, sections 2.2, 2.6, 3.2 and 4.2.2.2 define the requirements for the OCSP response signer's certificate and certificate chain. NSS enforces these requirements exactly.

You MUST test your OCSP service in Firefox! We expect OCSP responders to function without error in Mozilla products. To test in Firefox:
* Go to Tools -> Options -> Advanced -> Encryption -> Validation
* Check the box for "When an OCSP server connection fails, treat the certificate as invalid"
* You may need to clear your cache
* Browse to a website whose SSL certificate chains up to your root and has the corresponding OCSP URI in the AIA extension.

Errors that CAs sometimes encounter when testing OCSP in Firefox:
* Error code: sec_error_ocsp_unauthorized_response
** Please read section 4.2.2.2 "Authorized Responders" on pages 10-11 of RFC 2560. CAs that emit certificates for the general public must use a configuration that conforms to either rule 2 or 3. NSS also supports rule 1, but it requires manually configuring Firefox to set the [[CA:OCSP-TrustedResponder|trusted OCSP responder.]] This makes this choice relevant only when the Firefox installation is part of a centralized deployment where a local OCSP responder has been setup to send back OCSP responses for all the CAs that are locally trusted. The IETF pkix group that authored RFC 2560 has confirmed that rule 1 is intended to cover similar situations and not public deployments.
* Error code: sec_error_ocsp_bad_http_response
** the http response from the OCSP responder had some result code other than 200.
** The http 200 response from the OCSP responder could not be decoded.
* Error code: sec_error_ocsp_invalid_signing_cert
** OCSP response signer's certificate was issued by the CA that issued the certificate whose status is being checked, but the response signer's certificate does not bear an ExtendedKeyUsage extension with the OCSP Responder OID, or
** OCSP response signer's certificate chain does not validate (e.g. expired, or bad signature, etc.)
** Trusted OCSP Responder Signing cert has not been imported. Mozilla users should not have to find and install the OCSP responder's certificate. See [[CA:Problematic_Practices#OCSP_Responses_signed_by_a_certificate_under_a_different_root|Potentially Problematic Practices.]]
* Error code: sec_error_bad_database
** the OCSP response gives a cert subject name to identify its signer's certificate, but no certificate by that name can be found -- not in the response, not in the database, and not in the cert chain of the certificate whose status is being checked. See [https://bugzilla.mozilla.org/show_bug.cgi?id=560091 this bugzilla bug] for more details.

== Notes for future work ==

* What (if anything) should we do regarding the use of non US-ASCII character sets in certs? To what extent is this supported today in NSS and by CAs? This whole problem seems analogous to the IDN problem.
** Excluding the IDN problem (on which I comment under "Document Handling of IDNs in CP/CPS"), care should be taken to avoid setting technical requirements more stringent than the X.509 specifications. If X.509 permits non-US-ASCII characters in certificates and if NSS and the Mozilla products that use it can operate correctly in the presence of such characters, they should be permitted. On the other hand, if non-US-ASCII characters cause technical problems for NSS or the Mozilla products that use it, that is already addressed under item #4 (after the first two bullets) in the existing policy. Of course, it might be appropriate to add a new bullet in the second set of bullets under item #4 to state explicitly that certificates must not contain any characters that cause software failures or security vulnerabilities in Mozilla products. As an alternative, characters might be limited to those used in languages for which Mozilla products have been localized.

''proposal from Viktor Varga:''
''the exception when a natural person owns a domain name is not handled in any RFC. Its right, that the DNS to the CN is a deprecated solution, but the usage of the DNS in CN field is still popular.''
''The question, how to display a natural person in a certificate.''
''In EV it is solved, because EV can be bought only by organisation.''
''CN cant be used, and the O field means organisation, not Individual.''

''My proposal can be read here:''
''(please move it to the right place, edit or delete it if not conforms.''
== Domain owned by a Natural Person ==
If a domain name owned by a natural person, and wants to get a certificate itself after successful validation the parameters of the natural person should be included into these fields:
O = name of the person inf the form it's displayed in its ID
OU = the string "natural person"

CA/Required or Recommended Practices

2010-07-26T15:29:40Z

Vargaviktor: some comments on AIA:OCSP and on the OCSP deadlines

CA/Forbidden or Problematic Practices

2009-10-02T15:36:25Z

Vargaviktor: also problematic the non resolvable and the resolvable together

== Potentially problematic CA practices ==

This page contains draft comments about various CA practices that have been the subject of discussion in past CA evaluations. In general these practices are not explicitly addressed by the [http://www.mozilla.org/projects/security/certs/policy Mozilla CA certificate policy], and we do not necessarily consider them security risks. However we want to highlight them because they've occasioned controversy in the past and have in some cases caused approval of applications to be delayed. Some of these practices may be addressed in future versions of the policy.

=== Long-lived DV certificates ===

A domain-validated SSL certificate attests only to ownership and control of a domain name, and the owner of a domain name may have acquired it from others. It is therefore possible for the previous owner of the domain to have a still-valid DV certificate for the domain. If such a valid certificate (and associated private key) were to be used in conjunction with a DNS spoofing attack it would allow a malicious site to masquerade as a legitimate site and bypass the protection afforded by SSL.

Some CAs issue DV SSL certificates that have expiration times several years in the future. This increases the time during which the possibility of such an attack exists.

=== Wildcard DV SSL certificates ===

Some CAs issue domain-validated SSL certificates that can function as wildcard certificates, e.g., a certificate for *.example.com where the CA verifies only ownership and control of the example.com domain, and the certificate subscriber can then use the certificate with any site foo.example.com, bar.example.com, etc. This means that a subscriber could establish malicious SSL-protected web site that are deliberately named in imitation of legitimate sites, e.g., paypal.example.com, without knowledge of the CA. Concerns have been expressed that wildcard SSL certificates should not be issued except to subscribers whose actual identity has been validated with organizational validation (OV). (There are no EV wildcard certificates.)

=== Delegation of Domain / Email validation to third parties ===

Domain and Email validation are core-requirements of the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Policy] and should always be incorporated into the issuing CAs procedures whenever possible. Registration Authorities (RA) or other third parties performing such functions must provide attestations about their procedures and/or should be audited together with the issuing CA. The CA must demonstrate clear and efficient controls attesting the performance of its RAs. Delegation of domain/email validation to third parties should generally be avoided.

=== Issuing end entity certificates directly from roots ===

Some CAs issue end entity certificates directly from the root (i.e., signed using the root CA private key). This is not as secure as using an offline root and issuing certificates using a subordinate CA.

=== Allowing external entities to operate unconstrained subordinate CAs ===

Some CAs authorize external entities to operate their own CAs as subordinate CAs under the original CA's root. This raises concerns relating to whether or not such external entities are audited in a manner equivalent to the root CA, as well as what legal and technical arrangements constrain the external entities.

=== Distributing generated private keys in PKCS#12 files ===

It is reported that some CAs generate the key pairs for their subscribers,
rather than having the subscribers generate their own key pairs, and once generated, those CAs distribute the private key, together with the issued public key certificate and its chain, to the subscriber in a PKCS#12 file.
The issues include:
* The user doesn't know or control who else possesses and can use his private key (decrypt his private messages or forge his signature), and
* The distribution channels used (e.g. unencrypted email) may not be adequately secured.

=== Certificates referencing hostnames or private IP addresses ===

The standard model for SSL on the web assumes that an SSL certificate references a domain name that is resolvable using the public DNS infrastructure (e.g., "www.example.com") or an IP address that is reachable from the public Internet. However it is also possible to include in a certificate a hostname not resolvable through the public DNS (e.g., "home") or a private IP address (e.g., 192.168.1.101); for example, this might be done for a corporate intranet with SSL-enabled servers behind a firewall and employees who don't want to enter fully-qualified domain names.

We consider this a problematic practice for a public CA because a subscriber who obtains a certificate of this type could in theory use it in contexts other than the one for which the certificate was obtained, and in particular could use it to help enable an SSL MITM attack on users in other organizations who are using the same hostname or IP address for their own SSL-enabled servers. (Depending on the hostnames and private IP addresses used, this vulnerability might also affect users of home networks with SSL-enabled home gateway devices.)

It is also a problematicaly practice, to issue a certificate with non resolvable DNS or private IP and resolvable DNS adresses together.

=== OCSP Responses signed by a certificate under a different root ===

CAs are not required to use OCSP. However, CAs who issue certificates with OCSP URLs in AIA extensions should make sure that the OCSP responses conform to RFC 2560, and work correctly for Mozilla users without requiring the user to find and install the OCSP responder's certificate, that is, the certificate with which the OCSP response signatures are verified.

At least one CA has issued certificates with OCSP URLs that reference OCSP responders that do not serve queries from the general public, and/or send out responses that are signed with a certificate that is
* not the certificate of the CA that issued the certificate in question; and
* not issued by the CA that issued the certificate in question.

When an OCSP responder URL is included in end-entity certificates, Firefox 3 will by default attempt to check the certificate's status via OCSP. If the OCSP signer certificate is not the certificate of the CA that issued the certificate in question and is not issued by the CA that issued the certificate in question, the OCSP check will fail with an NSS error code for OCSP, such as SEC_ERROR_OCSP_UNAUTHORIZED_REQUEST or SEC_ERROR_OCSP_UNAUTHORIZED_RESPONSE.

=== CRL with critical CIDP Extension ===

Currently Firefox handles "full" CRLs, but not "partitioned" CRLs. Partitioned CRLs are identified by the presence of a CRL Issuing Distribution Point (CIDP) extension flagged as critical. Firefox is not presently able to load CRLs with critical CIDP extensions. When attempting to load a CRL with a critical CIDP extension, Firefox will return the error code ffffe095, which is equivalent to the negative decimal number -8043. According to the [http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html NSS Error Codes] this error corresponds to SEC_ERROR_CRL_UNKNOWN_CRITICAL_EXTENSION.

The NSS team hopes to eventually implement partitioned CRLs, and when that work is done, Firefox should allow CRLs with critical CIDP extensions. However, even when that is done, older versions of Firefox will still not be able to load CRLs with critical CIDP extensions.

Our recommendation is to not put critical CIDP extensions into full CRLs, and to make full CRLs available for download when practical.

=== Generic names for CAs ===

In various contexts Firefox and other Mozilla-based products display to users the names of root CAs, issuing CAs, and intermediate CAs in general. In some cases CA names are very generic, e.g., "Secure Server CA"; this makes it difficult for users to ascertain who operates the CA without undertaking a detailed investigation.

Our recommendation is that all CA names incorporate an organizational name or product brand name sufficiently unique to allow relatively straightforward identification of the CA.

== Other considerations when updating the CA Certificate Policy ==

Many of the descriptions of the practices above will provide food for thought when and if we are making further updates to the CA Certificate Policy. Other issues which might be considered at that time include:

=== Root Count Restrictions ===

It has been suggested that, when the CA cert policy is revised, we restrict the
number of roots any one CA may have to e.g. 3. This is because more roots
increases the download size of the product.

=== Restrict government roots to their TLDs ===

A suggestion for a future revision of the policy is: we should restrict
government run/sponsored roots to only issuing certificates for the
corresponding TLD.

There are, of course, questions such as:

* What defines a government root
* What if they have all the necessary audits anyway

and so on. These would need to be discussed.

=== Minimum Key Sizes ===

One suggestion for a future revision of the CA Cert Policy is that we should
specify minimum key sizes, either just for roots or for roots, intermediates
and end entity certificates.

The exact restrictions would need to be discussed, but doubtless we would take
into account the views of our crypto team and advice from places like NIST.

=== Max Time Between Audits ===

It has been suggested that, when the CA cert policy is revised, we specify the
maximum period allowed between audits. WebTrust currently specifies 12 months,
and the same is (I understand) recommended for ETSI audits.

=== Actual Paperwork ===

It has been suggested that CAs should submit some paperwork by postal mail as
well as electronically. A formal inclusion request and general details from the
CA in question might help Mozilla in the case of legal problems in the future.

Apparently Apple and Microsoft do require physical paperwork.

=== Improve definition of "independent"; add idea of "trustworthy" ===

Currently, the guidelines talk about an auditor having to be both "independent"
and "competent". It has been suggested that the definition of independent
should be changed to be more like that the inverse of the MPL's definition of
You:

"For legal entities, "You" includes any entity which controls, is controlled
by, or is under common control with You. For purposes of this definition,
"control" means (a) the power, direct or indirect, to cause the direction or
management of such entity, whether by contract or otherwise, or (b) ownership
of more than fifty percent (50%) of the outstanding shares or beneficial
ownership of such entity."

Additionally, a new "trustworthiness" requirement would be added, which would
address some of the issues currently listed under "independent", such as being
bound to render a true judgement. This is because one could imagine an auditor
who was (under the above definition) independent and also competent, but may
nevertheless always provide "the right result" on payment of a fee.

CA:Root Removal Policy Notes

2009-09-15T13:26:26Z

Vargaviktor: some comment

== Mozilla CA Root Removal Policy Notes ==

The purpose of this wiki page is to gather input on creating a policy for removing CA root certificates from NSS. This page is open to everyone, so please add your input/comments directly. Adding content is greatly appreciated, but please don’t delete anything, but rather add a comment if you think something should be removed.

=== Summary and Policy Rational ===

CA root certificates may need to be removed from NSS. For example, for one or more of the following reasons:
* Security Compromise
* Expired or Expiring CA
* Small modulus key length, [http://csrc.nist.gov/groups/ST/key_mgmt/documents/Transitioning_CryptoAlgos_070209.pdf NIST recommend that 1024 bit roots be phased out by the end of 2010]
* Outdated signing key algorithm, such and MD2 and MD5
* Transition/Rollover to new root completed
* Legacy, no longer in use
* The CA has requested (via a bug report) a site certificate to be removed

Goals of Policy/Process:
* To have a completely open and public process, with public posting of all policy drafts and public discussion of what should go into the policy.
* To make explicit all the underlying rationales for why the policy is the way it is, including referencing available third-party documents that support particular policy decisions.
* To make an effort to get input from people who don't normally participate in mozilla.dev.security.policy discussions, including the development teams for Firefox, Thunderbird, SeaMonkey, Camino, and other Mozilla-based products, as well as representatives of CAs.
* To create a policy that is clear and understandable, is the product of a transparent public process, can be justified as reasonable given the current state of knowledge in the crypto/PKI/CA world, and is compatible with the general way we operate in the Mozilla project.
* [[Iang]] To process the requests on a policy-based, procedure-driven fashion, and to document this process so that it withstands challenge.
* [[Iang]] To be efficient, fast when needed, and provide sufficient and reasonable due scrutiny.

'''Comments:'''
* It doesn't hurt anything to leave roots in NSS past their expiration date,and it is occasionally useful for validating signatures on old emails, etc.
** For a CA whose ONLY purpose is to issue SSL server certs, which have no long term use after they expire, I see no reason to keep them after they expire.
** But email and code signing certs are different, because they validate signatures on long lived things (emails, code files) long after.
** [[Iang]] Which is complicated because the preferred schema is that roots don't do separate things, only subroots do.
**[[vargaviktor]] Its better to preserve the old invalid roots to, and give a red flag about it, that it is not secure anymore.
** Each CA might want its root in until signatures expire, which is potentially never.
* I also think that we should not remove a cert before its expiration unless the CA has utterly repudiated that cert (e.g. declared a compromise).
* What’s the best way to get input from people who don’t normally participate in mozilla.dev.security.policy discussions?
* A root certificate cannot be added to NSS without a request from the CA. A request from the CA to remove a root certificate should be treated as if the original request to add it was then withdrawn. The CA should not be required to express a reason for the request to remove the certificate. The CA might have a reason that precludes actually revoking the certifcate. However, legacy uses of mail and code-signing certificates can indeed create a need for a certificate to remain in use despite the CA's request. Thus, the CA's request should prevail only for site certificates; for mail and code-signing certificates, the action should be to remove the trust bit for sites instead of removing the certificate itself.
** [[Iang]] I don't think it is so easy as that.
** It is a convenience of contract that only the CA can ask for the root to be added.
** Because Mozilla acts on behalf of end-users, and those end-users have rights, liabilities and obligations, these all have to be considered.
** Rather than set rules under what circumstances the root should be removed "easily" I think it better to simply deal with it on a circumstance-by-cicumstance basis.
** If it was easy, we'd already have done it :)

=== Suggestions about what the policy should include ===

Information that the policy should include:

* Which root certificates should be removed, and when:
** [http://csrc.nist.gov/groups/ST/key_mgmt/documents/Transitioning_CryptoAlgos_070209.pdf NIST recommend that 1024 bit roots be phased out by the end of 2010]
** Other?

* Reasons a root certificate may be removed:
** Security Compromise
** Expired or Expiring CA
** Small modulus key length (1024 or smaller)
** Outdated signing key algorithm, such as MD2 or MD5
** Transition/Rollover to new root completed
** Legacy, no longer in use

* Actions that the CA is required to perform before a root certificate may be removed.
** provide ?
** publicly disclose information about ?
** prior to removing the CA certificates, verify ?

* Required notifications when a root certificate is to be removed, for example
** For security compromise or legacy reasons, the CA should be notified.
** Other?

'''Comments:'''
*

=== Suggestions about the Policy Language ===

Using much of the text from the Mozilla CA Policy, I have created the shell for the Removal Policy:

http://www.mozilla.org/projects/security/certs/removal-policy/

Please add your comments/recommendations about the text in the removal-policy here.

'''Comments:'''
* In the case of security compromise or legacy roots, we probably don’t want to depend on the CA filing a bug to request removal. On the other hand, I’m sure a CA would not want some random person to be able to file a root certificate removal request on their behalf. Should it be limited to an official representative of either the CA or Mozilla?
* [[iang]] I disagree.
** CAs are making representations to relying parties, who are known persons according to CA's RPA. They are also (potentially, arguably) creating risks for non-related persons, those who aren't relying parties according to their RPA, for whom Mozilla stands in for. The existence of the audit process and the mozilla policy bears testament to the risks, liabilities and obligations of all these parties.
** Obviously, CAs only and every reaction will be to suppress all claims by all others all the time.
** It is therefore both important and difficult to know who has valid and relevant claim to make against a CA or CA's root.
** I would therefore prefer that anyone can file a bug against a root or a CA, and that there be an easy procedure for dismissing the bug.
** And, I would suggest that Mozilla explicitly create a "safe harbour" for doing so by being precise as to the method.
* [[iang]] I think the notion of a removal policy is a bit too precise.
** There may be many other things that we want to do, such as deliver instructions to fix things, give deadlines, change settings.
* [[iang]] Some of the removals are likely to happen in adverse circumstances, so a policy is ''necessary'' but ''isn't sufficient''.
** We need a filing procedure. That is easy, just use the bugzilla.
** We need a procedure whereby the due attention is paid to claims in a formal setting, so that any decision can stand up in court.
** We need a decision maker. Relatively easy: Mozilla Foundation.
** In any adverse setting, the CA will be talking to their lawyers. It should be planned ''as if'' it will end up in court. This doesn't mean it will end up in court, quite the reverse. It doesn't end up in court, because you planned it ''as if'' it would end up in court. So, lay the chain of events and the evidence carefully.
** All of this can be the same for both adversarial and non-adversarial process. The latter can just speed it up by an order of magnitude. Doing it this way means that when we come to the former case, it has a chance of working.
* [[iang]] There needs to be a little bit more formalism with the CAs
** Technically there should be a written contract
** the bug filed to get a root added can be implied into a contract
** but it's very messy ... better to have a description page that lays out what the contract is, referring to all the other areas.
** also, we need to get CAs to accept that Mozilla has jurisdiction over its root, and has the ability and right and desire to remove roots and other actions.
** At the moment, it could be argued that Mozilla provides a public service, and does not have the right to not provide it. Or some blah blah.
* [[iang]] Which is to say, this "root removal" project will have implications on other areas. Perhaps move some of these points to the talk page?

=== Suggestions about the Process ===

High level process for removal of a root certificate:
# a bug is filed in bugzilla requesting removal of a root
## ''outstanding question: CA or Mozilla representatives only?''
# Mozilla representative is appointed to deal with the bug
## this will normally be the standing module owner.
# Mozilla representative ensures necessary information provided
## Options should be identified (removal, flagging, bit-settings)
## technical assistance may be requested
## Additional information is requested of CA and other parties
# Mozilla representative delivers any preliminary decisions.
## It may be necessary to do a security patch immediately.
# Public discussion on mozilla.dev.security.policy
## Outline is presented, references to full bug provided
## Deadline for discussion is set.
## Reminder of the rules of safe harbour.
# Final Decision
## Decision to remove (or not)
## Any other options or actions as decided
# Implementation
## Assignment of bug to appropriate person for actual changes to NSS
## Test
## Notification

'''Comments:'''
* Should the root cert actually be removed from NSS? Or is there a another alternative that would enable an appropriate error message to be returned when an attempt is made to use a “removed” root cert?
** [[Iang]] I see these alternatives that may or may not be relevant: Change the certificate to include better info or better algorithms, change the so-called "trust-bits", flags put on to make some statement (requires code changes), notification of deadlines for removal, immediate security bug patch to remove.
* Mozilla should have a rapid response plan for removing a compromised root, and corresponding procedures to test the removal.
** [[Iang]] This is started at [[CA:Recommendations_for_Roots]] pt 3.
* When a CA requests a root certificate to be removed (a site certificate), should the removal be delayed by this process? The only process that should be required is to authenticate the source of the request.
** [[Iang]] I would strongly suggest you use exactly the same procedure regardless of the circumstances. Then, in the case of a CA requesting, or an emergency security situation, the Mozilla Representative expedites the process. This way, we ensure the process works when we need it.
**[Varga Viktor] My opinion, that the remove is not the most secure.
For example:
case A - Removed compromised root ca:
1) with the compromised key the phishinger creates bogus certificates
2) attacker uses it, and Firefox doesnot know anything about the root
3) user clisks a few, because the security alert
case B - ca certificate is not removed, only blacklisted
1) with the compromised key the phishinger creates bogus certificates
2) attacker uses it, and Firefox knows that it is an invalid root
3) Firefox display big red exclamation marks, and disables the usage of this certificate, because its knows, that this certificate is insecure
(same like the SSL gui, ...)
This example only concentrates on the key compromise, but, there is only a few scenario, which should be handled.

CA:Root Removal Policy Notes

2009-07-22T15:26:51Z

Vargaviktor: /* Suggestions about the Process */

== Mozilla CA Root Removal Policy Notes ==

The purpose of this wiki page is to gather input on creating a policy for removing CA root certificates from NSS. This page is open to everyone, so please add your input/comments directly. Adding content is greatly appreciated, but please don’t delete anything, but rather add a comment if you think something should be removed.

=== Summary and Policy Rational ===

CA root certificates may need to be removed from NSS. For example, for one or more of the following reasons:
* Security Compromise
* Expired or Expiring CA
* Small modulus key length, [http://csrc.nist.gov/groups/ST/key_mgmt/documents/Transitioning_CryptoAlgos_070209.pdf NIST recommend that 1024 bit roots be phased out by the end of 2010]
* Outdated signing key algorithm, such and MD2 and MD5
* Transition/Rollover to new root completed
* Legacy, no longer in use
* The CA has requested (via a bug report) a site certificate to be removed

Goals of Policy/Process:
* To have a completely open and public process, with public posting of all policy drafts and public discussion of what should go into the policy.
* To make explicit all the underlying rationales for why the policy is the way it is, including referencing available third-party documents that support particular policy decisions.
* To make an effort to get input from people who don't normally participate in mozilla.dev.security.policy discussions, including the development teams for Firefox, Thunderbird, SeaMonkey, Camino, and other Mozilla-based products, as well as representatives of CAs.
* To create a policy that is clear and understandable, is the product of a transparent public process, can be justified as reasonable given the current state of knowledge in the crypto/PKI/CA world, and is compatible with the general way we operate in the Mozilla project.
* [[Iang]] To process the requests on a policy-based, procedure-driven fashion, and to document this process so that it withstands challenge.
* [[Iang]] To be efficient, fast when needed, and provide sufficient and reasonable due scrutiny.

'''Comments:'''
* It doesn't hurt anything to leave roots in NSS past their expiration date,and it is occasionally useful for validating signatures on old emails, etc.
** For a CA whose ONLY purpose is to issue SSL server certs, which have no long term use after they expire, I see no reason to keep them after they expire.
** But email and code signing certs are different, because they validate signatures on long lived things (emails, code files) long after.
** [[Iang]] Which is complicated because the preferred schema is that roots don't do separate things, only subroots do.
** Each CA might want its root in until signatures expire, which is potentially never.
* I also think that we should not remove a cert before its expiration unless the CA has utterly repudiated that cert (e.g. declared a compromise).
* What’s the best way to get input from people who don’t normally participate in mozilla.dev.security.policy discussions?
* A root certificate cannot be added to NSS without a request from the CA. A request from the CA to remove a root certificate should be treated as if the original request to add it was then withdrawn. The CA should not be required to express a reason for the request to remove the certificate. The CA might have a reason that precludes actually revoking the certifcate. However, legacy uses of mail and code-signing certificates can indeed create a need for a certificate to remain in use despite the CA's request. Thus, the CA's request should prevail only for site certificates; for mail and code-signing certificates, the action should be to remove the trust bit for sites instead of removing the certificate itself.
** [[Iang]] I don't think it is so easy as that.
** It is a convenience of contract that only the CA can ask for the root to be added.
** Because Mozilla acts on behalf of end-users, and those end-users have rights, liabilities and obligations, these all have to be considered.
** Rather than set rules under what circumstances the root should be removed "easily" I think it better to simply deal with it on a circumstance-by-cicumstance basis.
** If it was easy, we'd already have done it :)

=== Suggestions about what the policy should include ===

Information that the policy should include:

* Which root certificates should be removed, and when:
** [http://csrc.nist.gov/groups/ST/key_mgmt/documents/Transitioning_CryptoAlgos_070209.pdf NIST recommend that 1024 bit roots be phased out by the end of 2010]
** Other?

* Reasons a root certificate may be removed:
** Security Compromise
** Expired or Expiring CA
** Small modulus key length (1024 or smaller)
** Outdated signing key algorithm, such as MD2 or MD5
** Transition/Rollover to new root completed
** Legacy, no longer in use

* Actions that the CA is required to perform before a root certificate may be removed.
** provide ?
** publicly disclose information about ?
** prior to removing the CA certificates, verify ?

* Required notifications when a root certificate is to be removed, for example
** For security compromise or legacy reasons, the CA should be notified.
** Other?

'''Comments:'''
*

=== Suggestions about the Policy Language ===

Using much of the text from the Mozilla CA Policy, I have created the shell for the Removal Policy:

http://www.mozilla.org/projects/security/certs/removal-policy/

Please add your comments/recommendations about the text in the removal-policy here.

'''Comments:'''
* In the case of security compromise or legacy roots, we probably don’t want to depend on the CA filing a bug to request removal. On the other hand, I’m sure a CA would not want some random person to be able to file a root certificate removal request on their behalf. Should it be limited to an official representative of either the CA or Mozilla?
* [[iang]] I disagree.
** CAs are making representations to relying parties, who are known persons according to CA's RPA. They are also (potentially, arguably) creating risks for non-related persons, those who aren't relying parties according to their RPA, for whom Mozilla stands in for. The existence of the audit process and the mozilla policy bears testament to the risks, liabilities and obligations of all these parties.
** Obviously, CAs only and every reaction will be to suppress all claims by all others all the time.
** It is therefore both important and difficult to know who has valid and relevant claim to make against a CA or CA's root.
** I would therefore prefer that anyone can file a bug against a root or a CA, and that there be an easy procedure for dismissing the bug.
** And, I would suggest that Mozilla explicitly create a "safe harbour" for doing so by being precise as to the method.
* [[iang]] I think the notion of a removal policy is a bit too precise.
** There may be many other things that we want to do, such as deliver instructions to fix things, give deadlines, change settings.
* [[iang]] Some of the removals are likely to happen in adverse circumstances, so a policy is ''necessary'' but ''isn't sufficient''.
** We need a filing procedure. That is easy, just use the bugzilla.
** We need a procedure whereby the due attention is paid to claims in a formal setting, so that any decision can stand up in court.
** We need a decision maker. Relatively easy: Mozilla Foundation.
** In any adverse setting, the CA will be talking to their lawyers. It should be planned ''as if'' it will end up in court. This doesn't mean it will end up in court, quite the reverse. It doesn't end up in court, because you planned it ''as if'' it would end up in court. So, lay the chain of events and the evidence carefully.
** All of this can be the same for both adversarial and non-adversarial process. The latter can just speed it up by an order of magnitude. Doing it this way means that when we come to the former case, it has a chance of working.
* [[iang]] There needs to be a little bit more formalism with the CAs
** Technically there should be a written contract
** the bug filed to get a root added can be implied into a contract
** but it's very messy ... better to have a description page that lays out what the contract is, referring to all the other areas.
** also, we need to get CAs to accept that Mozilla has jurisdiction over its root, and has the ability and right and desire to remove roots and other actions.
** At the moment, it could be argued that Mozilla provides a public service, and does not have the right to not provide it. Or some blah blah.
* [[iang]] Which is to say, this "root removal" project will have implications on other areas. Perhaps move some of these points to the talk page?

=== Suggestions about the Process ===

High level process for removal of a root certificate:
# a bug is filed in bugzilla requesting removal of a root
## ''outstanding question: CA or Mozilla representatives only?''
# Mozilla representative is appointed to deal with the bug
## this will normally be the standing module owner.
# Mozilla representative ensures necessary information provided
## Options should be identified (removal, flagging, bit-settings)
## technical assistance may be requested
## Additional information is requested of CA and other parties
# Mozilla representative delivers any preliminary decisions.
## It may be necessary to do a security patch immediately.
# Public discussion on mozilla.dev.security.policy
## Outline is presented, references to full bug provided
## Deadline for discussion is set.
## Reminder of the rules of safe harbour.
# Final Decision
## Decision to remove (or not)
## Any other options or actions as decided
# Implementation
## Assignment of bug to appropriate person for actual changes to NSS
## Test
## Notification

'''Comments:'''
* Should the root cert actually be removed from NSS? Or is there a another alternative that would enable an appropriate error message to be returned when an attempt is made to use a “removed” root cert?
** [[Iang]] I see these alternatives that may or may not be relevant: Change the certificate to include better info or better algorithms, change the so-called "trust-bits", flags put on to make some statement (requires code changes), notification of deadlines for removal, immediate security bug patch to remove.
* Mozilla should have a rapid response plan for removing a compromised root, and corresponding procedures to test the removal.
** [[Iang]] This is started at [[CA:Recommendations_for_Roots]] pt 3.
* When a CA requests a root certificate to be removed (a site certificate), should the removal be delayed by this process? The only process that should be required is to authenticate the source of the request.
** [[Iang]] I would strongly suggest you use exactly the same procedure regardless of the circumstances. Then, in the case of a CA requesting, or an emergency security situation, the Mozilla Representative expedites the process. This way, we ensure the process works when we need it.
**[Varga Viktor] My opinion, that the remove is not the most secure.
For example:
case A - Removed compromised root ca:
1) with the compromised key the phishinger creates bogus certificates
2) attacker uses it, and Firefox doesnot know anything about the root
3) user clisks a few, because the security alert
case B - ca certificate is not removed, only blacklisted
1) with the compromised key the phishinger creates bogus certificates
2) attacker uses it, and Firefox knows that it is an invalid root
3) Firefox display big red exclamation marks, and disables the usage of this certificate, because its knows, that this certificate is insecure
(same like the SSL gui, ...)
This example only concentrates on the key compromise, but, there is only a few scenario, which should be handled.