1677631 - Add Autoridade Certificadora do Serpro SSLv1

Is there a “problem reporting” email address that is closely monitored for reporting suspected Private Key Compromise and to request rapid revocation?

I have uploaded your audit letter, but all CA certificates need to be reported by their SHA256 hash, uppercase letters, no spaces or colons, and all on one line. Here is the error we received when running the current audit letter through our Audit Letter Validation (ALV) program: “The thumbprint of R00001434 is not found”. There was only one CA listed in your audit, but all subordinates that are capable of issuing SSL certificates must be listed.

Also, whenever an audit letter is submitted for Baseline Requirements, it must also be accompanied by a standard WebTrust audit issued in accordance with WebTrust for CAs, v. 2.2.

Additionally, here are some “Needs” that need to be completed in the CCADB or submitted and attached here to this bug:

CA's Responses to the following Required Practices

NEED: CP/CPS section numbers addressing each of the items listed in https://wiki.mozilla.org/CA/Required_or_Recommended_Practices

\1. Publicly Available CP and CPS:

1.1 Revision Table, updated annually:

1.2 CAA Domains listed in CP/CPS:

1.3 BR Commitment to Comply statement in CP/CPS:

1.4 CP/CPS Structured According to RFC 3647, appropriate use of 'No Stipulation':

\2. Audit Criteria:

2.1 Complete Audit History:

CA key generation report, any point in time audits, all period of time audits

\3. Revocation of Compromised Certificates:

\4. Verifying Domain Name Ownership:

4.1 Baseline Requirements:

4.2 WHOIS:

4.3 Email Challenge-Response:

\5. Verifying Email Address Control:

\6. DNS names go in SAN:

\7. OCSP:

- OCSP SHALL NOT respond 'Good' for unissued certificates:

\8. Network Security Controls:

CA's Responses to the following Forbidden Practices

NEED: CP/CPS section numbers addressing each of the items listed in https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices

\1. Long-lived Certificates:

\2. Non-Standard Email Address Prefixes for Domain Ownership Validation:

\3. Issuing End Entity Certificates Directly From Trust Anchors

\4. Distributing Generated Private Keys in PKCS#12 Files:

\5. Certificates Referencing Local Names or Private IP Addresses:

\6. Issuing SSL Certificates for .int Domains:

\7. OCSP Responses Signed by a Certificate Under a Different CA:

\8. Issuance of SHA-1 Certificates:

\9. Delegation of Domain / Email Validation to Third Parties:

CA Certificate Download URL

NEED: A public URL through which the CA certificate can be directly downloaded.

(I had trouble finding it on https://certificados.serpro.gov.br/)

Certificate Testing

NEED:

- Provide 3 URLs to 3 test websites (valid, expired, revoked) whose TLS/SSL cert chains up to this CA.

Revocation Tested

NEED: Test with http://certificate.revocationcheck.com/ make sure there aren't any errors.

CA/Browser Forum Lint Test

NEED: Provide evidence that you have tested and verified that no certificates issued in this CA hierarchy violate any of the CA/Browser Forum Baseline Requirements (BRs).

BR Lint Test: https://github.com/awslabs/certlint

Mozilla will check that the CA is not issuing certificates that violate any of the BRs by using crt.sh on the proposed trust anchor and subordinate CAs via: https://crt.sh/?caid=<CA ID>&opt=cablint,zlint,x509lint&minNotBefore=2014-01-01

and/or

The Lint tests in https://crt.sh/?a=1

Test Website Lint Test

NEED: Provide evidence that you have tested and verified that no certificates issued in this CA hierarchy violate the X.509 rules.

X.509 Lint Test: https://github.com/kroeckx/x509lint

Full Description of Existing/Proposed PKI Hierarchy

NEED: URL and/or Description of this PKI Hierarchy.

Provide details related to any of the check-boxes above that are selected.

Add records for the existing intermediate certs to the CCADB as described here: https://ccadb.org/cas/intermediates#adding-intermediate-certificate-data

If Mozilla accepts and includes your CA certificate, then we have to assume that we also accept any of your future sub-CAs and their sub-CAs. Therefore, the selection criteria for your sub-CAs and their sub-CAs will be a critical decision factor. As well as the documentation and auditing of operations requirements that you place on your sub-CAs and their sub-CAs.

If this CA has (or will have) any subordinate CA certificates that are operated by external third parties, then provide the information listed in the Subordinate CA Checklist in a separate document. https://wiki.mozilla.org/CA/Subordinate_CA_Checklist

Constraints on External SubCAs & RAs

NEED: Describe constraints on external subordinate CAs and RAs.

As per section 5.3 of Mozilla's Root Store Policy, provide the required data for all of your non-technically-constrained subordinate CA certificates that chain up or will chain up to this proposed trust anchor.

This data may be provided as follows:

- If your CA has access to the CCADB, then you may upload existing CA certificates directly into the CCADB.

- Otherwise, provide this information here in your Bugzilla Bug.

Mozilla Applied Constraints

NEED: Mozilla has the ability to name-constrain trust anchors; e.g. to *.gov.br or *.mil.br, so CAs should consider if such constraints may be applied to this certificate.

https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/certdb/genname.c#1551

CPS Review Items

For future reference, here are the items that we will be reviewing in your CPS.

CP/CPS structured in accordance with RFC 3647 with no blank sections (MRSP § 3.3.5) (BR § 2.2)

CP/CPS made available under a Creative Commons License (MRSP § 3.3.3)

“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)”

