RE: GoDaddy Misissuance Action Items

> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+wthayer=godaddy@lists.mozilla.org] On Behalf Of Gervase > Markham via dev-security-policy > Here is our proposed remediation plan for GoDaddy. > > 1) As with all CAs, update all their domain

Re: Swiss Government root inclusion request

On Thursday, November 23, 2017 at 4:03:27 AM UTC-7, michael.vonn...@bit.admin.ch wrote: > Hi Matt > > Thank you for your statement. > > Let me try to clarify: > > In 3.2.2.4 we specify the Authorization by Domain Name Registrant as follows: > > 3.2.2.4 Authorization by Domain Name Registrant

Re: Anomalous Certificate Issuances based on historic CAA records

What problem(s) are you trying to solve? - Subscribers already (or soon will) have CT logs and monitors available to detect mis-issued certs. They don't need CAA Transparency. - This thread started as a discussion over possible mis-issuance that was determined to be false positives. As has been

Re: CA generated keys

On Mon, Dec 11, 2017 at 9:43 AM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I don't know but it's worth talking about. I think the discussion should > be > "when should this be allowed, and how can it be done securely?" > > The outcome to be avoided

Re: On the value of EV

Thank you Ryan for raising this question, and to everyone who has been contributing in a constructive manner to the discussion. A number of excellent points have been raised on the effectiveness of EV in general and on the practicality of solving the problems that exist with EV. While we have

Re: ComSign Root Renewal Request

On Sun, Dec 10, 2017 at 9:15 AM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Thank you for your notes, > Here are the answers to your points. > > all the "bad" points about the CPS were addressed: > Both CPS's are now changed to ver 4.1 > Looks good, thank

Re: CA generated keys

On Tue, Dec 12, 2017 at 7:45 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 12/12/2017 19:39, Wayne Thayer wrote: > >> The outcome to be avoided is a CA that holds in escrow thousands of >> private keys used for TLS. I don’t think that a policy

Re: OCSP Responder monitoring (was Re: Violations of Baseline Requirements 4.9.10)

Thanks Rob! I went through the list and filed a bug for each CA if there wasn't one already open (with one exception that I'm still researching). All open OCSP issues are included in the list at https://wiki.mozilla.org/CA/Incident_Dashboard Wayne On Mon, Dec 11, 2017 at 10:49 PM, Rob Stradling

Re: Acquisition policy (was: Francisco Partners acquires Comodo certificate authority business)

On Thu, Nov 9, 2017 at 1:25 PM, Peter Kurrasch via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > There's always a risk that a CA owner will create a security nightmare > when we aren't looking, probationary period or not. In theory regular > audits help to prevent it, but

Re: ComSign Root Renewal Request

> We can restart the discussion and please review their updated documents and > comment in this discussion if you have further questions or concerns about > this request. > After reviewing Comsign's updated CPS and related documents, I have the following comments: == Good == - CPS follows RFC

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

On Fri, Dec 8, 2017 at 3:55 PM, Hanno Böck via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > So I wonder: If a CA signs an intermediate - are they responsible > making sure that reports brought to the subca are properly handled? > > The root CA is ultimately responsible

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

On Sat, Dec 9, 2017 at 7:50 AM, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Sat, 9 Dec 2017 09:51:59 +0100 > Hanno Böck via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > > On Fri, 8 Dec 2017 16:43

Re: Swiss Government root inclusion request

I've placed this discussion on hold pending: 1. Updated audit statement specifying the audit period. 2. Updated CP/CPS including CAA information, BR compliance statement, and clearer specification of the domain validation procedures that are in use. Wayne >On Tuesday, November 28, 2017 at

Re: ComSign Root Renewal Request

gt; > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of > > Wayne Thayer via dev-security-policy > > Sent: Tuesday, December 5, 2017 1:44 PM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: ComSign Root Renewal Request

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On Fri, May 4, 2018 at 1:25 PM Carl Mehner via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hey Doug, > > On Friday, May 4, 2018 at 3:00:03 PM UTC-5, Doug Beattie wrote: > > Hey Wayne, > > > > This should be a really easy thing, but it's not. > > > > First comments on

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

