RE: Certificate with invalid dnsName issued from Baltimore intermediate

@lists.mozilla.org] On Behalf Of Ben Wilson via dev-security-policy Sent: Thursday, August 3, 2017 7:33 AM To: Nick Lamb <tialara...@gmail.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: Certificate with invalid dnsName issued from Baltimore intermediate That would be fine. Al

RE: Certificate with invalid dnsName issued from Baltimore intermediate

sounds like OneCRL would be an appropriate remedy. Alex On Thu, Aug 3, 2017 at 10:38 AM, Ben Wilson via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: Nick and Mozilla Community, Here is the response from In

RE: Certificate with invalid dnsName issued from Baltimore intermediate

That would be fine. Also, we have given Intesa Sanpaolo a scheduled revocation date of 15 August 2017, and I'm waiting to hear back. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Nick Lamb via

RE: Certificate with invalid dnsName issued from Baltimore intermediate

No, not yet. We're currently in negotiations/discussions with them. Here is a snippet from a communication from them: Concerning the CA revocation, first of all, I want to underline that for us it would be a major issue: we don't have enough time and resources to replace all the certificates

RE: Certificates with reserved IP addresses

Gerv, Yes. We'll be revoking both of those. A date is yet to be determined. Ben Gerv wrote: TI Trust Technologies has two intermediate certificates in the CCADB - the one mentioned above: https://ccadb.my.salesforce.com/001o00cdd4t and this one, serial number 0727bfc4:

RE: Certificate with invalid dnsName issued from Baltimore intermediate

Attached is an audit from 2016. They are due for another one for 2017. -Original Message- From: Gervase Markham [mailto:g...@mozilla.org] Sent: Tuesday, August 15, 2017 6:55 AM To: Ben Wilson ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re:

RE: Certificates with reserved IP addresses

ave details about why DigiCert failed to detect these, and what steps DigiCert has in place to ensure compliance from its subordinate CAs? On Sat, Aug 12, 2017 at 10:19 PM, Ben Wilson via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozil

RE: Certificates with less than 64 bits of entropy

As previously noted on this list, there are two Siemens CAs that have issued certificates with less than 64 bits of entropy. See https://misissued.com/batch/6/ The Siemens Issuing CA Internet 2013 is subordinate to a DigiCert-owned root, and the Siemens Issuing CA Internet 2016 is signed by Quo

RE: Certificates with less than 64 bits of entropy

With regard to Siemens, given the large number of certificates and the disruption that massive revocations will have on their infrastructure, what does this community expect them to do? -Original Message- From: dev-security-policy

RE: Certificates with less than 64 bits of entropy

hey fixed whatever issue there is with their PKI infrastructure that leads to this issue? From skimming, I see this pool contains certs issued as recently as one month ago. Alex On Fri, Aug 11, 2017 at 10:26 AM, Ben Wilson via dev-security-policy <dev-security-policy@lists.mozilla.org

RE: Certificates with reserved IP addresses

Thanks. We've sent an email to the operators of the first two CAs (TI Trust Technologies and Cybertrust Japan) that they need to revoke those certificates. Thanks again, Ben -Original Message- From: dev-security-policy

RE: Certificates with reserved IP addresses

why DigiCert failed to detect these, and what steps DigiCert has in place to ensure compliance from its subordinate CAs? On Sat, Aug 12, 2017 at 10:19 PM, Ben Wilson via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wro

RE: Certificates with less than 64 bits of entropy

fix in a 24 hour period, every issuing CA should be able to muster the strength to keep the community informed of their plans and progress in however long it takes to address the issue. -- Eric On Fri, Aug 11, 2017 at 10:33 AM, Ben Wilson via dev-security-policy <dev-security-policy@lis

RE: Certificates with less than 64 bits of entropy

ith their PKI infrastructure that leads to this issue? From skimming, I see this pool contains certs issued as recently as one month ago. Alex On Fri, Aug 11, 2017 at 10:26 AM, Ben Wilson via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-poli

