Re: Audit Reminder Email Summary
Forwarded Message Subject: Summary of March 2021 Audit Reminder Emails Date: Tue, 16 Mar 2021 19:02:12 + (GMT) Mozilla: Audit Reminder CA Owner: certSIGN Root Certificates: certSIGN ROOT CA Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239757 Standard Audit Period End Date: 2020-02-07 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239758 BR Audit Period End Date: 2020-02-07 CA Comments: null Mozilla: Audit Reminder CA Owner: Krajowa Izba Rozliczeniowa S.A. (KIR) Root Certificates: SZAFIR ROOT CA2 Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238854 Standard Audit Period End Date: 2019-12-18 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238855 BR Audit Period End Date: 2019-12-18 CA Comments: null Mozilla: Audit Reminder CA Owner: Government of Hong Kong (SAR), Hongkong Post, Certizen Root Certificates: Hongkong Post Root CA 3** Hongkong Post Root CA 1** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238797 Standard Audit Period End Date: 2019-12-31 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238798 BR Audit Period End Date: 2019-12-31 EV Audit: https://www.ecert.gov.hk/ev/Webtrust_EVSSL_2019.pdf EV Audit Period End Date: 2019-11-30 CA Comments: null Mozilla: Audit Reminder CA Owner: QuoVadis Root Certificates: QuoVadis Root CA 1 G3 QuoVadis Root CA 2 QuoVadis Root CA 2 G3 QuoVadis Root CA 3 QuoVadis Root CA 3 G3 QuoVadis Root Certification Authority Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239021 Standard Audit Period End Date: 2019-12-31 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239022 BR Audit Period End Date: 2019-12-31 EV Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239023 EV Audit Period End Date: 2019-12-31 CA Comments: null Mozilla: Audit Reminder CA Owner: Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) Root Certificates: AC RAIZ FNMT-RCM SERVIDORES SEGUROS FNMT-RCM - SHA256 Standard Audit: https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019-003%20-%20FNMT-v2.pdf Standard Audit Period End Date: 2020-01-12 BR Audit: https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%201%20ETSI%20319%20411-2%20PSC-2019-003%20-%20FNMT-v2.pdf BR Audit Period End Date: 2020-01-12 BR Audit: https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019-003%20-%20FNMT-v2.pdf BR Audit Period End Date: 2020-01-12 EV Audit: https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%201%20ETSI%20319%20411-2%20PSC-2019-003%20-%20FNMT-v2.pdf EV Audit Period End Date: 2020-01-12 CA Comments: null Mozilla: Audit Reminder CA Owner: Taiwan-CA Inc. (TWCA) Root Certificates: TWCA Global Root CA** TWCA Root Certification Authority** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238799 Standard Audit Period End Date: 2019-12-31 BR Audit: https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238800 BR Audit Period End Date: 2019-12-31 EV Audit: https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238801 EV Audit Period End Date: 2019-12-31 CA Comments: null Mozilla: Audit Reminder CA Owner: Trustis Root Certificates: Trustis Limited - Trustis FPS Root CA Standard Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=9146189 Standard Audit Period End Date: 2020-01-15 BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=9146189 BR Audit Period End Date: 2020-01-15 CA Comments: null Mozilla: Audit Reminder CA Owner: Asseco Data Systems S.A. (previously Unizeto Certum) Root Certificates: Certum Trusted Network CA 2 Certum CA Certum Trusted Network CA Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239794 Standard Audit Period End Date: 2020-02-10 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239795 BR Audit Period End Date: 2020-02-10 EV Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239796 EV Audit Period End Date: 2020-02-10 CA Comments: null Mozilla: Audit Reminder CA Owner: Government of The Netherlands, PKIoverheid (Logius) Root Certificates: Staat der Nederlanden Root CA - G3 Staat der Nederlanden EV Root CA Standard Audit:
Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA
On Tue, Mar 16, 2021 at 6:02 PM Pablo Díaz via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Said "additional" confirmation email, addressed to the domain > administrator, informs them that [Applicant Data] has requested an SSL > certificate for their domain [Domain] by [Request ID] request, and > instructs them to access a link (valid for 29 days, the email indicates the > expiration date) where they can manually confirm or reject the request by > clicking Confirm/Reject buttons. Can you describe more here? There are gaps here which seem to allow any number of insecure implementations. For example: - Sending a link that must be accessed to approved is known-insecure, as automated mail scanning software may automatically dereference links in e-mail (in order to do content inspection). Confirm/Reject buttons alone shouldn't be seen as sufficient to mitigate this, as that may vary based on how the crawler works. Requiring explicit entry of the random value is a necessary "human" measure (aka similar to a CAPTCHA) - You haven't described how the email address is constructed for these cases. The BRs only permit you to reuse the Random Value for 3.2.2.4.2, and if and only if the domain contact is the same for all of the requested domains. If, for example, you're using 3.2.2.4.4 (your #1 example), it would be inappropriate if hostmaster@apex1.example could approve a request for apex2.example, yet, as currently described, that seems to be possible, in that both hostmaster@apex1.example and hostmaster@apex2.example will receive the same Request ID to approve/reject the request. The reliance on 3.2.2.4.2 is also known to be dangerous (in that it relies on human inspection or OCR of otherwise unstructured text), which is why it's discouraged compared to other methods (like .7, .19, or .20, and if using e-mail, .13, .14). It's unclear how you extract the emails from the WHOIS results that you provide, and whether that's something the IRM performs or whether that's somehow programmatically driven. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA
> The reason we reject human error as a root cause, which you don't seem > to understand because you mention the engineers, is that failures are > NOT the fault of humans who make mistakes. They're the fault of the > system which failed to prevent the mistakes. > The mention of the engineers, coupled with the note in the incident > report about "Disciplinary Measures and Sanctions", suggests that ANF > intends to use the threat of punishment to try to prevent mistakes. I believe that you have overlooked many of the reinforcement measures that I indicated in my previous email for the sake of your final conclusion. Measures that show that in ANF AC, we work so that our systems avoid the errors that humans could make, and that these would prevent errors that other included CAs have made (I gave some examples). I pointed out several automated measures, however, the conclusion you reach is that we "intend to use the threat of punishment to try to prevent mistakes”... The existence of said document “Disciplinary Measures and Sanctions” is not “threat of punishment”, it is a normative and legal obligation, by ETSI EN 319 401, whose REQ-7.2-05 indicates “Appropriate disciplinary sanctions shall be applied to personnel violating TSP's policies or procedures”; which refers to clause 7.2.3 of ISO/IEC 27002:2013 for guidance: "There should be a formal and communicated disciplinary process in place to take action against employees who have committed an information security breach." Your interpretation that a “Disciplinary Measures and Sanctions” Policy is intended to intimidate our staff is far from reality. Contrary to that, this documented processes in an organization are intended to avoid arbitrariness and guarantee a unified criterion, which is known throughout the organization. _ Regarding Domain Control Validation, I apologize for trying to be brief in my previous answer. I will go into more detail, so that it can be understood how ANF AC proceeds to validate the requests: At the time of request, when indicating the domain or domains to be included in the certificate, the automated checks described in my previous email are performed (regarding correct format, posible errors, CAA Records, Google Safe Browsing list, ANF AC blocklist) to prevent an “invalid” request from proceeding. Because, it makes no sense to allow a request for an invalid domain to proceed, or for a domain with CAA RR containing unknown property tags with the Critical bit set, or with “issue” or “issuewild” that does not authorize issuance by ANF AC. Here, also a WHOIS lookup is made. It is important, for the explanation further below, to indicate that in the request we also require the applicant's phone number. Next, for each of the domains to be included, a drop-down email list is shown with the following options to choose from: 1) Constructed emails, using 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' + @ + apex domain (which would be method 3.2.2.4.4) 2) Result of the WHOIS lookup previously made, for the “technical contact”, or “administrative contact” (which would be method 3.2.2.4.2). This is in case the content of said contact is in email format. If the content is protected by privacy it is not listed. In the case of single-domain, when formalizing the request, two codes are sent via: - Request confirmation email: Contains the request ID (numeric), a random alphanumeric code valid for 29 days, and a download link for “ANF Certificate Manager” program. - SMS: Random code (code 2). In “ANF Certificate Manager” the applicant must enter the request ID, the email code and the SMS code. The program then shows all the request information (applicant info, data of the subject, DNS to include in SAN…) and the applicant must give confirmation. Said request is then sent to ANF AC in order to validate the rest of the documentation (explained further below), and proceed, if favorable, to the issuance of the certificate. NOTE: "ANF Certificate Manager" is a client desktop program that incorporates a tool so that the applicant can generate their key pair on their Windows PC. This makes it easier for the client to later download the issued certificate, and export to pfx if needed. Here I want to clarify that in NO case ANF AC generates the keys and returns them to the program, it is the program tool that generates the keys on the applicant's PC. (as I saw it was discussed at https://archive.cabforum.org/pipermail/servercert-wg/2020-May/001949.html). We also allow the option for the user to provide CSR that was generated by their preferred means. In case of multi-domain, it does not make sense to send N emails with instructions to download the program, since it only needs to be downloaded 1 time. Therefore, what the system does is: send the request confirmation email to one of the emails, and send an
Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days
That works, too. Thoughts? On Tue, Mar 16, 2021 at 5:21 AM Doug Beattie wrote: > Hi Ben, > > Regarding the redlined spec: > https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.7.1?short_path=73f95f7#diff-73f95f7d2475645ef6fc93f65ddd9679d66efa9834e4ce415a2bf79a16a7cdb6 > > Is this a meaningful statement given max validity is 398 days now? >5. verify that all of the information that is included in server > certificates remains current and correct at intervals of 825 days or less; > I think we can remove that and them move 5.1 to item 5 > > I find the words for this requirement 5.1 unclear. > > " 5.1. for server certificates issued on or after October 1, 2021, > verify each dNSName or IPAddress in a SAN or commonName at an interval of > 398 days or less;" > > Can we say: > "5.1. for server certificates issued on or after October 1, 2021, each > dNSName or IPAddress in a SAN or commonName MUST have been validated accordance with the CABF Baseline Requirements?> within the prior 398 days. > > > > -Original Message- > From: dev-security-policy > On Behalf Of Ben Wilson via dev-security-policy > Sent: Monday, March 8, 2021 6:38 PM > To: mozilla-dev-security-policy < > mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name > verification to 398 days > > All, > > Here is the currently proposed wording for subsection 5.1 of MRSP section > 2.1: > > " 5.1. for server certificates issued on or after October 1, 2021, verify > each dNSName or IPAddress in a SAN or commonName at an interval of 398 days > or less;" > > Ben > > On Fri, Feb 26, 2021 at 9:48 AM Ryan Sleevi wrote: > > > > > > > On Thu, Feb 25, 2021 at 7:55 PM Clint Wilson via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> I think it makes sense to separate out the date for domain validation > >> expiration from the issuance of server certificates with previously > >> validated domain names, but agree with Ben that the timeline doesn’t > >> seem to need to be prolonged. What about something like this: > >> > >> 1. Domain name or IP address verifications performed on or after July > >> 1, > >> 2021 may be reused for a maximum of 398 days. > >> 2. Server certificates issued on or after September 1, 2021 must have > >> completed domain name or IP address verification within the preceding > >> 398 days. > >> > >> This effectively stretches the “cliff” out across ~6 months (now > >> through the end of August), which seems reasonable. > >> > > > > Yeah, that does sound reasonable. > > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days
Hi Ben, Regarding the redlined spec: https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.7.1?short_path=73f95f7#diff-73f95f7d2475645ef6fc93f65ddd9679d66efa9834e4ce415a2bf79a16a7cdb6 Is this a meaningful statement given max validity is 398 days now? 5. verify that all of the information that is included in server certificates remains current and correct at intervals of 825 days or less; I think we can remove that and them move 5.1 to item 5 I find the words for this requirement 5.1 unclear. " 5.1. for server certificates issued on or after October 1, 2021, verify each dNSName or IPAddress in a SAN or commonName at an interval of 398 days or less;" Can we say: "5.1. for server certificates issued on or after October 1, 2021, each dNSName or IPAddress in a SAN or commonName MUST have been validated within the prior 398 days. -Original Message- From: dev-security-policy On Behalf Of Ben Wilson via dev-security-policy Sent: Monday, March 8, 2021 6:38 PM To: mozilla-dev-security-policy Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days All, Here is the currently proposed wording for subsection 5.1 of MRSP section 2.1: " 5.1. for server certificates issued on or after October 1, 2021, verify each dNSName or IPAddress in a SAN or commonName at an interval of 398 days or less;" Ben On Fri, Feb 26, 2021 at 9:48 AM Ryan Sleevi wrote: > > > On Thu, Feb 25, 2021 at 7:55 PM Clint Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> I think it makes sense to separate out the date for domain validation >> expiration from the issuance of server certificates with previously >> validated domain names, but agree with Ben that the timeline doesn’t >> seem to need to be prolonged. What about something like this: >> >> 1. Domain name or IP address verifications performed on or after July >> 1, >> 2021 may be reused for a maximum of 398 days. >> 2. Server certificates issued on or after September 1, 2021 must have >> completed domain name or IP address verification within the preceding >> 398 days. >> >> This effectively stretches the “cliff” out across ~6 months (now >> through the end of August), which seems reasonable. >> > > Yeah, that does sound reasonable. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