The optimist in me thinks we might be getting close to resolving this issue (the last one remaining for the 2.6 policy update). Here is another proposal that attempts to account for most of the input we've received: Add the following to section 5.2 (Forbidden and Required Practices): CAs MUST

Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On Mon, May 14, 2018 at 11:29 AM Bruce via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote: > > I think we have settled on the following resolution to this issue: > > > > Add the following to section 5.2

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, > Dean??? > - We can’t permit user generated passwords (at least that is Tim's > proposal, Wayne may not

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

Doug, On Mon, May 7, 2018 at 11:24 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > -Original Message- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Ryan > >

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

On Fri, Apr 27, 2018 at 6:40 AM, Enrico Entschew via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I suggest to make the requirement „* The PKCS#12 file must have a > sufficiently secure password, and the password must be transferred via a > separate channel than the

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

On Thu, Apr 26, 2018 at 6:59 AM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, April 26, 2018 at 11:45:15 AM UTC, Tim Hollebeek wrote: > > > > which is why in the near future we can hopefully use RDAP over TLS > > > > (RFC > > > > 7481) instead

Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

I think we have settled on the following resolution to this issue: Add the following to section 5.2 (Forbidden and Required Practices): CAs MUST NOT generate the key pairs for end-entity certificates that have > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or >

Policy 2.6 Proposal: Update Minimum Audit Versions

After consulting with representatives from WebTrust and ETSI, I propose that we update the minimum required versions of audit criteria in section 3.1.1 as follows: - WebTrust "Principles and Criteria for Certification Authorities - Extended Validation SSL" from 1.4.5 to 1.6.0 or later - “Trust

Re: question about DNS CAA and S/MIME certificates

I created a new issue suggesting that we add this requirement to Mozilla policy: https://github.com/mozilla/pkipolicy/issues/135 On Wed, May 9, 2018 at 4:59 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wed, May 9, 2018 at 11:47 AM, Adrian R. via

Re: Root Store Policy 2.6

We're concluding discussions on all of the issues identified for version 2.6 of the policy [1]. You can find a complete set of changes here: https://github.com/mozilla/pkipolicy/compare/master...2.6 Two of the changes [2][3] require CAs to update their CP/CPS. For many CAs the current practice

Re: Policy 2.6 Proposal: Update Minimum Audit Versions

31941101v010202p.pdf > > > > ETSI EN 319 411-2 <3194112> V2.2.2 adopted on April 23, 2018 > > http://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.02.02_60 > > /en_31941102v020202p.pdf > > > > Peter > > > > -Original Message- > > From: dev

Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

Doug, On Thu, May 10, 2018 at 10:57 AM Doug Beattie wrote: > Hi Wayne, > > > > I’m OK with this as long as this permits the password (fully or partially > generated by the CA) and PKCS#12 file to be picked up by a user over HTTPS > (a single channel). > > > This

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On Tue, May 15, 2018 at 7:51 AM Doug Beattie wrote: > Wayne, > > > > This going to require 19 randomly generated Base64 characters and that > does not include removing common confused characters which will drive up > the length a bit more, but if this is what the

Re: question about DNS CAA and S/MIME certificates

I don't see how this debate is leading us to a solution. Can we just acknowledge that, prior to this discussion, the implications of CAA for the issuance of email certificates was not well understood by CAs or domain name registrants? I share the desire to have a system that fails closed in the

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

Wayne [1] https://en.wikipedia.org/wiki/Security_theater On Tue, May 15, 2018 at 10:23 AM Dimitris Zacharopoulos <ji...@it.auth.gr> wrote: > > > On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote: > > Did you consider any changes based on Jakob’s comments? If t

InfoCert Acquisition of Camerfirma

On Thursday, a representative of AC Camerfirma sent an email informing Mozilla that InfoCert [1] has taken control of Camerfirma. News of the deal was first published on May 4th. [2] Section 8.1 of our policy applies here (quoting version 2.6 draft): If the receiving or acquiring company is new

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

On Tue, May 22, 2018 at 12:11 PM Ryan Sleevi wrote: > Overall, I think this would be good to proceed, but there's certain > discrepancies called out under Questions that I think should be resolved > before doing so. I would suggest contacting WISeKey for follow-up on these, >

Re: Root Store Policy 2.6

I have incorporated the final changes from our policy discussions, as well as some corrections and clarifications that Kathleen and I found during our review, into the latest draft of the policy: https://github.com/mozilla/pkipolicy/compare/master...2.6 I would encourage everyone to review the

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

Reminder: there is one week left in the discussion period for this inclusion request. On Tue, May 1, 2018 at 12:02 PM Wayne Thayer wrote: > This request is for inclusion of the OISTE WISeKey Global Root GC CA as > documented in the following bug: >

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On Tue, May 15, 2018 at 9:17 PM Tim Hollebeek wrote: > My only objection is that this will cause key generation to shift to > partners and > affiliates, who will almost certainly do an even worse job. > > > This is already a Mozilla requirement [1] - we're just moving

Chunghwa Telecom eCA Root Inclusion Request

This request is for inclusion of the Chunghwa Telecom eCA as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1341604 * BR Self Assessment is here: https://bugzilla.mozilla.org/attachment.cgi?id=8963172 * Summary of Information Gathered and Verified:

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On Fri, Jun 8, 2018 at 2:32 PM Buschart, Rufus wrote: > Did we somehow came to a conclusion / agreed wording here? I'm not sure if > I missed something, but the last email I've received in regards to this > issue is from mid of May and the last change in >

Re: Disallowed company name

On Thu, May 31, 2018 at 8:39 PM James Burton via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > This is wrong and should be changed to allow all types of legally > incorporated company names to get certificates. I understand this > doesn't fit any of the standard company

Re: Namecheap refused to revoke certificate despite domain owner changed

On Fri, Jun 1, 2018 at 5:06 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Please contact the CA again, and inform them that BR 4.9.1.1 #6 requires > the CA (not some reseller) to revoke the certificate within 24 hours if: > > The CA is made aware of

Fwd: Invalid Country Code Issuance

Forwarding this for Brenda because the list's SPAM filter is preventing her from posting it: *From:* Brenda Bernal *Date:* June 1, 2018 at 1:33:46 PM PDT *To:* *Subject:* *Invalid Country Code Issuance* Digicert has posted a bug (below) on our invalid country code issuance. Wayne requested us

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

On Mon, Jun 25, 2018 at 2:45 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, Jun 25, 2018 at 5:12 PM, Pedro Fuentes via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > 7. In my humble opinion, I think that these

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

On Tue, Jun 26, 2018 at 1:53 PM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > El martes, 26 de junio de 2018, 22:36:23 (UTC+2), Ryan Sleevi escribió: > > Hopefully the audit report will be just as boringly positive as usual... :) > > I'll come back then

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

