Define/clarify policy for transfer of intermediate CA certificates

This issue was brought up in the thread that kicked off the 2.6 root store policy update [1]. Mozilla policy section 5.3.2 requires CAs to disclose new unconstrained intermediate CA certificates within one week of creation. Section 8 covers [in my opinion] transfers of roots but not intermediates.

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

On Wed, Apr 11, 2018 at 3:49 PM, Wayne Thayer wrote: > As an alternative to requiring newly-issued subCA Certificates to be > listed in the relevant CP/CPS prior to issuing certificates, would it be > reasonable for Mozilla to require the Certificate Policies extension in >

Re: CCADB disclosure of id-kp-emailProtection intermediates

Mozilla's April 15 deadline for disclosure of email intermediates that are not technically constrained has now passed. I have created the following bugs for the certificates listed at https://crt.sh/mozilla-disclos ures#undisclosed * Firmaprofesional:

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

se? Is it just that now all of the S/MIME certificates issued under the intermediate must also expire or be replaced so that the old intermediate (without a constraint on srvName) can be revoked? On Mon, Apr 23, 2018 at 3:42 PM, Wayne Thayer via dev-security-policy < > dev-security-po

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

On Wed, Apr 25, 2018 at 8:01 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 20/04/2018 21:59, Wayne Thayer wrote: > >> On Tue, Apr 17, 2018 at 6:10 AM, Buschart, Rufus via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >> I

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

On Wed, Mar 28, 2018 at 3:45 AM, ramirommunoz--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > On Tuesday, March 27, 2018 at 10:37:07 PM UTC+2, Wayne Thayer wrote: > > Hi Ramiro, > > > > On Fri, Mar 23, 2018 at 11:52 AM, ramirommunoz--- via > dev-security-policy < >

Re: Policy 2.6 Proposal: Permit issuance during change in ownership

On Thu, Mar 29, 2018 at 2:12 PM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Thu, Mar 29, 2018 at 4:03 PM, Wayne Thayer <wtha...@mozilla.com> wrote: > >> On Thu, Mar 29, 2018 at 8:53 AM, Ryan Sleevi <r...@sleevi.com> wrote: >> >>> >&g

Re: Audits for new subCAs

On Thu, Mar 29, 2018 at 12:55 PM, Ryan Sleevi wrote: > > I think, for new CAs, the KGC report and the stated CP/CPS, combined with > ensuring that the next audit that covers the period of time stated on the > KGC report includes that certificate, seems like a reasonable balance.

Re: Policy 2.6 Proposal: Require disclosure of S/MIME validation practices

ces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne > > Thayer via dev-security-policy > > Sent: Monday, March 26, 2018 2:50 PM > > To: mozilla-dev-security-policy > <mozilla-dev-security-pol...@lists.mozilla.org> > > Subject: Policy 2.6 Proposal: Require

Re: Audits for new subCAs

Tim, On Fri, Mar 30, 2018 at 7:00 AM, crawfordtimj--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, March 29, 2018 at 2:56:17 PM UTC-5, Ryan Sleevi wrote: > > On Thu, Mar 29, 2018 at 2:46 PM, Wayne Thayer via dev-security-policy < >

Re: Policy 2.6 Proposal: Require audits back to first issuance

On Thu, Mar 29, 2018 at 8:57 AM, Ryan Sleevi wrote: > > I'm not fully sure I understand the proposal here. > > I would think that, for all roots created since 2012, the expectation > is that there is an unbroken series of audits, going from a Point in Time > audit (of the

Re: Policy 2.6 Proposal: Permit issuance during change in ownership

On Thu, Mar 29, 2018 at 8:53 AM, Ryan Sleevi <r...@sleevi.com> wrote: > > On Mon, Mar 26, 2018 at 3:46 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> When the Francisco Partners acquisition of Comodo was annou

Re: Audits for new subCAs

at 6:18 PM, Peter Bowen <pzbo...@gmail.com> wrote: > On Fri, Mar 23, 2018 at 11:34 AM, Wayne Thayer via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > Recently I've received a few questions about audit requirements for > > subordinate CAs

Policy 2.6 Proposal: Require disclosure of S/MIME validation practices