Statement of adherence to BRs and their precedence (MRSP § 2.3) (BR § 2.2)

“The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and those Requirements, those Requirements take precedence.”

Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 7.1.2.2.g.)

Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU.

Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6)

“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.”

Explicit annual revision of CP/CPS w/ table of changes (MRSP § 3.3.4) (BR § 2.3)

“CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.” Also, a version history table provides evidence of compliance and good change management practices.

Statement of Non-Delegation for Domain Validation (BR § 1.3.2)

“With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.”

Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3)

“The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.”

Naming compliant with X.500, RFC5280 and BRs

The structure and use of names in certificates must comply with the Baseline Requirements, X.500, and RFC 5280.

No internal names or reserved IP addresses (BR § 7.1.4.2.1)

“CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name.”

ALL certificates must meet Mozilla/BR validation requirements

CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1)

CP/CPS must be sufficient “for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests”.

[Note: It is also recommended that CAs ensure that the domain name registrant has approved or authorized a certificate request such that the certificate cannot be used to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]

CA validates domain part of all e-mail addresses (MRSP § 2.2.2)

“For a certificate capable of being used for digitally signing 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 or has been authorized by the email account holder to act on the account holder’s behalf. The CA SHALL NOT delegate validation of the domain portion of an email address.”

Data sources need to be accurate (BR § 3.2.2.7 and EVG § 11.11.5)

For OV – “[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.”

For EV - “A database qualifies as a QIIS if the CA determines that: (1) Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and (2) The database provider updates its data on at least an annual basis.”

All information in a certificate must be verified (MRSP § 2.2.1) 3.2.4

“All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.”

Data reuse (certificate renewal) limited to 825 days (MRSP § 2.1.5) (BR § 4.2.1)

CAs must “verify that all of the information that is included in SSL certificates remains current and correct at time intervals of 825 days or less”.

CAA record checking and recognized domain names in section 4.2 (BR § 2.2)

“Section 4.2 of a CA’s Certificate Policy and/or Certification Practice Statement SHALL state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements.”

Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3)

CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”.

Pre-issuance linting (Recommended Practices)

“It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences”

Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2)

24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)

SMIME Reasons for Revocation (MRSP § 6.2)

“For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates upon the occurrence of any of the following events …”

CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6)

CA must not allow certificate suspension (BR § 4.9.13)

OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6)

Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7)

“Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.”

CA must not generate Subscriber key pairs (MRSP § 5.2)

“CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage.”

Must meet RSA key requirements (MRSP § 5.1)

Must meet ECDSA key requirements, P-256 or P-384 (MRSP § 5.1)

Certificate lifetimes limited to 398 days (BR § 6.3.2)

“Subscriber Certificates … SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.”

Network Security (MRSP § 2.1.2)

CAs must “follow industry best practice for securing their networks, for example by conforming to the CAB Forum Network Security Guidelines or a successor document”.

Serial numbers greater than 64 bits generated by a CSPRNG (MRSP § 5.2)

“all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG.”

EKUs required in certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 7.1.2.3.f)

Use of SHA-1 prohibited (MRSP § 5.1.3) (BR § 7.1.3.2.1)

Any CN must also be in a SAN (BR § 7.1.4.2.2.a)

Flags: needinfo?(lucia.castelli)

Ben Wilson

Assignee

Updated

•

5 years ago

Whiteboard: [ca-initial] → [ca-verifying] BW 2020-12-04 Comment #2

