CERTISIGN ROOT CERTIFICATE AUTHORITY REQUEST
Categories
(CA Program :: CA Certificate Root Program, task)
Tracking
(Not tracked)
People
(Reporter: patricia.leite, Assigned: bspirandelli)
References
Details
(Whiteboard: [ca-cps-review] - Pending CA Response to Comment 42)
Attachments
(14 files, 3 obsolete files)
|
4.78 MB,
application/x-zip-compressed
|
Details | |
|
202.06 KB,
application/pdf
|
Details | |
|
813.70 KB,
application/pdf
|
Details | |
|
1.59 KB,
application/x-x509-ca-cert
|
Details | |
|
59.14 KB,
application/pdf
|
Details | |
|
57.73 KB,
application/pdf
|
Details | |
|
38.55 KB,
application/pdf
|
Details | |
|
37.20 KB,
application/pdf
|
Details | |
|
155.43 KB,
application/pdf
|
Details | |
|
784.32 KB,
application/pdf
|
Details | |
|
747.54 KB,
application/pdf
|
Details | |
|
775.75 KB,
application/pdf
|
Details | |
|
6.94 MB,
application/x-zip-compressed
|
Details | |
|
15.53 KB,
application/x-zip-compressed
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Steps to reproduce: Hello everyone. I´ve made a mistake and cant access bug 1476739 anymore. I´ve just check-out the "security" issue as asked for Kathleen. so, let´s redo it. Certisign requests to operate as a Root CA under Mozilla Root Program. Certisign is a certification authority with 22 years operating history in Brazil. It was created in 1996 to issue SSL certificates operating under Symantec Trust Network. Certisign also issue end-users certificates into Brazilian official PKI(ICP-Brasil) from its beginning. Since then, Certisign has been the CA leader in Brazilian market, issuing more than 100,000 certificates per month.
|
||
Comment 2•6 years ago
|
||
Acknowledging receipt of this root inclusion request. I have a huge backlog of CA updates/requests to review, so this has been added to my list. I will update this bug when I begin information verification of this request as per step #2 of our process: https://wiki.mozilla.org/CA/Application_Process#Process_Overview
|
|
||
Comment 3•6 years ago
|
||
It will take me a while longer before I get to this request. Just updating the Whiteboard for now.
|
|
||
Comment 4•6 years ago
|
||
|
|
||
Comment 5•6 years ago
|
||
|
|
||
Comment 6•6 years ago
|
||
|
|
||
Comment 7•6 years ago
|
||
The CP/CPS documents are as follows. Certisign Trust Network CPS (mostly refers to the CP): http://ctn.certisign.com.br/ctn/pc/pc-certisign-trust-network-authority.pdf Certisign Trust Network CP: http://ctn.certisign.com.br/ctn/dpc/dpc-certisign-trust-network-authority.pdf "This CP is applicable to CERTISIGN ROOT CERTIFICATION AUTHORITY and Subordinates CAs: - CERTISIGN SSL CERTIFICATION AUTHORITY - CERTISIGN SSL EV CERTIFICATION AUTHORITY CERTISIGN Subordinates CAs operate as CAs under CERTISIGN TRUST NETWORK CP, issuing end-user subscriber certificates." Root CPS: http://ctn.certisign.com.br/root/dpc/dpc-certisign-root-certification-authority.pdf "This CPS is applicable to CERTISIGN ROOT CERTIFICATION AUTHORITY." SSL CPS http://ctn.certisign.com.br/ssl/dpc/dpc-certisign-ssl-certification-authority.pdf "This CPS is applicable to CERTISIGN SSL CERTIFICATION AUTHORITY, who operates as CAs under CERTISIGN TRUST NETWORK CP, issuing end-user subscriber certificates." EV SSL CPS http://ctn.certisign.com.br/ssl-ev/dpc/dpc-certisign-ssl-ev-certification-authority.pdf "This CPS is applicable to CERTISIGN SSL EV CERTIFICATION AUTHORITY, who operates as CAs under CERTISIGN TRUST NETWORK CP, issuing end-user subscriber certificates." CA CPS: http://ctn.certisign.com.br/certisign-ca/dpc/dpc-certisign-ca-certification-authority.pdf "This CPS is applicable to CERTISIGN CERTIFICATION AUTHORITY, who operates as CAs under CERTISIGN TRUST NETWORK CP, issuing end-user subscriber certificates." 1) Please explain the purpose of the dpc-certisign-ca-certification-authority.pdf document (CA CPS). I thought it might be for the subCAs for non-SSL certs, but it has detailed domain validation procedures. 2) Are you requesting that the email (S/MIME) trust bit also be enabled for this root certificate? If yes, then where in the CP/CPS is the description of how the CA/RA verifies that the certificate subscriber owns/controls the email address to be included in the cert? https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control 3) I looked through all of the CP/CPS documents, but could not find the permitted CAA domain(s). I see section 3.2.2.8, but I could not find the permitted CAA domain(s) in there. https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CAA_Domains_listed_in_CP.2FCPS 4) I noted in the CP: "Either the value id‐kpserverAuth [RFC5280] or id‐kp‐clientAuth [RFC5280] or both values MUST be present." Please see action #3 in our recent CA Communication about this: https://wiki.mozilla.org/CA/Communications#September_2018_CA_Communication
|
|
||
Comment 8•6 years ago
|
||
|
|
||
Comment 9•6 years ago
|
||
ALso, Please update the test websites to serve up the intermediate cert with the SSL cert.
|
|
||
Comment 10•6 years ago
|
||
|
|
||
Comment 11•6 years ago
|
||
|
|
||
Comment 12•6 years ago
|
||
|
|
||
Comment 13•6 years ago
|
||
|
|
||
Comment 14•6 years ago
|
||
I attached the audit statements I found in the zip file. Missing the WebTrust CA audit statement, please attach. Please also attach any other relevant audit statements. I'm not familiar with this particular auditor: "Ernst & Young Auditores Independentes S.S." So I'll have to dig into that later -- to find out if "Auditores Independentes S.S." is part of the EY in this list: http://www.webtrust.org/licensed-webtrust-practitioners-international/item64419.aspx I'm seeing that the certs for the test websites were create 2018-06-13T20:17:35Z And the point-in-time audits performed on June 14th 2018. When do you plan to have the period-of-time audits? BRs section 8.1: "If the CA does not have a currently valid Audit Report indicating compliance with one of the audit schemes listed in Section 8.1, then, before issuing Publicly-Trusted Certificates, the CA SHALL successfully complete a point-in-time readiness assessment performed in accordance with applicable standards under one of the audit schemes listed in Section 8.1. The point-in-time readiness assessment SHALL be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and SHALL be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate. Please also make sure that all audit statements meet Mozilla's requirements: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#314-public-audit-information
|
|
||
Comment 15•6 years ago
|
||
|
|
||
Updated•6 years ago
|
|
Reporter | |
Comment 16•5 years ago
|
||
Kathleen Wilson, good morning!
First of all, sorry for the delay on answering this bug.
We decided to wait the Period of time reports to answer the bug.
I´ve attached your requests and ours answers at "CERTISIGN _ Mozilla_answers_201901"
|
|
Reporter | |
Comment 17•5 years ago
|
||
|
|
Reporter | |
Comment 18•5 years ago
|
||
Good morning.
I´ve defined wrongly the "the content type" of "9039503: CERTISIGN´s Mozilla answers update at 2019-01-28"
Please consider this one.
|
|
||
Comment 19•5 years ago
|
||
|
|
||
Comment 20•5 years ago
|
||
|
|
||
Comment 21•5 years ago
|
||
|
|
||
Comment 22•5 years ago
|
||
The link below shows the CA information that has been verified. Search in the page for the word "NEED" to see where further clarification is requested.
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000328
In particular:
-
If the audit statements/seals are on the CPA Canada website, then please send me the URL to the WebTrust seals.
-
Per section 7.1.3 of the CP and CPS documents, it appears that SHA-1 certs are still allowed to be issued in this CA Hierarchy, as long as they do not have the CABF Algorithm object identifier.
Please see https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Issuance_of_SHA-1_Certificates
and section 7.1.3 of the CA/Browser Forum's Baseline Requirements. -
OCSP appears to not be working or to not be set up properly. This causes the Revoked test website to not show up as revoked in my browser even though I have "Check OCSP" set.
You can also see this problem in the OCSP section of
https://certificate.revocationcheck.com/revokedevssl.certisign.com.br
This also causes errors when checking the revocation setup for the valid test website
https://certificate.revocationcheck.com/trustedevssl.certisign.com.br
Errors:
http://ocsp-certisign-ssl-ev-ca.certisign.com.br (GET)
Unexpected HTTP response: 404 Not Found
http://ocsp-certisign-ssl-ev-ca.certisign.com.br (POST)
Unexpected HTTP response: 500 Server Error
http://ocsp-certisign-ssl-ev-ca.certisign.com.br (UNKNOWN)
Unexpected HTTP response: 404 Not Found
This also causes EV testing to fail.
- Please resolve Lint test ERRORS
https://crt.sh -> Advanced -> Certificate Linter
Input trustedevsslcertisigncombr.crt
output:
cablint ERROR Constraint failure in CertificatePolicies: ASN.1 constraint check failed: policyQualifiers: constraint failed (PolicyInformation.c:31)
PS: I also ran that test on the subCA, and got the following notices. I'm providing this info in case it helps you figure out what's going wrong with OCSP.
Input: CERTISIGNSSLEVCERTIFICATIONAUTHORITY.crt
output:
cablint INFO CA certificate identified
zlint WARNING Subordinate CA Certificate: authorityInformationAccess SHOULD also contain the HTTP URL of the Issuing CA's certificate.
zlint NOTICE Root and Subordinate CA Certificates that wish to use their private key for signing OCSP responses will not be able to without their digital signature set
|
|
Reporter | |
Comment 23•5 years ago
|
||
Good morning!
Here are our answers to the “needs” requirements:
a) We´ve already correct or complement this issues:
• General information about CA's associated organization
Problem Reporting Mechanism
NEED: An email address (that the CA closely monitors) for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, or any other matter related to certificates
CERTISIGN ANSWER: normas@certisign.com.br is an email address that we closely monitors and is assigned as point of contact in all CP/CPS
• CP/CPS and Audit Statements
Standard Audit ALV Comments
BR Audit ALV Comments
EV SSL Audit ALV Comments
NEED: If the Webtrust seal is available on the CPA Canada, please provide the link. Otherwise Kathleen will need to send email to EY to confirm the authenticity of the document.
CERTISIGN ANSWER: The links were made available by CPA and are in our site at https://www.certisign.com.br/certisign/institucional
Click over "WEBTRUST" image, that will open an sub-page with all our current WEBTRUST seals.
https://www.cpacanada.ca/webtrustseal?sealid=10110
https://www.cpacanada.ca/webtrustseal?sealid=10111
https://www.cpacanada.ca/webtrustseal?sealid=10112
NOTE: these links are valid only if they are opened from Certisign webpages. Otherwise you will receive a message saying that the link is not valid.
• Forbidden and Potentially Problematic Practices
CA's Response to Forbidden Practices
8. Issuance of SHA-1 Certificates: CP/CPS sections 6.1.5, 7.1.3
NEED: Per section 7.1.3 of the CP and CPS documents, it appears that SHA-1 certs are still allowed to be issued in this CA Hierarchy, as long as they do not have the CABF Algorithm object identifier.
Please see https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Issuance_of_SHA-1_Certificates and section 7.1.3 of the CA/Browser Forum's Baseline Requirements.
CERTISIGN ANSWER: we have already correct and republished our policies.
• CA Hierarchy Information
Description of PKI Hierarchy
NEED: CA to enter their intermediate certs into the CCADB as described here: https://ccadb.org/cas/intermediates#adding-intermediate-certificate-data
Kathleen needs to issue CCADB CA Community License to the CA first.
CERTISIGN ANSWER: I´ve understand that we must wait Mozilla actions first
b) We are working on these subjects and will present evidences in 2 weeks:
• Test Websites or Example Cert
Test Notes
NEED: OCSP appears to not be working or to not be set up properly.
This causes the Revoked test website to not show up as revoked in my browser even though I have "Check OCSP" set. You can also see this problem in the OCSP section of https://certificate.revocationcheck.com/revokedevssl.certisign.com.br
• Test Results (When Requesting the SSL/TLS Trust Bit)
Revocation Tested
NEED: Fix OCSP
https://certificate.revocationcheck.com/trustedevssl.certisign.com.br
http://ocsp-certisign-ssl-ev-ca.certisign.com.br (GET)
Unexpected HTTP response: 404 Not Found
http://ocsp-certisign-ssl-ev-ca.certisign.com.br (POST)
Unexpected HTTP response: 500 Server Error
http://ocsp-certisign-ssl-ev-ca.certisign.com.br (UNKNOWN)
Unexpected HTTP response: 404 Not Found
EV Tested
NEED: Fix OCSP
https://tls-observatory.services.mozilla.com/static/ev-checker.html with https://trustedevssl.certisign.com.br/ and 1.3.6.1.4.1.30253.17
Results in error: The response from the OCSP server was corrupted or improperly formed.
CERTISIGN ANSWER:
c) We´re having some difficulties in understanding these errors. Could you recommend any URL or technical person to discuss about them?
CA/Browser Forum Lint Test
NEED: Resolve Lint test ERRORS
https://crt.sh -> Advanced -> Certificate Linter
Input trustedevsslcertisigncombr.crt
output: cablint ERROR Constraint failure in CertificatePolicies: ASN.1 constraint check failed: policyQualifiers: constraint failed (PolicyInformation.c:31)
Test Website Lint Test
NEED: CA also found the error in their testing:
E: Constraint failure in CertificatePolicies: ASN.1 constraint check failed: policyQualifiers: constraint failed (PolicyInformation.c:31) trustedssl.cer
best regards
Patricia T O Leite
CERTISIGN CERTIFICADORA DIGITAL S.A.
|
|
||
Comment 24•5 years ago
|
||
The link below shows the CA information that has been verified.
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000328
(In reply to Patricia Leite from comment #23)
current WEBTRUST seals.
https://www.cpacanada.ca/webtrustseal?sealid=10110
https://www.cpacanada.ca/webtrustseal?sealid=10111
https://www.cpacanada.ca/webtrustseal?sealid=10112
entered into CCADB, and ALV passed.
CA's Response to Forbidden Practices
8. Issuance of SHA-1 Certificates: CP/CPS sections 6.1.5, 7.1.3
NEED: Per section 7.1.3 of the CP and CPS documents, it appears that SHA-1 certs are still allowed to be issued in this CA Hierarchy, as long as they do not have the CABF Algorithm object identifier.
Please see https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Issuance_of_SHA-1_Certificates and section 7.1.3 of the CA/Browser Forum's Baseline Requirements.
CERTISIGN ANSWER: we have already correct and republished our policies.
verified
Description of PKI Hierarchy
NEED: CA to enter their intermediate certs into the CCADB as described here: https://ccadb.org/cas/intermediates#adding-intermediate-certificate-data
Kathleen needs to issue CCADB CA Community License to the CA first.
CERTISIGN ANSWER: I´ve understand that we must wait Mozilla actions first
We will issue a CCADB CA Community License to you, and you will receive email when that happens.
OCSP Problems
We are working on these subjects and will present evidences in 2 weeks:
Maybe the following will help identify the OCSP problems
Input: CERTISIGNSSLEVCERTIFICATIONAUTHORITY.crt
output:
cablint INFO CA certificate identified
zlint WARNING Subordinate CA Certificate: authorityInformationAccess SHOULD also contain the HTTP URL of the Issuing CA's certificate.
zlint NOTICE Root and Subordinate CA Certificates that wish to use their private key for signing OCSP responses will not be able to without their digital signature set
EV Test Results in error: The response from the OCSP server was corrupted or improperly formed.
CERTISIGN ANSWER:
We´re having some difficulties in understanding these errors. Could you recommend any URL or technical person to discuss about them?
I think the EV test failures will be resolved when you get OCSP working correctly.
|
|
||
Comment 25•5 years ago
|
||
Update:
-
The CA has entered the intermediate cert data into the CCADB.
-
EV test passes
-
https://certificate.revocationcheck.com/trustedevssl.certisign.com.br
only has these errors now:
http://certisign-ca.certisign.com.br/certisignsslevca/lcr/LatestCRL.crl
ERROR: NextUpdate is 1s before the date in the Expires cache header
http://ocsp-certisign-ssl-ev-ca.certisign.com.br (GET)
ERROR: Response is not yet valid
Patricia, Please resolve those errors.
https://crt.sh/?caid=115641&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
ERROR: Constraint failure in CertificatePolicies: ASN.1 constraint check failed: policyQualifiers: constraint failed (PolicyInformation.c:31)
failed for the 3 test website certs.
Patricia, Please resolve or explain this error.
|
|
Reporter | |
Comment 26•5 years ago
|
||
Kathleen, good morning!
We attached the tests made yesterday when errors mentioned were solved.
|
|
Reporter | |
Comment 27•5 years ago
|
||
|
|
||
Comment 28•5 years ago
|
||
I'm still seeing errors...
-
https://certificate.revocationcheck.com/trustedevssl.certisign.com.br
is listing these errors:
http://certisign-ca.certisign.com.br/certisignsslevca/lcr/LatestCRL.crl
ERROR: NextUpdate is 1s before the date in the Expires cache header
http://certisign-ca.certisign.com.br/certisignrootca/lcr/LatestCRL.crl
ERROR: NextUpdate is 4h53m28s before the date in the Expires cache header
ERROR: The Cache-Control max-age header outlives NextUpdate with 4h53m28s
http://ocsp-certisign-ssl-ev-ca.certisign.com.br (GET)
ERROR: Response is not yet valid -
Please also resolve or explain this error:
https://crt.sh/?caid=115641&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
ERROR: Constraint failure in CertificatePolicies: ASN.1 constraint check failed: policyQualifiers: constraint failed (PolicyInformation.c:31)
failed for the 3 test website certs.
|
|
Reporter | |
Comment 29•5 years ago
|
||
Kathleen Wilson, good morning!
Here are our answers:
- https://certificate.revocationcheck.com/trustedevssl.certisign.com.br is listing these errors:
a) http://certisign-ca.certisign.com.br/certisignsslevca/lcr/LatestCRL.crl
ERROR: NextUpdate is 1s before the date in the Expires cache header
&
b) http://certisign-ca.certisign.com.br/certisignrootca/lcr/LatestCRL.crl
ERROR: NextUpdate is 4h53m28s before the date in the Expires cache header
ERROR: The Cache-Control max-age header outlives NextUpdate with 4h53m28s
[CERTISIGN] These errors occur due to the fact that our CA software generates the LCR / OCSP internally and then publishes this information in an external directory / service.
So, occasionally the date of the published data may have a difference of 1 second for the date entered in the LCR / OCSP, causing these error messages.
If you use the "Certificate Upload" option at https://certificate.revocationcheck.com/ the error messages don´t appear.
As “TLS / SSL Connection" option uses cach the errors should remain.
c) http://ocsp-certisign-ssl-ev-ca.certisign.com.br (GET)
ERROR: Response is not yet valid
[CERTISIGN] We are still working on it.
- https://crt.sh/?caid=115641&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
ERROR: Constraint failure in CertificatePolicies: ASN.1 constraint check failed: policyQualifiers: constraint failed (PolicyInformation.c:31)
failed for the 3 test website certs.
[CERTISIGN] We re-issued the test website certs in order to correct this error. Use them ((certificates.zip)) to test certilint e X509lint
|
|
Reporter | |
Comment 30•5 years ago
|
||
these certificates must be used to complete 7th,June,2019 analisys
|
|
Reporter | |
Comment 31•5 years ago
|
||
Hello!
Here is our last response:
c) http://ocsp-certisign-ssl-ev-ca.certisign.com.br (GET)
ERROR: Response is not yet valid
[CERTISIGN] "Response is not yet valid" error can occur when the certificate status check request is made up to 300 milliseconds or less for the second turn.
That's because our service (Application + web server) takes 300 milliseconds to respond to the client's request.
best regards
Patricia Leite
CERTISIGN S.A.
|
|
||
Comment 32•5 years ago
|
||
(In reply to Patricia Leite from comment #31)
Hello!
Here is our last response:
c) http://ocsp-certisign-ssl-ev-ca.certisign.com.br (GET)
ERROR: Response is not yet valid
[CERTISIGN] "Response is not yet valid" error can occur when the certificate status check request is made up to 300 milliseconds or less for the second turn.
That's because our service (Application + web server) takes 300 milliseconds to respond to the client's request.
I don't understand the explanation, but I checked again, and I still see the same error.
https://certificate.revocationcheck.com/trustedevssl.certisign.com.br
|
|
Reporter | |
Comment 33•5 years ago
|
||
(In reply to K Wilson from comment #32)
[CERTISIGN]
I think my bad english didn´t make you understand my explanation....
The "Response is not yet valid" error occurs because our infrastructure, based on best practices, keeps the OCSP service segregated across a different network segment of the front end.
We have servers to attend the client on the front end, segregated from the OCSP service servers in the backend by firewall.
The time lag between front-end receipt, forwarding to the back-end, back-end response, forwarding to the front end, and customer response is about 300 milliseconds.
When the OCSP demand is routed close to the next second, the answer forwarded in the next second.
If several tests are performed (waiting for buffer expiration), it is possible to identify successful tests (that is, response in the same second).
|
||
Comment 34•5 years ago
|
||
(In reply to Patricia Leite from comment #33)
(In reply to K Wilson from comment #32)
[CERTISIGN]
I think my bad english didn´t make you understand my explanation....
The "Response is not yet valid" error occurs because our infrastructure, based on best practices, keeps the OCSP service segregated across a different network segment of the front end.
We have servers to attend the client on the front end, segregated from the OCSP service servers in the backend by firewall.
The time lag between front-end receipt, forwarding to the back-end, back-end response, forwarding to the front end, and customer response is about 300 milliseconds.
When the OCSP demand is routed close to the next second, the answer forwarded in the next second.
If several tests are performed (waiting for buffer expiration), it is possible to identify successful tests (that is, response in the same second).
Patricia: I also do not understand this response. Are you saying that the clock on the CERTISIGN OCSP signer is slightly ahead of the clock on the revocationcheck.com website, or that the revocationcheck.com website is incorrectly comparing the thisUpdate time in the OCSP response to its clock time? Or are you saying that the CERTISIGN system will sometimes return OCSP responses that are timestamped slightly in the future? Or something else is wrong?
|
|
Reporter | |
Comment 35•5 years ago
|
||
Hello!
We´ve identified an internal error. Could you please checked again?
Best Regards
Patricia Leite
|
|
Reporter | |
Comment 36•5 years ago
|
||
Hello!
Is there any news about it?
Best Regards
|
|
||
Comment 37•5 years ago
|
||
The information for this root inclusion request is available at the following URL.
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000328
This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.
There is a queue waiting for detailed CP/CPS reviews:
https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review
It takes significant time and concentration to do a detailed CP/CPS review, so please be patient. In the meantime, I recommend looking at the results of the detailed CP/CPS reviews that have been previously completed.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21
|
|
Reporter | |
Comment 38•5 years ago
|
||
Hello!
Is there any news about it?
Best Regards
|
|
||
Comment 39•5 years ago
|
||
(In reply to Patricia Leite from comment #38)
Hello!
Is there any news about it?
Best Regards
Per Comment #37, you can watch the queue here:
https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review
(Click on the "Whiteboard" column to sort so you can see the CP/CPS Reviews based on date they entered the queue.)
|
Assignee | |
Comment 40•4 years ago
|
||
Hello!
I am Certisign's new contact for interactions on this ID.
Do we have any news about this process?
Thank you.
Best Regards.
|
|
||
Comment 41•4 years ago
|
||
If you sort https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review by the "Whiteboard" column, you can see that there are three requests in the queue ahead of yours. The request with the oldest date in the Whiteboard field is the one that will be reviewed next.
Please note that the 'needinfo' flag is used to notify others that you need their response. I have cleared the 'needinfo' you set for yourself.
|
||
Updated•4 years ago
|
|
|
||
Comment 42•4 years ago
|
||
Certisign CP/CPS Review based on:
http://ctn.certisign.com.br/ctn/pc/pc-certisign-trust-network-authority_v1.6a.pdf
http://ctn.certisign.com.br/ssl/dpc/dpc-certisign-ssl-certification-authority_v1.5.pdf
http://ctn.certisign.com.br/ssl-ev/dpc/dpc-certisign-ssl-ev-certification-authority_v1.5.pdf
Title page
The CP and CPS must be revised and updated annually. Mozilla Root Store Policy 3.3.4 - https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses
Table of Contents
Good - Document follows the RFC 3647 framework.
\1. Introduction
First bullet says, “CERTISIGN TRUST NETWORK PKI service providers who have to operate in terms of their own Certificate Practices (CP) that complies with the requirements laid down by the CPS,” which raises the question, who are the PKI service providers affiliated with or working with Certisign in providing the PKI services described in this CPS?
References to CA/Browser Forum guidelines are outdated and need to be updated. The specific references could be replaced with language about complying to “the then-current” version of each of the specified CABF Guidelines.
1.1 Overview
Typo – “throught”
Reference made to “Affiliates act as RAs”. Who are affiliates?
RAs and Enterprise RAs may not perform domain validation. The CPS should explicitly say that delegation of domain validation to third parties is prohibited.
1.2.1 CABF Policy Identifiers
Title “CABF Policy Identifiers” should be changed to just “Policy Identifiers”
What does the “16” stand for at the end of the OID?
1.2.2 Revision
Table is good. It shows document change control.
1.3 PKI Participants
Cross reference to Certisign CP makes it difficult to evaluate Certisign’s PKI Practices.
Certisign Network CP has not been updated in over one year.
Certisign CP section 1.3.2 clarifies that RAs are not allowed to perform domain and IP address validation under sections 3.2.2.4 and 3.2.2.5 of the CP, but this is not stated as the practice in the CPS.
1.4 Certificate Usage
Typo or wrong word ”throught” in sentence, “CERTISIGN SSL CERTIFICATE AUTHORITY issues certificate to be used by Subscribers to secure websites throught Organization Validation.”
1.5.2 Contact person
BR Section 4.9.3 requires that this section 1.5.2 contain 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.
2.2 Publication of Information
Typo – publishs
2.3 Time or Frequency of Publication
Section 2.3 of the CP states that Certisign updates the CP and CPS at least annually, but those updates have not yet been made publicly available in over a year.
2.4 Access Controls on Repositories
CP states that “CERTISIGN and Affiliates SHALL, however, require persons to agree to a Relying Party Agreement or CRL Usage Agreement as a condition to accessing Certificates, Certificate status information or CRLs.” How is this implemented?
3.1.1 Type of Names (EV SSL CPS)
For Table 2, review and update it in accordance with section 9.2 of the EV Guidelines.
3.1.1.1 CABF Naming Requirements
Good - Section asserts that DV and OV SSL Certificates conform to the CA / Browser Forum Baseline requirements, but section 3.1.1.1 of the EV CPS shouldn’t have that language.
For Issuer Organization Name, the CP and CPS state, “The field MUST NOT contain a generic designation such as “Root” or “CA1””. I think that requirement was removed from the BRs. It wasn’t an entirely accurate. The field must not contain “only” a generic designation. (The CN has to be somewhat descriptive.) I think this sentence could be deleted from the CP and CPS.
“Issuer commonName (Optional)” is misleading. Section 7.1.4.3.1. of the Baseline Requirements makes the CN field in CA’s subject required. “Contents: This field MUST be present and the contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate.”
These comments apply equally to the EV CPS. Section 3.1.1.1 of the EV CPS should be updated in accordance with Section 9.2 of the EV Guidelines.
3.1.3 Anonymity or Pseudonymity of Subscribers
Section 3.2.2 of the Baseline Requirements says that if the certificate asserts an identity, that identity must be verified. Section 7.1.4.2.2 of the Baseline Requirements requires that the contents of the certificate are what has been verified. In other words, pseudonymity is not allowed for OV and EV. (DV certificates don’t contain such information, so one could argue there is some anonymity with DV.)
3.2.1.1. CABF Verification Requirements for EV
This section seems misplaced. (It’s located as a subsection of 3.2.1 Method to Prove Possession of Private Key.) Shouldn’t it be a subsection to section 3.2.2?
3.2.2.4. Validation of Domain Authorization or Control
This section of the BRs has been revised.
Please describe in detail if these methods are used and how your CA meets the BR section 3.2.2.4 requirements.
3.2.2.4.1 Validating the Applicant as a Domain Contact
This method SHALL NOT be used.
3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
Allowed
3.2.2.4.3 Phone Contact with Domain Contact
This method has been replaced by 3.2.2.4.15 and SHALL NOT be used. (Validations completed as of 31-May-2019 may be used until 20-August-2021.)
3.2.2.4.4 Constructed Email to Domain Contact
Allowed
3.2.2.4.5 Domain Authorization Document
This method SHALL NOT be used for validation.
3.2.2.4.6 Agreed‐Upon Change to Website
Replaced with BR section 3.2.2.4.18 (effective 3/3/2020)
3.2.2.4.7 DNS Change
Allowed
3.2.2.4.8 IP Address
Allowed
3.2.2.4.9 Test Certificate
This method SHALL NOT be used.
3.2.2.4.10. TLS Using a Random Number
Allowed (This subsection contains major vulnerabilities. If the CA uses this method, then the CA should describe how they are mitigating those vulnerabilities. If not using this method, the CPS should say so.)
3.2.2.4.11 Any Other Method
This method SHALL NOT be used.
3.2.2.4.12 Validating Applicant as a Domain Contact
This method may only be used if the CA is also the Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name.
3.2.2.4.13 Email to DNS CAA Contact
Allowed
3.2.2.4.14 Email to DNS TXT Contact
Allowed
3.2.2.4.15 Phone Contact with Domain Contact
Allowed
3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact
Allowed
3.2.2.4.17 Phone Contact with DNS CAA Phone Contact
Allowed
3.2.2.4.18 Agreed-Upon Change to Website v2
Allowed
3.2.2.4.19 Agreed-Upon Change to Website - ACME
Allowed
3.2.2.5. Authentication for an IP Address
This section of the BRs has been revised.
Please describe in detail if these methods are used and how your CA meets the BR section 3.2.2.5 requirements.
3.2.2.5.1. Agreed-Upon Change to Website
Allowed
3.2.2.5.2. Email, Fax, SMS, or Postal Mail to IP Address Contact
Allowed
3.2.2.5.3. Reverse Address Lookup
Allowed
3.2.2.5.4. Any Other Method
This method SHALL NOT be used.
3.2.2.5.5. Phone Contact with IP Address Contact
Allowed
3.2.2.5.6 ACME “http-01” method for IP Addresses
Allowed
3.2.2.5.7 ACME “tls-alpn-01” method for IP Addresses
Allowed
3.2.2.7 (EV CPS)
The EV Guidelines have different sections for this -- 11.11.5 Qualified Independent Information Source; 11.11.6 Qualified Government Information Source; and 11.11.7 Qualified Government Tax Information Source.
3.2.2.8. CAA Records
Please note that RFC 6844 has been replaced by RFC 8659 (even though the Baseline Requirements have not yet been updated).
3.2.2.9 CABF Verification Requirements for Organization Applicants
The title doesn’t seem to match the discussion of IDNs and domain names.
3.2.3 Authentication of Individual Identity (EV CPS)
Section 11.2.1(3), 11.2.2(3) and (4), and 11.11.3 of the EV Guidelines set forth the requirements for this section 3.2.3 of the CPS. Also, the EV Guidelines don’t use “Reliable Method of Communication”. Instead they use “Verified Method of Communication.”
3.2.4 Non-Verified Subscriber information (EV CPS)
Section 9.2.7 of the EV Guidelines allows the OU field if the CA “has verified this information in accordance with Section 11.” Thus, I don’t think it is “non-verified” information.
3.2.5 Validation of Authority (EV CPS)
The EV Guidelines don’t use “Reliable Method of Communication”. Instead they use “Verified Method of Communication.” Section 11.5.2 of the EV Guidelines specifies how to establish a “Verified Method of Communication” with the Applicant. Section 3.2.2.1 of the EV CPS cannot be used as the basis for establishing a Verified Method of Communication. Sections 11.8, 11.9, and 11.10 of the EV Guidelines specify how authority is validated.
3.2.6 Criteria for Interoperation
Section 8 of the Mozilla Root Store Policy requires that Mozilla receive notice whenever “an organization other than the CA obtains control of an unconstrained intermediate certificate (as defined in section 5.3.2 of [the Mozilla Root Store Policy]) that directly or transitively chains to the CA's included certificate(s).” See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#8-ca-operational-changes
4.1.2.2.1 SSL Certificates
This section references “aging and updating” which is not found in section 3.3.1. Currently for DV and OV certificates, information may be reused for 825 days (BR 4.2.1 and SSL CPS section 4.2.1.1-see below). For EV certificates, the reuse period is 13 months (EVG 11.14.3). (This EV period appears to be stated in Appendix C, Item 14.3, of the CP and EV CPS.)
Also, the phrase “in order to comply with these Requirements and the CA’s Certificate Policy and/or Certification Practice Statement” appears to be a copy-and-paste and not customized by Certisign.
4.2.1 Performing Identification and Authentication Functions
Only for DV certificates is the following absolutely correct: “Applicant information MUST include, but not be limited to, at least one FQDN or IP address to be included in the Certificate’s SubjectAltName extension.” (Applicant information for OV and EV certificates must include more information than just what is in the SAN.)
4.2.1.1. CABF Requirements for SSL Certificates
SSL CPS - Because it is now after March 1, 2018, some of this language can be removed.
EV SSL CPS – This is inaccurate. This should be replaced with reference to the 13 months in section 14.3 of Appendix C.
4.2.2.1. CABF Requirements for SSL Certificates
This language is obsolete and can be deleted. (It is addressed in Certisign CP/CPS section 7.1.4.2.1.1 - Reserved IP Address or Internal Names).
4.2.4 CABF Certificate Authority Authorization (CAA) Requirement
The Baseline Requirements now contain more items that must be discussed in a CA’s CP/CPS. Please review BR section 2.2.
4.5.1 Subscriber Private Key and Certificate Usage
Since Subscriber Keys are not being escrowed, “except as set forth in section 4.12” should be deleted.
4.9.1.2. Reasons for Revoking a Subordinate CA Certificate
The CPSes should contain the language in BR 4.9.1.2, or at least cross-reference CP section 4.9.1.2.
4.9.8 Maximum Latency for CRLs
The content about OCSP information isn’t proper for this section. Also, the following sentences are confusing and should be deleted. “Processing Centers shall have a web-based repository that permits Relying Parties to make online inquiries regarding revocation and other Certificate status information. A Processing Center, as part of its contract with a Service Center, shall host such a repository on behalf of the Service Center.” The location for OCSP responders should be embedded in the AIA extension of the certificate. That OCSP information needs to appear in either section 4.9.10 or section 4.10.
5.3.7.1. CABF Requirements for Delegation of Functions to Registration Authorities and Subcontractors for EV and EV Code Signing Certificates
The first sentence should be amended to prohibit the delegation of domain validation. “CERTISIGN MAY delegate the performance of all or any part of a requirement, except domain validation, to an Affiliate or a Registration Authority (RA) or subcontractor …”
5.7.3 Entity Private Key Compromise Procedures
According to section 4 of the CCADB Policy, “If an intermediate certificate is revoked, the CCADB must be updated to mark it as revoked, giving the reason why, within 24 hours for a security incident, and within 7 days for any other reason.” See https://www.ccadb.org/policy#4-intermediate-certificates
Below the phrase, “If CA Certificate revocation is REQUIRED, the following procedures are performed:” add something to the effect that Certisign will “update the CA record in the CCADB, giving the reason why, within 24 hours for a security incident, and within 7 days for any other reason.”
6.1.1.1. CABF CA Key Pair Generation Requirements
Mozilla Root Store Policy section 5.2 prohibits CAs from generating key pairs for subscribers. See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices
6.1.6 Public Key Parameters Generation and Quality Checking
Mozilla Root Store Policy section 5.1 also requires that RSA keys have a “modulus size that in bits is divisible by 8, and is at least 2048.” https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#51-algorithms
6.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field)
Why are keys used for SSL required to have the nonrepudiation bit? This seems contrary to RFC 5280, section 4.2.1.12. Extended Key Usage, which says that only digitalSignature, keyEncipherment or keyAgreement key usage bits are consistent with the serverAuth EKU.
6.5 Computer Security Controls
Should cross-reference CP section 6.5 instead of saying “not applicable”.
6.7 Network Security Controls
Should cross-reference CP section 6.7 instead of saying “not applicable”.
7.1.4.2.1. CABF Subject Alternative Name Extension Requirements
Section 7.1.4.2.1 of the Baseline Requirements simplifies some of this language concerning underscores: “Entries in the dNSName MUST be in the "preferred name syntax", as specified in RFC 5280, and thus MUST NOT contain underscore characters ("_").”
7.1.4.2.2. CABF Subject Distinguished Name Fields Requirements (EV CPS) and 7.1.4.2.3. Subject Distinguished Name Fields for EV Certificates
Section 7.1.4.2.2 of the EV SSL CPS is not needed (“Not applicable”) because all of the EV Subject Distinguished Name fields are set forth in section 7.1.4.2.3 of the Certisign EV SSL CPS.
7.1.5 Name Constraints
This section is to discuss the application of name constraints to subordinate CAs, not certificate transparency.
7.1.6.4. Subscriber Certificates
Section 3.A.10 of the Microsoft Root Certificate Program Requirements ( https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#a-root-requirements) requires use of the CA/Browser Forum OIDs in Subscriber Certificates.
8.6 Communications of Results
Note that Mozilla and the CCADB Policy require that CAs provide annual updates of their audits. See https://www.ccadb.org/cas/updates; see also https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#3-documentation
Appendix A: Table of Acronyms and Definitions
Various definitions still reference the EV Guidelines without saying “EV Guidelines”. For example, “Section 11.11.1 of these Guidelines”, etc.
CICA has been renamed “CPA Canada”
The AICPA no longer runs the WebTrust Program. It is only run by CPA Canada.
“CPA” means “Chartered Professional Accountant” in Canada, and “Certified Public Accountant” in the U.S.
“Entry Date” should be “Expiry Date”
“VOID” should be “VoIP”
Appendix B: References
CA/Browser Forum document references need to be updated.
|
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
|
Assignee | |
Comment 43•4 years ago
|
||
Hi Ben,
We are changing the requested information.
Thank you.
Best regards.
|
|
||
Updated•4 years ago
|
|
|
||
Comment 44•3 years ago
|
||
The posted CPS is nearly 2 years old and the last audit on file is over two years old. No activity has occurred in over 8 months, so I am inclined to close this root certificate inclusion request.
|
|
||
Comment 45•3 years ago
|
||
Please respond or I will close this inclusion request on or about 5-Mar-2021.
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
||
Updated•2 years ago
|
Description
•