Mozilla policy section 2.2(2) requires validation of email addresses for S/MIME certificates, but doesn't require disclosure of these practices as it does for TLS certificates. I propose adding the following language from 2.2 (3) (TLS) to 2.2(2) (S/MIME): The CA's CP/CPS must clearly specify the

Policy 2.6 Proposal: Require audits back to first issuance

Mozilla began requiring BR audits for roots in our program in 2013 [1], but we have a vague policy statement in section 3.1 regarding audit requirements prior to inclusion: Before being included and periodically thereafter, CAs MUST obtain certain > audits… > BR section 8.1 contains the

Fwd: FW: Complying with Mozilla policy on email validation

I'm forwarding this for Tim because the list rejected it as SPAM. *From:* Tim Hollebeek *Sent:* Monday, April 2, 2018 2:22 PM *To:* 'mozilla-dev-security-policy' *Subject:* Complying with Mozilla policy on email validation Mozilla policy

Re: Audits for new subCAs

On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > While Entrust happens to do this, as a relying party, I dislike frequent > updates to CP/CPS documents just for such formal changes. > > This creates a huge loophole. The CP/CPS

Re: Policy 2.6 Proposal: Require audits back to first issuance

i wrote: > > On Mon, Mar 26, 2018 at 3:06 PM, Wayne Thayer via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > Mozilla began requiring BR audits for roots in our program in 2013 > [1], but > > > we have a vague policy s

Re: FW: Complying with Mozilla policy on email validation

On Tue, Apr 3, 2018 at 11:42 AM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, Apr 3, 2018 at 12:19 PM, Ryan Hurst via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > > > For example, if we consider a CA

Re: FW: Complying with Mozilla policy on email validation

On Tue, Apr 3, 2018 at 10:19 AM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Reading this thread and thinking the current text, based on the > interpretation discussed, does not accommodate a few cases that I think are > useful. > > For example, if we

Re: Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

There has been a lot of confusion about the transition to the new standards, and I believe that this change makes it clearer that Mozilla no longer accepts audits based on the older ETSI standards. On Tue, Mar 27, 2018 at 4:28 AM, Julian Inza via dev-security-policy <

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

Hi Ramiro, On Fri, Mar 23, 2018 at 11:52 AM, ramirommunoz--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan > > Thanks again for your remarks. > In the end I am going to learn something of PKI :-). > Surely I do not get a full understanding of you solution, but

Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

Mozilla policy section 3.1.2.2 states: ETSI TS 102 042 and TS 101 456 audits are only acceptable for audit periods > ending in July 2017 or earlier. > Now that we are past this deadline, I propose that we remove all references to ETSI TS 102 042 and 101 456 from the policy. This is:

Policy 2.6 Proposal: Permit issuance during change in ownership

When the Francisco Partners acquisition of Comodo was announced, it was pointed out [1] that a strict reading of the current policy section 8.1 would have forced Comodo to stop issuing certificates for some period of time: If the receiving or acquiring company is new to the Mozilla root program,

Re: AC Camerfirma misissued certificates automated analysis results

Thank you for sharing this information. On Mon, Mar 26, 2018 at 9:24 AM, juanangel.martingomez--- via dev-security-policy wrote: > > > We've done an automated analysis on 2018-03-13 of TSL/SSL certificates > that have been issued by our CAs: > - Camerfirma

Re: Policy 2.6 Proposal: Updated criteria for including new CAs based on recent discussion

On Tue, Mar 20, 2018 at 8:22 AM, Ryan Sleevi wrote: > > So, one aspect of this is the recently discussed risk - that is, a CA that > provides value for only 10 users presents a substantial amount of risk to > all Mozilla users, for both compromise and non-compliance. This is, >

Re: Policy 2.6 Proposal: Move Compliance Date into policy

On Tue, Mar 20, 2018 at 8:19 AM, Ryan Sleevi wrote: > > Looking through [1], it seems like the Compliance Date has only differed > from the Publication Date once (with 2.0). > It's not clear to me that the 2.5 failure to adoption was related to > ambiguity around compliance

Re: TURKTRUST Non-compliance

On Tue, Mar 20, 2018 at 12:56 PM, Eric Mill via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I think it's not going to be productive to spend a lot of time on the list > debating whether or not a CA can opt out of full BR compliance by simply > saying "we're winding

Re: DigiCert .onion certificates without Tor Service Descriptor Hash extension

Jeremy filed the following incident report at https://bugzilla.mozilla.org/show_bug.cgi?id=1447192 : 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug),

Policy 2.6 Proposal: Update domain validation requirements

Section 2.2(3) defines very specific requirements for use of the BR 3.2.2.4 domain validation methods. Now that 3.2.2.4.11 (“any other method”) has been removed from the BRs and ballot 218 [1] has passed, the Mozilla policy is out-of-date. I propose the following changes: * Remove the reference

Policy 2.6 Proposal: Updated criteria for including new CAs based on recent discussion

A few months ago, we discussed our root inclusion criteria [1], and came to a conclusion that I summarized and proposed in policy as follows: I would like to thank everyone for your constructive input on this topic. > At the outset I stated a desire to ‘establish some objective criteria that >

Policy 2.6 Proposal: Remove temporary exception for unconstrained email subordinates

This new version of the policy won’t be completed until after 15-April, which is the revised deadline for disclosure and auditing of unconstrained email subordinates. I propose removal of the following exception from section 5.3.1: Instead of complying with the above paragraph, intermediate

Policy 2.6 Proposal: Move Compliance Date into policy

Historically, the effective dates of new versions of the policy have been maintained separately from the policy itself [1]. In our November Communication, we learned that many CAs weren’t in compliance with policy version 2.5 despite it having been in effect since June [2]. This proposal is simply

Re: Root Store Policy 2.6

There are 17 proposed changes in total for version 2.6 of the policy, and I'm about to kick off discussions on the first batch. I expect some of these to be straightforward while others will hopefully generate good dialogues. As always, everyone's constructive input is appreciated. Thanks, Wayne

TURKTRUST Non-compliance

TURKTRUST has the "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5" root included in the Mozilla program with the 'websites' trust bit enabled (not EV). Crt.sh identifies one unexpired and unrevoked subordinate CA [1], and 13 unexpired end-entity certificates signed by this root [2]. The

Re: Policy 2.6 Proposal: Move Compliance Date into policy

On Tue, Mar 20, 2018 at 2:46 PM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Tue, Mar 20, 2018 at 4:15 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Tue, Mar 20, 2018 at 8:19 AM, Ryan Sleevi <r...@sle

Re: TURKTRUST Non-compliance

Given that TURKTRUST has stated that the "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5" root is no longer being audited or complying with new policies, I believe there is consensus that it should be removed from the Mozilla root store. Kathleen will file a bug for that action. Ryan

Audits for new subCAs

Recently I've received a few questions about audit requirements for subordinate CAs newly issued from roots in our program. Mozilla policy section 5.3.2 requires these to be disclosed "within a week of certificate creation, and before any such subCA is allowed to issue certificates.", but says

Re: Policy 2.6 Proposal: Remove temporary exception for unconstrained email subordinates

Hearing no objections, I've added this change to the 2.6 branch: https://github.com/mozilla/pkipolicy/commit/5490d165f0d9b55cb75e5851303a21f9a250e199 ​ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Policy 2.6 Proposal: Updated criteria for including new CAs based on recent discussion

le change. > > On Tue, Mar 20, 2018 at 2:45 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Tue, Mar 20, 2018 at 8:22 AM, Ryan Sleevi <r...@sleevi.com> wrote: >> >> > >> > So, one aspect of this is th

Re: Audits for new subCAs

Apologies. By choosing to use the term TSP when referring to an organization operating a PKI, I thought I had made my meaning clear. I now realize I inferred "certificate" when I used the term "subordinate CA". I meant "subordinate CA certificate" in all cases where I wrote "subordinate CA" or

Re: Policy 2.6 Proposal: Update domain validation requirements

I've drafted these changes: https://github.com/mozilla/pkipolicy/commit/e5269ff0d6ced93a6c6af65947712b8e4b2e18b8 On Tue, Mar 20, 2018 at 9:57 AM, Tim Hollebeek wrote: > > > * Add a new bullet on IP Address validation that forbids the use of BR > > 3.2.2.5(4) (“any

Re: Policy 2.6 Proposal: Move Compliance Date into policy

On Wed, Mar 21, 2018 at 2:43 AM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Tue, Mar 20, 2018 at 8:27 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: >> >> >> > I am specifically thinking of CP/CPS updat

Re: Policy 2.6 Proposal: Update domain validation requirements

Tim, On Tue, Mar 20, 2018 at 9:57 AM, Tim Hollebeek wrote: > > > * Add a new bullet on IP Address validation that forbids the use of BR > > 3.2.2.5(4) (“any other method”) and requires disclosure of IP Address > > validation processes in the CA’s CP/CPS. > > This is

Re: TURKTRUST Non-compliance

Jakob, On Mon, Mar 19, 2018 at 9:48 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/03/2018 01:23, Wayne Thayer wrote: > > Note, that if it is reasonably certain/validated that the only activity > is maintaining CRLs/OCSP for the remaining unexpired

Re: Logius PKIoverheid response to Action #2 in the January 2018 CA Communication

Thank you for the response Jochem. I am glad to hear that Logius has evaluated the risk and, given the passage of ballot 218, is moving to other methods of domain validation. - Wayne On Fri, Mar 16, 2018 at 5:55 AM, Berge, J. van den (Jochem) - Logius via dev-security-policy

Re: Policy 2.6 Proposal: Move Compliance Date into policy

ity-policy@lists.mozilla.org> wrote: > On 21/03/2018 10:43, Ryan Sleevi wrote: > >> On Tue, Mar 20, 2018 at 8:27 PM, Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> >>> I think it's reasonable - especial

Re: Allowing WebExtensions to Override Certificate Trust Decisions

Thanks everyone for your input on this topic. The consensus seems to be that allowing WebExtensions to muck with certificate validation decisions is a bad idea. The bug [1] has been updated with that sentiment and a link to this discussion. - Wayne [1]

Re: Mozilla’s Plan for Symantec Roots

Update: Mozilla is moving forward with our implementation of the consensus plan for Symantec roots [1]. With the exception of whitelisted subordinate CAs using the keys listed on the wiki [2], Symantec certificates are now blocked by default on Nightly builds of Firefox. The preference

Re: Mozilla’s Plan for Symantec Roots

On Fri, Mar 2, 2018 at 11:58 AM, Doug Beattie wrote: > Hi Wayne, > > Is the Firefox 60 update in May the same as the combination of the April > and October Chrome updates, in that all Symantec certificates will be > untrusted on this date (5 months before Chrome)? >

AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

This request is for inclusion of the Camerfirma CHAMBERS OF COMMERCE ROOT - 2016 (CCR2016) and GLOBAL CHAMBERSIGN ROOT - 2016 (GCSR2016) as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=986854 * BR Self Assessment is here:

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

On Fri, Mar 2, 2018 at 3:47 PM, David E. Ross via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 3/2/2018 2:05 PM, Wayne Thayer wrote [in part]: > > [snipped] > > NOTE: The fact that I have snipped some of the items under "==Bad==" > does not mean I consider them

Re: potential audit delay due to issue with CPA Canada

If you have the letters from your auditor, you can upload them as an attachment to a Bugzilla bug, then submit the links in your CCADB audit case. It's preferable to be able to verify the audit letters via the seal on the WebTrust site, but Mozilla doesn't require it - we can contact the auditor

Re: Code signing and malware

The article also claims that bad actors are selling EV SSL certificates that they obtain for real companies without their knowledge: "to guarantee the issuance and lifespan of the products, all certificates are registered using the information of real corporations. With a high degree of

Re: Need remove OISTE WISeKey Global Root GA CA?

The test site for the root referenced in bug 1172819 is working fine in Firefox: https://gbvalidssl.hightrusted.com/ I am not able to locate any gov.sc websites properly configured for HTTPS to test. - Wayne On Sat, Feb 24, 2018 at 3:45 AM, westmail24--- via dev-security-policy <

Re: Allowing WebExtensions to Override Certificate Trust Decisions

On Tue, Feb 27, 2018 at 3:40 PM, Peter Saint-Andre via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2/27/18 3:26 PM, Hanno Böck via dev-security-policy wrote: > > Hi, > > > > On Tue, 27 Feb 2018 09:20:33 -0700 > > Wayne Thayer via dev-

Re: TunRootCA2 root inclusion request

On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg <jonat...@titanous.com> wrote: > > > On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > >> On Feb 27, 2018, at 16:17,

Re: Japan GPKI Root Renewal Request

On Wed, Feb 28, 2018 at 9:13 AM, Eric Mill via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wed, Feb 28, 2018 at 12:58 AM, apca2.2013--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > "I would like to again point out that simply waiting

Re: Japan GPKI Root Renewal Request

To conclude this discussion, Mozilla is denying the Japanese Government ApplicationCA2 Root inclusion request. I'd like to thank everyone for your constructive input into the discussion, and I'd like to thank the Japanese Government representatives for their patience and work to address issues as

Re: Policy 2.6 Proposal: Require CAs to support problem reports via email

On Fri, Apr 20, 2018 at 12:33 PM, Wayne Thayer wrote: > At this point we have a few choices: > > 1. Do nothing about requiring email as a problem reporting mechanism. > Instead, take on the related issues of disclosure of the reporting > mechanism and receipt confirmation in

Re: Unrevoked/unexpired certificate with Debian Weak Key

I searched through the list of certificates that Rob provided and didn't find any new issues (no valid certificates and none that had been issues since Jan 1, 2017 and not previously disclosed. I've requested an incident report from QuoVadis for the one new certificate that Hanno identified via

GlobalSign Root CA - R6 Inclusion Request

This request is for inclusion of the GlobalSign Root CA - R6 as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1390803 This is an RSA-4096 / SHA-384 root that GlobalSign states “…will replace older, expiring roots that have smaller key sizes in the future.” * BR

Re: Google Trust Services Root Inclusion Request

A few additional points: First off, thank you Rob and James for calling out unacceptable list behavior. Personal attacks will not be tolerated from anyone on this list. On Thu, Sep 27, 2018 at 10:26 AM Ryan Sleevi wrote: > > On Thu, Sep 27, 2018 at 11:17 AM Jeremy Rowley > wrote: > >> Oh – I

Re: Visa Issues

On Sun, Sep 23, 2018 at 1:15 PM Ryan Sleevi wrote: > > > On Thu, Sep 13, 2018 at 3:26 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Visa recently delivered new qualified audit reports for their eCommerce >> Root that i

Re: 46 Certificates issued with BR violations (KIR)

Thank you for the incident report. I have posted it to the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1495497 On Mon, Oct 8, 2018 at 8:25 AM piotr.grabowski--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Here's the incident report: > > 1.How your CA first

Re: Incorrect qcStatements encoding at a number of Qualified Web Authentication Certificates (QWACs)

Thank you for this report Fotis. On Thu, Oct 11, 2018 at 6:13 AM Fotis Loukos via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Summary > --- > > A number of Qualified Web Authentication Certificates have been issued > with incorrect qcStatements encoding. A small

Re: Violation report - Comodo CA certificates revocation delays

I just poked Comodo in the bug - https://bugzilla.mozilla.org/show_bug.cgi?id=1492006 CT Logs are designed such that certificates cannot be removed from them. The evidence will not disappear once the certificates expire. On Wed, Oct 10, 2018 at 5:26 PM please please wrote: > Any update behind

Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3

This request is for inclusion of these four emSign roots operated by eMudhra in bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1442337 * BR Self Assessment is here: https://bug1442337.bmoattachments.org/attachment.cgi?id=8955225 * Summary of Information Gathered and Verified:

Re: Certum CA - Unallowed key usage for EC public key (Key Encipherment)

Wojciech, Thank you for the incident report. I believe it does a good job of explaining how you will prevent this specific problem from happening again, but it does not address the broader problem of misissuance and Certum's failure to detect it. How can the Mozilla community be assured that

Re: Incorrect qcStatements encoding at a number of Qualified Web Authentication Certificates (QWACs)

t; On Fri, Oct 12, 2018 at 2:32 AM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Thank you for this report Fotis. >> >> On Thu, Oct 11, 2018 at 6:13 AM Fotis Loukos via dev-security-policy < >> dev-security-

Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3

?id=8955223 - Wayne On Thu, Oct 11, 2018 at 2:07 PM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, 11 Oct 2018 13:06:46 -0700 > Wayne Thayer via dev-security-policy > wrote: > > > This request is for inclusion of these fo

Re: Misissuance and BR Audit Statements

e result of obtaining a qualified report. >> >> [A] https://bugzilla.mozilla.org/show_bug.cgi?id=1482930 >> [B] https://bug1482930.bmoattachments.org/attachment.cgi?id=8999669 >> [C] https://crt.sh/?id=23432431 >> [D] https://crt.sh/?id=351449246 >> [E] https://bugzilla.m

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

Having given this some more thought, I suggest the following changes: * Forbid "no stipulation" altogether. While there are a few sections where it would be convenient to use "No stipulation" (e.g. 4.2.3 Time to Process Certificate Applications), I don't see a requirement for more descriptive

Re: Identrust Commercial Root CA 1 EV Request

I've filed a bug to track this misissuance and subsequent failure to report: https://bugzilla.mozilla.org/show_bug.cgi?id=1500593 On Fri, Oct 19, 2018 at 6:22 AM identrust--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, October 17, 2018 at 9:08:41 PM

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

2018 to comply with > > new BRs, and again in May 2019 due to annual review, they need not comply > > until May 2019. > > > > > > > >> -Original Message- > > >> From: dev-security-policy > > >> On Behalf Of Wayne

Re: Certigna Root Renewal Request

I believe that the discussion over Certigna's reported CAA misissuance [1][2] has reached an end, even though some questions remain unanswered. If anyone has additional comments or concerns about this inclusion request, please respond by Friday 26-October. This request [3] has been in discussion

Re: Certigna Root Renewal Request

On Tue, Oct 23, 2018 at 1:46 PM David E. Ross via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 10/23/2018 11:45 AM, Wayne Thayer wrote: > > I believe that the discussion over Certigna's reported CAA misissuance > > [1][2] has reached an end, even though some questions

Re: Certigna Root Renewal Request

On Wed, Oct 24, 2018 at 3:02 PM David E. Ross via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 10/24/2018 1:07 PM, Wayne Thayer wrote: > > On Tue, Oct 23, 2018 at 1:46 PM David E. Ross via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >>

Re: AC Camerfirma's CP & CPS disclosure

.com or through the website > http://webcrm.camerfirma.com/incidencias/incidencias.php > > > -Mensaje original- > De: dev-security-policy > [mailto:dev-security-policy-boun...@lists.mozilla.org] En nombre de Wayne > Thayer via dev-security-policy > Enviado el: jueves, 27 de septiem

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

On Thu, Oct 25, 2018 at 11:17 AM Joanna Fox via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Questions about blank sections, thinking of a potential future > requirement. Sections such as 1.INTRODUCTION would remain blank as they are > more titles than components,

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

On Thu, Oct 25, 2018 at 10:11 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 26/10/2018 01:13, Ryan Sleevi wrote: > > On Thu, Oct 25, 2018 at 5:47 PM Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> On

Re: Identrust Commercial Root CA 1 EV Request

I am recommending denial of this request. It was not uncommon for CAs to treat the .int TLD as an Internal Name, so I'm not going to argue this point and claim that these certificates were misissued because 'identrust.int' and 'identrus.int' were not registered domain names. Under the assumption

Re: Questions regarding the qualifications and competency of TUVIT

I am particularly disturbed by three points made by TUVIT during this discussion: 1. A malformed qcStatement extension is a minor non-conformity because there is no known security risk - This argument is incredibly dangerous and harmful. It implies that all sorts of well-defined requirements can

Re: Certigna Root Renewal Request

Having received no further comments, I am recommending approval of Certigna's inclusion request. I would first like to thank Certigna for their patience as this request spent a long time waiting on Mozilla. The disregard for CAB Forum requirements shown by Certigna's CAA exception process is a

Re: Questions regarding the qualifications and competency of TUVIT

In addition, I take exception to the statement that open criticism is a bad approach and the implication that private discussions are the best way to make improvements. This is clearly not Mozilla's philosophy. I do believe that we all need to be careful to follow Mozilla forum etiquette [1] and

CA Communication: Underscores in dNSNames

As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1] creating a sunset period for TLS certificates containing an underscore ("_") character in the SAN. This practice was widespread until a year ago when it was pointed out that underscore characters are not permitted in dNSName

Re: CA Communication: Underscores in dNSNames

uirement. - Man Ho > > On 11/13/2018 7:18 AM, Wayne Thayer via dev-security-policy wrote: > > As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1] > > creating a sunset period for TLS certificates containing an underscore > > ("_") character in

Re: EV Policy OIDs (was Re: Identrust Commercial Root CA 1 EV Request)

; > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1486838 > > On Thu, Sep 20, 2018 at 1:49 AM Nick Lamb via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Tue, 18 Sep 2018 17:53:34 -0700 >> Wayne Thayer via dev-security-policy &g

New Auditor Compliance Dashboard + Bugzilla Change

The recent auditor discussions on this list have highlighted the fact that we haven't done a good job of tracking auditor concerns. Easily searchable records of past CA issues in Bugzilla help us to identify patterns of CA behavior, and we should have the same for auditors. with that in mind, I

Re: CA Communication: Underscores in dNSNames

I agree with Tim on the interpretation and can confirm that my intent was as Tim described. Perhaps the confusion is over the purpose of the <30 day exception. It wasn't to exempt legacy certificates near the end of their lifetime from being revoked. It was to allow subscribers to begin using

Re: Questions regarding the qualifications and competency of TUVIT

It should come as no big surprise that I have documented this issue as our first auditor compliance bug[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1507376 I only included a brief summary of this discussion (and a link to it). Others are welcome to comment if you feel that I have omitted

Re: Identrust Commercial Root CA 1 EV Request

It might be helpful for me to provide a better explanation of the thinking that went into my recommendation: The timeline of the Internal Name incident is as follows: * Identrust appears to have stopped issuing certificates containing .INT names prior to the BR deadline. * They then failed to

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

I'm not convinced there is an answer here. It seems that most would agree with the premise that we should consider the circumstances and context for an issue and make a balanced assessment. That leaves the matter of what this means in practice up for debate. Often, it appears to be a debate

Re: CA Communication: Underscores in dNSNames

y requiring them to replace their certificates while still allowing some time to transition away from them via 30-day duration certificates, the hope is that we will avoid the urgent calls for exceptions we've seen with past sunset periods. Thanks, > > Vincent > > On Mon, Nov 12, 2018 a

Re: Identrust Commercial Root CA 1 EV Request

Since there haven't been any further comments regarding my recommendation to deny this request, I would like to ask for feedback on next steps that Identrust can take in the event of a denial. I believe that Identrust would still like to pursue EV recognition in Firefox, but I think it's unlikely

Re: CA Communication: Underscores in dNSNames

of the relevant compliance dates in the email are correct, so I'm not planning to resend the CA communication. - Wayne On 11/13/2018 7:18 AM, Wayne Thayer via dev-security-policy wrote: >> > As you may be aware, the CA/Browser Forum recently passed ballot SC12 >> [1] >> >

Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)

On Thu, Oct 4, 2018 at 9:48 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I seem to recall that the bad practice was explicitly called out in > their (old) CP/CPS, which was applicable at the time. Thus any similar > misunderstanding should be

Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)

On Wed, Oct 3, 2018 at 7:27 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wed, Oct 03, 2018 at 09:31:08AM -0700, Wayne Thayer wrote: > > On Mon, Oct 1, 2018 at 4:49 AM Matt Palmer via dev-security-policy < > > dev-security-policy@lists.mozilla.org>

Re: DoS attack without consequences to Firmaprofesional

Thank you for reporting this incident Chema. No further actions are required by Mozilla, but this information may be useful to others in our community. - Wayne On Wed, Oct 3, 2018 at 7:57 AM Chema Lopez via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Good afternoon, >

Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)

Hi Matt, I appreciate your interest in getting to the root causes of this issue, and the polite and professional manner in which you are asking questions. However, I am concerned that this line of questioning seem to have reached the limits of Certigna's analysis capabilities, and is thus

<    1   2   3   4   5   6   7   >