CA/Auditor Mistakes

From MozillaWiki
< CA
Jump to: navigation, search

Auditor Mistakes

During evaluation of a CA's root inclusion or change request, Mozilla uses public audit statements to help confirm that the CA is in compliance with the stated verification requirements, the BRs, and Mozilla's policy. Therefore, when members of Mozilla's community find a problem with certificates in the CA's hierarchy that should have been noted in the audit statement (as an exception or point of non-compliance), the CA may need to be re-audited to confirm that the problem has been resolved.

When egregious mistakes were overlooked by the auditor, or there are a significant number of oversights, or the auditor did not notice BR compliance problems with the root or intermediate certificates, then the CA must resolve the issues and be re-audited. For the re-audit the CA can either get re-audited by a different auditor, or have the current auditor provide an immediate plan for correction and compliance, and then present a mid-term partial audit following that plan. In either case, the auditor must provide documentation about steps they are taking to avoid making the same mistakes in future audits. If the auditor fails to assure Mozilla that they have corrected the deficiencies in their auditing process, then their standing as a trusted auditor for the Mozilla root program may be jeopardized.

Non-compliance to the following policies are examples of mistakes that auditors must not overlook.

  • BR Appendix A (section 6.1.5 in BR version 1.3) for root and intermediate certs - Cryptographic Algorithm and Key Requirements (Normative) - Certificates MUST meet the following requirements for algorithm type and key size.
  • BR Appendix B (section 7.1.2 in BR version 1.3) for root and intermediate certs – Certificate Extensions (Normative) - specifies the requirements for Certificate extensions for Certificates generated after the Effective Date.
  • With regards to root and intermediate certificates, the items listed in section 4 of Mozilla CA Certificate Inclusion Policy:
    • ASN.1 DER encoding errors;
    • invalid public keys (e.g., RSA certificates with public exponent equal to 1);
    • duplicate issuer names and serial numbers;
    • incorrect extensions (e.g., SSL certificates that exclude SSL usage, or authority key IDs that include both the key ID and the issuer’s issuer name and serial number); or
    • cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists.

There are other types of mistakes that could potentially not be found by an auditor doing sampling of end-entity certificates. If the auditor did not note this type of mistake in the audit statement, then the CA must fix the mistake(s) and be re-audited to confirm that the problem has been resolved. The CA may use the same auditor that issued the previous audit statement.

Non-compliance to the following policies are examples of mistakes that auditors might overlook due to sampling of end-entity certificates:

  • BR 9.2.1 (section 7.1.4.2.1 in BR version 1.3) - Subject Alternative Name Extension - SSL certs must contain at least one entry
  • BR 9.2.2 (section 7.1.4.2.2 in BR version 1.3) - Subject Common Name Field - If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension
  • BR 9.4.1 (section 6.3.2 in BR version 1.3)- Subscriber Certificates - Subscriber Certificates issued after the Effective Date (1 July 2012) MUST have a Validity Period no greater than 60 months. (exceptions allowed)
  • BR Appendix A (section 6.1.5 in BR version 1.3) for Subscriber certs - Cryptographic Algorithm and Key Requirements (Normative) - Certificates MUST meet the following requirements for algorithm type and key size.
  • BR Appendix B (section 7.1.2 in BR version 1.3) for Subscriber certs – Certificate Extensions (Normative) - This appendix specifies the requirements for Certificate extensions for Certificates generated after the Effective Date.
  • The items listed in section 4 of Mozilla CA Certificate Inclusion Policy in end-entity certificates:
    • ASN.1 DER encoding errors;
    • invalid public keys (e.g., RSA certificates with public exponent equal to 1);
    • duplicate issuer names and serial numbers;
    • incorrect extensions (e.g., SSL certificates that exclude SSL usage, or authority key IDs that include both the key ID and the issuer’s issuer name and serial number); or
    • cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists.

Finally, there are a type of mistakes that may be found during the evaluation of a root inclusion/change request, and resolved by the CA without requiring a re-audit. If someone reports this type of mistake, then the CA must fix the mistake and provide examples to demonstrate that the problem has been resolved. Examples of this type of mistake include non-compliance with the following.

  • BR 13.2.2 (section 4.9.10 in BR version 1.3) - Repository -- CRL and OCSP max expiration time, GET
  • BR 3.2.5 (section 4.9.9 in BR version 1.3) OCSP Signing -- OCSP responses MUST conform to RFC2560 and/or RFC5019.
  • Mozilla CA Certificate Maintenance Policy section 9: all new end-entity certificates must contain at least 20 bits of unpredictable random data (preferably in the serial number).
Retrieved from "https://wiki.mozilla.org/index.php?title=CA/Auditor_Mistakes&oldid=1237518"