SERPRO_Audit_Report.pdf 5 years ago Ben Wilson 301.62 KB, application/pdf		Details
AC_SERPRO_SSL_Self_Assessment.ods 5 years ago Lucia Castelli 70.81 KB, application/vnd.oasis.opendocument.spreadsheet		Details
01_-_AC_SERPRO_SSL_Webtrust_for_CA_-_Period_of_Time_Audit_Report.pdf 5 years ago Lucia Castelli 311.36 KB, application/pdf		Details
02_-_AC_SERPRO_SSL_Webtrust_BR_SSL_and_Network_Security_-_Period_of_Time_Audit_Report.pdf 5 years ago Lucia Castelli 301.62 KB, application/pdf		Details
100_-_AC_SERPRO_SSL_RKGC_Audit_Report.pdf 5 years ago Lucia Castelli 298.67 KB, application/pdf		Details
101_-_AC_SERPRO_SSL_Webtrust_for_CA_-_Point_in_Time_Audit_Report.pdf 5 years ago Lucia Castelli 315.39 KB, application/pdf		Details
102_-_AC_SERPRO_SSL_Webtrust_BR_SSL_and_Network_Security_-_Point_in_Time_Audit_Report.pdf 5 years ago Lucia Castelli 308.15 KB, application/pdf		Details
11_-_AC_SERPRO_SSL_Webtrust_for_CA_-_Period_of_Time_Audit_Report_-_versão_10122020-assinado.pdf 5 years ago Lucia Castelli 299.07 KB, application/pdf		Details
12_-_AC_SERPRO_SSL_Webtrust_BR_SSL_and_Network_Security_-_Period_of_Time_Audit_Report_-_versão_10122020.pdf 5 years ago Lucia Castelli 294.72 KB, application/pdf		Details
Update CA Certificate Download URL 5 years ago Lucia Castelli 76 bytes, text/plain		Details
CP_SERPRO_SSL_CA.pdf 5 years ago Lucia Castelli 345.12 KB, application/pdf		Details
CPS_SERPRO_SSL_CA.pdf 5 years ago Lucia Castelli 1.35 MB, application/pdf		Details
Personal Data Protection Principles.pdf 5 years ago Lucia Castelli 195.80 KB, application/pdf		Details
The 5 years ago Lucia Castelli 249.51 KB, application/pdf		Details
01 - Relatório Webtrust for CA - SERPRO 2021 - signed.pdf 4 years ago Lucia Castelli 387.15 KB, application/pdf		Details
WebTrust Trademark Agreement PKI Contabilidade e Auditoria Ltda.pdf 4 years ago Lucia Castelli 1.91 MB, application/pdf		Details
AC SERPRO - WebTrust for SSL Baseline with Network Security Report-Management Assertion_SIGNED.pdf 4 years ago Lucia Castelli 516.93 KB, application/pdf		Details
AC SERPRO - WebTrust for SSL Baseline with Network Security Report-Management Assertion V2.pdf 4 years ago Lucia Castelli 274.76 KB, application/pdf		Details
Value vs Risk_SERPRO_SSL_CA.pdf 3 years ago Lucia Castelli 178.66 KB, application/pdf		Details
Value vs Risk_SERPRO_SSL_CA.pdf 3 years ago Lucia Castelli 179.73 KB, application/pdf		Details