Jakob, On Tue, May 1, 2018 at 1:14 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote > > However maybe an additional (clarifying or new) requirement set: > > I think the existing language in section 5.3.1 covers all of this. If not, can you point out the gaps

OISTE WISeKey Global Root GC CA Root Inclusion Request

This request is for inclusion of the OISTE WISeKey Global Root GC CA as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1403591 * BR Self Assessment is here: https://bugzilla.mozilla.org/attachment.cgi?id=8912732 * Summary of Information Gathered and Verified:

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

Ryan - thanks for raising these issues again. I still have concerns about getting this specific in the policy, but since we're now headed down that road... On Tue, May 1, 2018 at 7:13 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > A few problems I see

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

Unless there is further discussion, I will consider this issue closed with the following change to section 5.3, meaning that it applies to both unconstrained and technically constrained intermediates: Subordinate CA certificates created after January 1, 2019: * MUST contain an EKU extension; and,

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

ear, what defines a 'sufficiently secure password' as the original > > > wording lets a lot of room for 'interpretation'. > > > > > > What do you think? > > > > > > /Rufus > > > > > > > > > Siemens AG > > > Information Tec

Re: Policy 2.6 Proposal: Define/clarify policy for transfer of intermediate CA certificates

24, 2018 at 9:21 AM, Ryan Sleevi <r...@sleevi.com> wrote: > >> >> >> On Mon, Apr 23, 2018 at 6:12 PM, Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> I'm re-sending this with the subject tagged as

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

On Mon, Apr 30, 2018 at 8:27 AM, Ryan Sleevi wrote: > > > On Wed, Apr 25, 2018 at 1:03 PM, Wayne Thayer wrote: > >> On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi wrote: >> >>> I'm not sure I underestand the use case. I'm hoping that they

Re: Japan GPKI Root Renewal Request

On Thursday, August 25, 2016 at 8:07:05 PM UTC, Kathleen Wilson wrote: > > This request by the Government of Japan, Ministry of Internal > > Affairs and Communications, is to include the GPKI 'ApplicationCA2 Root' > > certificate and enable the Websites trust bit. This new root certificate > >

Re: Mis-Issuance of a SSL multi-domain certificate

Thank you for reporting this issue. I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1428877 to track the issue and SwissSign's response. - Wayne On Mon, Jan 8, 2018 at 5:08 AM, Reinhard Dietrich via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > To whom it may

Re: Misissued certificate with improper characters in DNSname

Stephen, Thanks for the report. I have a few questions: 1. Did you scan for any additional certificates containing this type of error that Quovadis or your subordinate CAs have issued? What were the findings? 2. Will the linting check be performed pre- or post-issuance? 3. When will the linting

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, Jan 10, 2018 at 10:39 AM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wed, Jan 10, 2018 at 11:24 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > I don't think that's true. If your

Re: Incident report: Failure to verify authenticity for some partner requests

Thank you for the report Tim. I just created https://bugzilla.mozilla.org/show_bug.cgi?id=1429639 to track this issue. Please follow up in the bug and on this thread. - Wayne On Wed, Jan 10, 2018 at 2:24 PM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: >

Re: 5.3.1 Technically Constrained

Ben, I'm about to use the term 'paragraph' to refer to the text within section 5.3.1 that is separated by carriage returns. The prior version of the policy contained the language in the final paragraph of section 5.3.1 - see

Updating Root Inclusion Criteria

I would like to open a discussion about the criteria by which Mozilla decides which CAs we should allow to apply for inclusion in our root store. Section 2.1 of Mozilla’s current Root Store Policy states: CAs whose certificates are included in Mozilla's root program MUST: > 1.provide

Re: ComSign Root Renewal Request

To recap, we've established that this root was first BR audited on 26-April 2015 and has received clean period-of-time audits over the next two years. ComSign has disclosed 36 certificates issued by this root prior to the BR point-in-time audit, of which one remains unexpired. This does not

Re: Camerfirma's misissued certificate

Thank you for reporting this misissuance. Since this is a different issue than described in bug 1390977, I have created a new bug to track this problem and your response: https://bugzilla.mozilla.org/show_bug.cgi?id=1431164 Please also post your incident report here. Also, the crt.sh link above

Re: Taiwan GRCA Root Renewal Request

This root inclusion request is currently in the public discussion phase [1] After reviewing Taiwan GRCA's CP, CPS and related documents [2], I have the following comments: ==Good== 1. GRCA has requested that this root be constrained to issuing certificates for .tw domains. 2. The BR Self

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 1:58 PM, Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Given this discussion, there must be no other CAs using method 9 or 10, > else they would have come forward by now with disclosures and have > demonstrated their compliance..

Re: TLS-SNI-01 and compliance with BRs

Peter, On Fri, Jan 19, 2018 at 10:06 AM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > What does Mozilla expect to be verified? We know the 10 methods allow > issuance where "the applicant has registered the domain(s) referenced in > the certificate or

Re: Google OCSP service down

On Sun, Jan 21, 2018 at 2:14 PM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > I think the whole CA incident reporting question has lots of room for > > improvement. And I think this should be considered in a way that people > > who are not familiar

Re: ComSign Root Renewal Request

Wayne [1] https://ccadb-public.secure.force.com/mozillacommunications/ CACommResponsesOnlyReport?CommunicationId=a051J3mogw7= Q00042,Q00048 On Tue, Jan 16, 2018 at 2:05 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > To recap, we've established that this

DRAFT January 2018 CA Communication

I want to directly notify all CAs in the Mozilla program of the recently exposed issues with domain validation methods and of some upcoming deadlines. A draft is available below and at https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication I would appreciate your prompt and

Re: Summary of Responses to the November CA Communication

On Wed, Jan 24, 2018 at 6:56 AM, Ryan Sleevi wrote: > This seems to be a perennial problem with CAs, and doesn't inspire > confidence in them or their operations. I am also concerned that an > extension of this nature does not inspire confidence in the Mozilla Root > Program,

Re: Summary of Responses to the November CA Communication

To the best of my knowledge, the only "standard" sanction we have today is complete distrust of a root or intermediate, and in practice that rarely happens. On the surface, the idea of lesser sanctions like removing the EV indicator for some period of time is appealing to me, but I think we need

Re: DRAFT January 2018 CA Communication

On Wed, Jan 24, 2018 at 1:50 PM, Jonathan Rudenberg <jonat...@titanous.com> wrote: > > > On Jan 24, 2018, at 15:20, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > 2. On 19-December, significant concer

Re: DRAFT January 2018 CA Communication

Based on the feedback we've received, but sticking with the original intent of this communication, I have converted it into a survey. You can find a draft at: https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication I would appreciate your comments on this. I have set the

Re: Updating Root Inclusion Criteria

On Wed, Jan 17, 2018 at 7:46 AM, Tim Hollebeek wrote: > I support "encouraging" those who are currently using the public web PKI > for > internal uses to move to their own private PKIs. The current situation is > an > artifact of the old notion that there should be a

Re: Updating Root Inclusion Criteria

On Wed, Jan 17, 2018 at 7:54 AM, Alex Gaynor wrote: > Hi Wayne, > > After some time thinking about it, I struggled to articulate what the > right rules for inclusion were. > > Yes, that is the challenge. So I decided to approach this from a different perspective: which is

Re: Updating Root Inclusion Criteria

On Wed, Jan 17, 2018 at 3:32 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/01/2018 23:03, Jonathan Rudenberg wrote: > > You seem to be stuck inside some kind of ivory tower world where > computers are king and everything is done by robots. > > This

Re: DRAFT January 2018 CA Communication

On Wed, Jan 24, 2018 at 4:05 PM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: >> >> > Is there a reason to make this deprecation conditional

Re: DRAFT January 2018 CA Communication

d, Jan 24, 2018 at 4:05 PM, Ryan Sleevi <r...@sleevi.com> wrote: > >> >> >> On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >>> >>> > Is there a reason to make this depr

Re: DRAFT January 2018 CA Communication

On Thu, Jan 25, 2018 at 11:48 AM, Jonathan Rudenberg wrote: > This is a great improvement. I think we should also ask that any CAs using > these methods immediate disclose that they are and the procedures they are > using, as well as the date they expect to complete a

Re: Summary of Responses to the November CA Communication

In the past, new policy versions have not had a clearly defined future effective date. That seems to have led some CAs to interpret the timing for making changes to be "whenever we get around to it" instead of the intent of "the policy is effective immediately and we expect you to comply with it

Re: Summary of Responses to the November CA Communication

On Wed, Jan 24, 2018 at 9:54 AM, Gervase Markham wrote: > We do actually do that, it's just not written in the policy itself. See: > https://wiki.mozilla.org/CA/Root_Store_Policy_Archive > which gives all the publication dates and compliance dates. > > Good. Then all I'm

Re: DRAFT January 2018 CA Communication

Thanks Jakob. I updated the draft as described below. On Fri, Jan 26, 2018 at 10:42 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I think a number of the questions/actions need additional options: > > For ACTION 1: > > (These 3 are between the 1st and

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

Doug, I have some questions: > > c.The hosting company must allow you to manually create and upload > a CSR for a site you don’t own > > Did you mean to say 'certificate' here instead of 'CSR'? d. The user must be able to trick the hosting provider to enable SNI > for this domain

Re: Taiwan GRCA Root Renewal Request

On Thursday, June 1, 2017 at 5:03:15 PM UTC-7, Kathleen Wilson wrote: > On Friday, May 26, 2017 at 9:32:57 AM UTC-7, Kathleen Wilson wrote: > > On Wednesday, March 15, 2017 at 5:01:13 PM UTC-7, Kathleen Wilson wrote: > > All, > > > > I requested that this CA perform a BR Self Assessment, and

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

On Fri, Jan 12, 2018 at 11:21 AM, Doug Beattie wrote: > > > Normally a web hosting provider should not let you set SNI for a domain > someone else is using, especially on that IP address. I think this is > where method 9 deviates from method 10. > > > I agree, it

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Thu, Jan 11, 2018 at 3:28 PM, josh--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > https://community.letsencrypt.org/t/2018-01-11-update-regard > ing-acme-tls-sni-and-shared-hosting-infrastructure/50188 > > Speaking for myself, this is an excellent game plan that

Re: Taiwan GRCA Root Renewal Request

Thanks for pointing this out Ryan and Dimitris. You are both correct: we should direct Taiwan GRCA to change their request from including the root to including only the subordinate CAs that comply with the Mozilla policy. The option of adding the non-compliant subordinate CAs to OneCRL does not

Re: DRAFT January 2018 CA Communication

You can find a link to the final version of the survey at https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication We're planning to send this out to all CAs in the Mozilla program later today. The deadline for responses has been set to 9-February. Thanks to everyone who

Re: DRAFT January 2018 CA Communication

The email has been sent, and we've published a blog post: https://blog.mozilla.org/security/2018/01/29/january-2018-ca-communication/ On Monday, January 29, 2018 at 1:15:51 PM UTC-7, Wayne Thayer wrote: > You can find a link to the final version of the survey at >

Re: Updating Root Inclusion Criteria

On Fri, Jan 19, 2018 at 3:04 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 18/01/18 14:24, Ryan Sleevi wrote: > > Isn't this effectively the VISA situation? When were their first audits - > > late 2016 / early 2017? > > I'm not certain; I'll ask

Re: Updating Root Inclusion Criteria

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 can be measured and applied fairly’. While some suggestions have been made, no clear set of criteria has emerged. At the same time, we’ve heard the

Re: ComSign Root Renewal Request

Yair, Will you please provide a detailed response to each of Ryan's points? Also, please provide the specific version of the RSA Certificate Manager in use by ComSign. Thanks, Wayne On Mon, Jan 29, 2018 at 8:43 AM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:

Re: Certificates with 2008 Debian weak key bug

On Mon, Feb 5, 2018 at 4:33 PM, Alex Cohn via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I logged two of those five certificates (https://crt.sh/?id=308392091 > and https://crt.sh/?id=307753186) to Argon, as part of a project to > log every certificate in the censys.io

Re: Certificates with 2008 Debian weak key bug

I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1435770 requesting an incident report from Certum. On Mon, Feb 5, 2018 at 10:07 AM, Eric Mill via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > WoSign and StartCom are untrusted, but Certum is still trusted, right?

Re: Misissuance/non-compliance remediation timelines

On Tue, Feb 6, 2018 at 6:03 PM, Paul Kehrer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > So, how long is too long? > This is the crux of the issue for me. If a CA (that really should have stopped responding 'good' for unknown certs back in 2013) needs to select,

Re: Certificate for com and it

On Thu, Feb 8, 2018 at 8:54 AM, Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 08/02/18 15:50, Gervase Markham via dev-security-policy wrote: > >> On 08/02/18 13:47, Hanno Böck wrote: >> >> OneCRL additions normally have an associated bug but I can't

Re: ComSign Root Renewal Request

On Wed, Feb 7, 2018 at 8:18 AM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Wyane, > resopnding to your notes: > > Section 4.9 states that in any case that Comsign is notified about a > misissuance (no matter if it was notified by a subscriber or in any

Re: ComSign Root Renewal Request

Yair, > Re Section 3.4, you seem to assume the domain holder is a ComSign > > subscriber. In case of misissuance, that may not be true. > >>> I understand, for that we added on the CPS on section 3.4 the > following: > "For the handling of revocation requests by other than the Subscriber or >

Re: Mozilla’s Plan for Symantec Roots

On Thu, Feb 8, 2018 at 7:26 AM, Kai Engert via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 16.10.2017 19:32, Gervase Markham via dev-security-policy wrote: > > The subCAs that we know of that fall into this category belong to Google > > and Apple. If there are any

Re: DRAFT January 2018 CA Communication

-Tugra I will allow a grace period of a few days and then will open incident bugs for those CAs that still haven't responded. - Wayne On Mon, Jan 29, 2018 at 5:14 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The email has been sent, and we've

Re: Japan GPKI Root Renewal Request

All of my questions regarding the CP/CPS and audits have been answered to my satisfaction. I am left with two concerns: 1. This root was signed on 12-March 2013. The first end-entity certificate that I'm aware of was signed later in 2013. Mozilla began requiring BR audits in 2014, but the first

Re: ComSign Root Renewal Request

Hi Yair, On Mon, Feb 12, 2018 at 11:50 AM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Wayne, > Please realize our situation versus the Israeli market. We are the major > certificate authority and we comply with every piece of local regulation, > we are

Re: Public trust of VISA's CA

On Tue, Feb 13, 2018 at 10:49 AM, Jonathan Rudenberg wrote: > > > On Sep 19, 2017, at 11:12, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > In the light of this, I believe it is reasonable to discuss the question > > of

Re: Public trust of VISA's CA

On Tue, Feb 13, 2018 at 11:26 PM, Paul Kehrer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On February 14, 2018 at 4:17:16 AM, Wayne Thayer via dev-security-policy ( > dev-security-policy@lists.mozilla.org) wrote: > > > The most recent BR audi

Re: Public trust of VISA's CA

On Wed, Feb 14, 2018 at 10:47 AM, Tim Smith via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, February 14, 2018 at 8:43:19 AM UTC-8, Wayne Thayer wrote: > > In this particular case, my conclusion is that the existing Mozilla > > process is working. We have

  1   2   3   4   5   6   7   >