RE: Certificate with invalid dnsName issued from Baltimore intermediate

Dear Jonathan, Thank you for bringing this to our attention. We have contacted Intesa Sanpaolo regarding this error and have asked them to correct it as soon as possible. Sincerely yours, Ben Wilson, JD, CISA, CISSP DigiCert VP of Compliance -Original Message- From:

RE: How long to resolve unaudited unconstrained intermediates?

ow long to resolve unaudited unconstrained intermediates? Hey Ben, Take a look at the thread "Disclosing unconstrained emailProtection intermediates to CCADB" by Rob, it explains the change and has the relevant dates by which CAs must comply. Alex On Tue, Jul 11, 2017 at

RE: Certificate with invalid dnsName issued from Baltimore intermediate

Just as a follow up, these two certificates (with www.intesasanpaolovita..biz) were revoked on 19 July 2017. See http://ca.intesasanpaolo.com/portalCais0/crl/servext2.crl. -Original Message- From: dev-security-policy

RE: Certificate with invalid dnsName issued from Baltimore intermediate

Nick, We are in discussions with Intesa Sanpaolo about implementing/pursuing OneCRL or a similar approach (e.g. outright revocation of the CAs). Thanks, Ben -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

We've now uploaded the self-signed root into the CCADB as a subordinate CA to the same self-signed root, if that makes sense. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Jeremy Rowley via

RE: Certificates with invalidly long serial numbers

FWIW - In the case of Telecom Italia, they have a commercial CA product has a bug in it that occasionally causes this issue. They may need some time for the software to be fixed/replaced. -Original Message- From: dev-security-policy

RE: Hunting for intermediates that still haven't been disclosed to CCADB

Both sets had been publicly disclosed through affirmative publishing in the repositories of the respective CAs--that's probably how your crawler found them, because I don't believe they are issuing SSL/TLS certificates. I thought I had disclosed the ones chaining to the DigiCert Orion Health

RE: New undisclosed intermediates

I don't believe that disclosure of root certificates is the responsibility of a CA that has cross-certified a key. For instance, the CCADB interface talks in terms of "Intermediate CAs". Root CAs are the responsibility of browsers to upload. I don't even have access to upload a "root"

RE: New undisclosed intermediates

dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > >> On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy >> <dev-security-policy@lists.mozilla.org> wrote: >> >> I don't believe that disclosure of root certificates is the >> responsibili

RE: Old roots to new roots best practice?

Ryan, Could you please explain what you mean by saying that if you revoke a single certificate that it is akin to revoking all variations of that certificate? I don't think I agree. There are situations where the certificate is revoked for reasons (e.g. issues of certificate format/content) that

RE: CAs not compliant with CAA CP/CPS requirement

Those are typos. See section 4.2.1 of our CPS posted here: https://www.digicert.com/wp-content/uploads/2017/09/DigiCert_CPS_v412.pdf -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Samuel Pinder via

RE: Violations of Baseline Requirements 4.9.10

Hi Paul, In case you're not on the distribution for the DigiCert bug for this, here is my recent post. https://bugzilla.mozilla.org/show_bug.cgi?id=1398269#c2 Cheers, Ben -Original Message- From: dev-security-policy

RE: Violations of Baseline Requirements 4.9.10

This CA only issues client certificates: DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação Electrónica do Estado, C=PT Ben Wilson, JD, CISA, CISSP VP Compliance +1 801 701 9678 From: Paul Kehrer [mailto:paul.l.keh...@gmail.com] Sent: Tuesday, August

RE: Violations of Baseline Requirements 4.9.10

This CA is technically constrained: DN: C=CH, L=Zurich, O=ABB, CN=ABB Issuing CA 6 From: Paul Kehrer [mailto:paul.l.keh...@gmail.com] Sent: Tuesday, August 29, 2017 6:48 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Violations of Baseline Requirements 4.9.10 I've

RE: Violations of Baseline Requirements 4.9.10

Could someone re-check Multicert and SCEE? (See below.) They have indicated to us that they have now patched their OCSP responder systems. DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação Electrónica do Estado, C=PT Example cert: https://crt.sh/?id=12729446 OCSP

New Sub CAs under the DigiCert RSA and ECC Transition Roots

In the spirit of full transparency and in attempt to comply to the extent we can with Mozilla policy, on Thursday, Nov. 2, we created several sub CAs under two new "transition" roots (yet to be submitted as roots). These sub CAs haven't been uploaded yet to the CCADB because no instances of the

RE: Proposed policy change: require private pre-notification of 3rd party subCAs

n. On Tue, Oct 24, 2017 at 9:01 AM, Ben Wilson via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: I echo Doug's concerns. I can see this process as being useful/helpful where the private key is off-prem

5.3.1 Technically Constrained

Which "above paragraph" is being referenced in the following excerpt from Section 5.3.1 of the Mozilla Root Store Policy v.2.5 (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/)? "Instead of complying with the above paragraph, intermediate certificates

RE: 5.3.1 Technically Constrained

n=digicert@lists.mozilla.org] On Behalf Of Ben Wilson via dev-security-policy Sent: Monday, January 8, 2018 3:42 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: 5.3.1 Technically Constrained Which "above paragraph" is being referenced in the following excerp

RE: CCADB disclosure of id-kp-emailProtection intermediates

What about the Mozilla CA communication that said that CAs had until 15 April 2018? -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Rob Stradling via dev-security-policy Sent: Tuesday, January 16, 2018 2:29

RE: localhost.megasyncloopback.mega.nz private key in client

Norbert, I've tried to verify this with and without spaces in the msg.asc below. I get "Signature Verification Failure". Please contact me off-list to provide me clearer information related to your proof of private key possession. Thanks, Ben Wilson -Original Message- From:

RE: Misissuance and BR Audit Statements

Re-sending -Original Message- From: Ben Wilson Sent: Wednesday, August 15, 2018 8:34 AM To: 'r...@sleevi.com' ; Wayne Thayer Cc: mozilla-dev-security-policy Subject: RE: Misissuance and BR Audit Statements Thanks, Ryan and Wayne, Going forward we'll work to improve our management

RE: Misissuance and BR Audit Statements

Thanks, Ryan and Wayne, Going forward we'll work to improve our management letter disclosures to include reported mis-issuances during the audit period. Sincerely yours, Ben -Original Message- From: dev-security-policy On Behalf Of Ryan Sleevi via dev-security-policy Sent: Monday,

RE: Misissuance and BR Audit Statements

What about all of the other audit firms? From: Wayne Thayer Sent: Wednesday, August 15, 2018 1:09 PM To: Ben Wilson Cc: Ryan Sleevi ; mozilla-dev-security-policy Subject: Re: Misissuance and BR Audit Statements I went ahead and noted these DigiCert audits as a concern on the CCADB

Unrevocation of BT Class 2 CA - G2 CA Certificate

I've filed an incident report here: https://bugzilla.mozilla.org/show_bug.cgi?id=1442091 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Mis-issuance of certificate with https in CN/SAN

This mis-issuance incident was reported by Cybertrust Japan (CTJ), an intermediate CA of DigiCert. (https://bugzilla.mozilla.org/show_bug.cgi?id=1445857) Here's the incident report: 1.How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem

RE: Policy 2.6 Proposal: Audit requirements for new subCA certificates

That is a distinction without a difference. If I create a subCA, it’s because I want to put it into production soon afterwards. This proposal is going to add hours per week that DigiCert is going to have to do, on top of reporting CAs to the CCADB, and everything else that CAs have to do.

RE: Policy 2.6 Proposal: Audit requirements for new subCA certificates

If I create a new sub CA on a weekly basis, will that mean that I have to republish my CPS every week? That makes absolutely no sense. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Dimitris

RE: Mis-issuance of certificate with https in CN/SAN

Matt and Jakob, Cybertrust Japan asked me to relay the following response to the list. Jakob, thank you very much for pointing this out. We should have reported this link, https://crt.sh/?id=357203958=cablint Matt, thank you very much also for asking about our remediation actions we did and

RE: How harsh (in general) should Mozilla be towards CAs?

Jakob Bohm wrote "Each of these arguments for maximum punishment and/or maximum inconvenience for innocent bystanders is backed by a formal/legal interpretation of existing rules as making this the only possible outcome." I'd agree - heavy-handed, strict enforcement of some rules unnecessarily

RE: Incorrect OCSP status for revoked intermediates

Thanks, Corey. As I said, we'll try to get this resolved as soon as possible and file an incident report. -Original Message- From: dev-security-policy On Behalf Of Corey Bonnell via dev-security-policy Sent: Sunday, January 27, 2019 2:21 PM To:

RE: Incorrect OCSP status for revoked intermediates

I'll look into this immediate, but have you checked to see whether these certificates have OCSP AIAs in them? Or did you find these by searching our CRLs. -Original Message- From: dev-security-policy On Behalf Of Corey Bonnell via dev-security-policy Sent: Sunday, January 27, 2019 8:50

Re: Incorrect OCSP status for revoked intermediates

We believe this issue has been fixed. From: Ben Wilson Sent: Sunday, January 27, 2019 2:22:45 PM To: Corey Bonnell; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: Incorrect OCSP status for revoked intermediates Thanks, Corey. As I said, we'll try to

RE: Unretrievable CPS documents listed in CCADB

That approach could work. From: Wayne Thayer Sent: Friday, May 3, 2019 1:19 PM To: Ben Wilson Cc: Andrew Ayer ; Corey Bonnell ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Unretrievable CPS documents listed in CCADB On Fri, May 3, 2019 at 8:36 AM Ben Wilson via dev

RE: Unretrievable CPS documents listed in CCADB

I'm against having to continually update the exact URL of the CP and CPS in the CCADB. It's pretty easy to find the current CP and CPS from a legal repository. Plus, if we point to an exact one in the CCADB, it might not be the one that is applicable to a given certificate that was issued

RE: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

I thought that the EKU "id-kp-OCSPSigning" was for the OCSP responder certificate itself (not the CA that issues the OCSP responder certificate). I don't think I've encountered a problem before, but I guess it would depend on the implementation? -Original Message- From:

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

Dear Sándor, I have a couple of follow-up questions for Microsec. There were some responses during the recent public discussion in which Microsec indicated it would update its CPS(es). When do you anticipate that this will occur? Also, it is also unclear from the quoted thread below whether

Welcome Ben Wilson to Mozilla!

Thanks, Kathleen I'm really excited to begin working with all of you! Cheers and stay safe, Ben Wilson On Mon, Apr 13, 2020 at 11:07 AM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > All, > > I am pleased to announce that Ben Wilson has joined

COVID-19 Policy (especially EKU Deadline of 1-July-2020)

Dear MDSP community, As you are aware from past discussions on this list, there has been a concern about the impact of COVID-19 on CA operations. COVID-19 continues to impact certain areas of the world more severely than others. For example, there has been a recent resurgence of COVID-19 in

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

Dear Andrew, The purpose of my email was to alert the Mozilla community of a COVID-19 concern as it arose and to start/continue a dialogue on these COVID-19 matters. I was hoping to get some general feedback to help guide our COVID-19 policy. I appreciate the feedback so far. As mentioned in

Request to Include certSIGN Root CA G2 certificate

This request is for inclusion of the certSIGN Root CA G2 certificate and to turn on the Websites trust bit and for EV treatment. The request is documented in Bugzilla and in the CCADB as follows: https://bugzilla.mozilla.org/show_bug.cgi?id=1403453

Re: Mozilla's Expectations for OCSP Incident Reporting

Just an FYI - I've also started a thread on the CA/Browser Forum list to see about establishing OCSP uptime requirements in the Baseline Requirements. On Mon, May 11, 2020 at 5:45 AM Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2020-05-08 21:03, Wayne

Re: Digicert issued certificate with let's encrypts public key

Thanks, Corey. I've added this as a matter to consider in a future version of the Root Store Policy. https://github.com/mozilla/pkipolicy/issues/215 On Thu, May 21, 2020 at 7:23 PM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > While I realize the current

Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

This issue is presented for resolution in the next version of the Mozilla Root Store Policy. It is related to Issue #147 (previously posted for discussion on this list on 6-Oct-2020). Possible language is presented here:

Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

This issue #153, listed here: https://github.com/mozilla/pkipolicy/issues/153, is proposed for resolution with version 2.7.1 of the Mozilla Root Store Policy. It is related to Issue 139 (audits required even if not issuing). The first paragraph of

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

e. Also, I haven't mapped out how this might affect CAs that we sometimes add to the root store without EV enablement and with the suggestion that they apply later for it. On Sat, Oct 17, 2020 at 12:26 AM Ryan Sleevi wrote: > > > On Thu, Oct 15, 2020 at 4:36 PM Ben Wilson via dev-secur

NAVER: Public Discussion of Root Inclusion Request

Dear All, This is to announce the beginning of the public discussion phase of the Mozilla root CA inclusion process, https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 through 9). Mozilla is considering approval of NAVER Business Platform Corp.’s request to include the

MRSP Issue #139: Audits required even if not issuing

Here is the first issue for discussion here on the m.d.s.p. list relative to the next version of the Mozilla Root Store Policy (v.2.7.1). #139 - Audits are required even if no longer issuing - Clarify that audits are required until the CA

MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

#147 - Require EV audits for certificates capable of issuing EV certificates – Clarify that EV audits are required for all intermediate certificates that are technically capable of issuing EV certificates, even when not currently issuing EV

Re: Policy 2.7.1 Issues to be Considered

uld be a > useful clarification alongside issue 147, as it will better define the > parameters that determine if a given intermediate is “EV capable”. > > Thanks, > Corey > -- > *From:* dev-security-policy > on behalf of Ben Wilson via dev-secur

Re: Policy 2.7.1 Issues to be Considered

tes would become > effective, and specifically this item: > >https://github.com/mozilla/pkipolicy/issues/206 > > Doug > > -Original Message- > From: dev-security-policy > On Behalf Of Ben Wilson via dev-security-policy > Sent: Thursday, October 1, 2020 4:

Re: New Blog Post on 398-Day Certificate Lifetimes

that chain up to > built-in > > roots. > > Thanks, > > Ben > > On Mon, Jul 13, 2020 at 10:37 PM Christian Felsing via > dev-security-policy < > > dev-secur...@lists.mozilla.org> wrote: > > > > > Am 09.07.2020 um 17:46 schrieb Ben Wilson via

Re: Verifying Auditor Qualifications

In a draft template for audit attestations, provided by the ACAB'c, the template would provide a URL to the NAB's certification of the CAB with a statement that the NAB had certified the CAB to perform "certification of trust services according to 'EN ISO/IEC 17065:2012' and 'ETSI EN 319 403

Sectigo to Be Acquired by GI Partners

As announced previously by Rob Stradling, there is an agreement for private investment firm GI Partners, out of San Francisco, CA, to acquire Sectigo. Press release: https://sectigo.com/resource-library/sectigo-to-be-acquired-by-gi-partners. I am treating this as a change of legal ownership

Policy 2.7.1 Issues to be Considered

Below is a list of issues that I propose be addressed in the next version (2.7.1) of the Mozilla Root Store Policy (MRSP). There are currently 73 issues related to the MRSP listed here: https://github.com/mozilla/pkipolicy/issues. So far, I have identified 13 items to consider for this policy

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

In accordance with the CA inclusion process,[1] this is a summary of the public discussion of Microsec’s application for inclusion of the e-Szigno Root CA 2017 into the Mozilla root store, and to EV enable it and the currently-included e-Szigno Root CA 2009. The request is documented in Bugzilla

Re: Request to Include certSIGN Root CA G2 certificate

ates shall be created under, at least, dual control. > > > > I'd like to see an explanation of these non-conformities and the > > remediation from certSIGN, and confirmation from LSTI that they have been > > fixed. > > > > - Wayne > > > > [1

Re: EV-enablement Request of Identrust

Based on the record in Bugzilla Case 1551703 and the CCADB Case 417 ( https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0417) , and receiving no further comments, I have recommended approval of this request to EV-enable the Identrust Commercial Root CA 1. See

SecureTrust: Root Certificates Inclusion Request

This email announces an intent to include the following three (3) root certificates as trust anchors with the websites and email trust bits enabled, and to enable each root for EV as documented in the following Bugzilla case: https://bugzilla.mozilla.org/show_bug.cgi?id=1528369 This email

Re: EV-enablement Request of Identrust

Today is the close of the comment period for the Identrust EV enablement request. I don't believe we have received any comments, and I intend to recommend that this request be approved unless there are any reasons why the request should be denied. Thanks, Ben On Fri, Jul 10, 2020 at 4:05 PM Ben

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

All, Thank you to Ryan for identifying this problem, and to all of you who are earnestly investigating what this problem means and the impact to your CA hierarchies. Mozilla::pkix requires that an OCSP responder certificate be an end entity certificate, so we believe that Firefox and Thunderbird

New Blog Post on 398-Day Certificate Lifetimes

All, This is just to let everyone know that I posted a new Mozilla Security blog post this morning. Here is the link> https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/ As I note at the end of the blog post, we continue to seek safeguarding secure browsing

Re: New Blog Post on 398-Day Certificate Lifetimes

Thanks, Paul, for your comments and concerns regarding our reasons 2 and 3, and the costs vs. benefits of going to a 398-day certificate lifetime. We'll keep those in mind as we move forward. In response, the security of our users is the primary concern for Mozilla. So while we recognize there

Re: New Blog Post on 398-Day Certificate Lifetimes

Christian Felsing via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy: > > > https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/ > > Hi, >

Re: New Blog Post on 398-Day Certificate Lifetimes

Yes, that's right. On Fri, Jul 10, 2020 at 12:11 PM Doug Beattie wrote: > Ben, > > For the avoidance of doubt, I assume this means Sept 1, 00:00 UTC. > > > -Original Message- > From: dev-security-policy > On > Behalf Of Ben Wilson via dev-security-policy &g

Re: New Blog Post on 398-Day Certificate Lifetimes

Some people have asked whether two-year certificates existing on August 31 would remain valid. The answer is yes. Those certificates will remain valid until they expire. The change only applies to certificates issued on or after Sept. 1, 2020. ___

EV-enablement Request of Identrust

This is a request to EV-enable the IdenTrust Commercial Root CA 1, as documented here: https://bugzilla.mozilla.org/show_bug.cgi?id=1551703 * Summary of Information Gathered and Verified: https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0417 * SHA2 hash for Root

Updated Language in CA Incident Report Template

All, I have updated the wiki page containing the CA incident report template. See https://wiki.mozilla.org/CA/Responding_To_An_Incident The purpose of this update is to place more emphasis on the level of detail that CAs should provide,

Re: Request to Include certSIGN Root CA G2 certificate

ll be improved >> > -CSS-6.3.10-13–Documentation shall be improved >> > >> > I'm particularly concerned about GEN-6.5.1-04: The CA key pair used for >> > signing certificates shall be created under, at least, dual control. >> > >> > I'd like to see an e

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

Having received no further comments, I have recommended approval of this request in bug 1445364 - Ben On Tue, Jun 2, 2020 at 1:57 PM Ben Wilson wrote: > I have now reviewed Microsec's updated CPS for OV and DV. I am not going > to hold up

CA Configuration and Operation

Often CA configurations and settings are complex and can be difficult to manage. We would like to remind CA operators that they need to be familiar with the configuration and operation of all aspects of CA software and ensure that they have adequate documentation and training. For example, in

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

I have now reviewed Microsec's updated CPS for OV and DV. I am not going to hold up approval of the inclusion of this root for the following reasons, which I believe are relatively minor, but Microsec should be aware that: - section 3.1.1 of Microsec's "eIDAS conform Certificate for Website

Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

This is to announce the beginning of the public discussion phase of the Mozilla root CA inclusion process for GlobalSign. See https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 through 9). GlobalSign has four (4) new roots to include in the root store. Two roots, one RSA

Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

This is the last issue that I have marked for discussion in relation to version 2.7.1 of the Mozilla Root Store Policy . It is identified and discussed in GitHub Issue #218

Summary of Camerfirma's Compliance Issues

All, We have prepared an issues list as a summary of Camerfirma's compliance issues over the past several years. The purpose of the list is to collect and document all issues and responses in one place so that an overall picture can be seen by the community. The document is on the Mozilla wiki:

Re: FNMT: Public Discussion of Root Inclusion Request

CPS v. 1.6 document.) > > > Ben > > > > > > On Wed, Dec 2, 2020 at 7:15 AM Matthias van de Meent via > dev-security-policy wrote: > > >> > > >> On Fri, 27 Nov 2020 at 11:19, Santiago Brox via dev-security-policy < > > >> dev-secu

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

mains/customers should not be affected until then. Cheers, Ben > > Doug > > -----Original Message- > From: dev-security-policy > On Behalf Of Ben Wilson via dev-security-policy > Sent: Monday, November 30, 2020 2:27 PM > To: mozilla-dev-security-policy < > mozilla-dev

Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

The purpose of this email is to begin public discussion on a modification to subsection 5 in section 2.1 of the Mozilla Root Store Policy. Issue #206 in GitHub discusses the need to bring the reuse period for domain validation in line with the

Re: FNMT: Public Discussion of Root Inclusion Request

ribió: > > > On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy, > > > wrote: > > > > > > > > [...] > > > > > > > > *CP/CPS:* > > > > > > > > > https://www.sede.fnmt.gob.es/documents/10445900/1053

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

See my responses inline below. On Tue, Dec 1, 2020 at 1:34 PM Ryan Sleevi wrote: > > > On Tue, Dec 1, 2020 at 2:22 PM Ben Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> See responses inline below: >> >> On Tu

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

s not addressed in this update, adding clarification on > domain verification reuse for SMIME would be a good improvement on the > existing policy. > > -Original Message- > From: dev-security-policy > On Behalf Of Ben Wilson via dev-security-policy > Sent: Wednesday, December 2,

Re: FNMT: Public Discussion of Root Inclusion Request

thoroughly sometime in the following weekend, at first glance they >> > already looked much better. >> > >> > -Matthias >> > >> > [1] >> https://www.sede.fnmt.gob.es/en/normativa/declaracion-de-practicas-de-certificacion >> > On Wed, 2 D

Policy 2.7.1: MRSP Issue #207: Require audit statements to provide information about which CA Locations were audited

All, This email is part of the discussion for the next version of the Mozilla Root Store Policy (MSRP), version 2.7.1, to be published during of Q1-2021. For audit delays, we currently require that audit statements disclose the locations that were and were not audited, but that requirement has

Policy 2.7.1: MRSP Issue #211: Align OCSP requirements in Mozilla's policy with the BRs

This discussion is related to Issue #211 on GitHub . Effective September 30, 2020, as a result of the Browser Alignment Ballot , section 4.9.10 of the CA/Browser Forum’s

Policy 2.7.1: Process Overview

Re-posting this email to start it with its own subject line and to start a new thread: There have been questions about the process being followed and the comment period. Here is where it now stands. I intend to introduce the remaining discussion topics over the next three weeks. I did not

Re: NAVER: Public Discussion of Root Inclusion Request

ike all certificates with a stateOrProvinceName > > > field are misissued. The ST field should probably be the "Gyeonggi-do" > as > > > the "Seongnam-si" entered is a city. > > > > > > > > > > > > > > > > ‐‐‐

  1   2   >