Section Number	Comments
1.2.1. Revisions Note the Effective Date for each item in the table. Certificates created after each Effective Date are expected to be in compliance with the item. Make sure your CA is in compliance with each of these items. After careful consideration, indicate if your CA is fully compliant with all items in the table, or clearly indicate action that your CA is taking to improve compliance.	Improvement needed - SERPRO needs to stay current with developments in the CA/Browser Forum and with Mozilla's Root Store Policy.
1.2.2. Relevant Dates Note the Compliance date for each item in the table. Those are the dates by which your CP/CPS and practices are expected to be updated to comply with the item. Make sure your CA is in compliance with each of these items. After careful consideration, indicate if your CA is fully compliant with all items in the table, or clearly indicate action that your CA is taking to improve compliance.	Improvement needed - SERPRO needs to stay current with developments in the CA/Browser Forum and with Mozilla's Root Store Policy.
1.3.2. Registration Authorities Indicate whether your CA allows for Delegated Third Parties, or not. Indicate which sections of your CP/CPS specify such requirements, and how the CP/CPS meets the BR requirements for RAs.	Need to fix Section 1.3.2.1 of the SERPRO CPS needs to state that domain validation is not delegated to third party registration authorities.
2.2 Publication of information - RFC 3647 "Effective as of 31 May 2018, the Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647."	Need to fix Multiple section headings do not match the outline in the appendix of RFC 3647. These need to be fixed.
2.3. Time or frequency of publication "The CA SHALL ... annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. Section 3.3 of Mozilla's Root Store Policy states: "CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document." Indicate your CA's policies/practices to ensure that the BRs are reviewed regularly, and that the CA's CP/CPS is updated annually.	Should fix section 2.3.1 to state that the CP/CPS is republished and reversioned annually even if there are no changes.
3.2.2.4 Validation of Domain Authorization or Control Indicate which of the methods of domain validation your CA uses, and where this is described in your CP/CPS.	See below
3.2.2.4.6 Agreed‐Upon Change to Website If your CA uses this method of domain validation, indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.	NEED TO REPLACE WITH UPDATED BR METHOD 3.2.2.4.18
3.2.2.4.18 Agreed‐Upon Change to Website v2	Move to here and re-phrase based on BR section 3.2.2.4.18
3.2.2.5 Authentication for an IP Address If your CA allows IP Addresss to be listed in certificates, indicate which methods your CA uses and how your CA meets the requirements in this section of the BRs.	OUTDATED CROSS-REFERENCE - this method (3.2.2.4.18) cannot be used
3.2.2.6 Wildcard Domain Validation If your CA allows certificates with a wildcard character () in a CN or subjectAltName of type DNS‐ID, then indicate how your CA meets the requirements in this seciton of the BRs.*	OUTDATED CROSS-REFERENCE - this method (3.2.2.4.18) cannot be used - "This method is NOT suitable for validating Wildcard Domain Names."
4.3.1. CA Actions during Certificate Issuance
4.9.1.1 Reasons for Revoking a Subscriber Certificate Indicate which section in your CA's CP/CPS contains the list of reasons for revoking certificates.	Reason 4 is missing - "The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys);" Also, re-check section 4.9.1.1 of the Baseline Requirements to ensure that no other revocation reasons are missing.
4.9.2. Who Can Request Revocation	SERPRO needs to accommodate third parties with a copy of the private key who can demonstrate key compromise and request revocation
4.9.10. On-line Revocation Checking Requirements Indicate how your CA meets all of the requirements listed in this section, including support of GET, update frequency, preventing erronious return of "good" status.	I did not see where SERPRO states that it supports "GET" and does not respond "good" for a non-existent certificate serial number.
5.7.3 Key Compromise	Mozilla and other root stores need to be notified if there is a compromise of the CA's private key
6.1.5. Key Sizes	Need to specify
6.1.6. Public Key Parameters Generation and Quality Checking	Need to specify (see BR section 6.1.6)

Section Number	Comment
1.3.2. Registration Authorities or 3.2.2.4 Validation of Domain Authorization or Control	The SERPRO CPS should be more explicit and state that only SERPRO SSL CA performs the domain validation required by section 3.2.2.4 of the Baseline Requirements (BR) and that the task is never delegated to any third party.
3.2.2.4.18 Agreed‐Upon Change to Website v2	The explanation of the processes used to fulfill the requirements of BR section 3.2.2.4.18 are not sufficiently detailed. The CPS needs to provide a detailed explanation of the steps followed to perform the method "Agreed-Upon Change to Website".
3.2.2.5 Authentication for an IP Address	This method should be based on BR 3.2.2.5.1 Agreed‑Upon Change to Website (not 3.2.2.4.18, even though they are very similar) , and the CPS needs sufficient explanation of how this occurs.
3.2.2.6 Wildcard Domain Validation	This method (BR 3.2.2.4.18) cannot be used to issue Wildcard Certificates- BR 3.2.2.4.18 states, "This method is NOT suitable for validating Wildcard Domain Names."
4.9.1.1 Reasons for Revoking a Subscriber Certificate	Reason 4 of BR 4.9.1.1 is missing - "The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys);"
4.9.2. Who Can Request Revocation	SERPRO needs to accommodate revocation requests by third parties who have a copy of the private key and who can demonstrate key compromise.
4.9.12 Special Requirements Related of Key Compromise	This section 4.9.12 needs to explain how someone with possession of the private key can demonstrate that the private key has been compromised. See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation.
5.7.3 Key Compromise	Mozilla and other root stores need to be notified if there is a compromise of the SERPRO SSL CA private key.

Add Autoridade Certificadora do Serpro SSLv1

Initial Notes: