> -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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
> >
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
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
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
>
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
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
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
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
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
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
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
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
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
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,
>
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
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:
>
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
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:
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
>
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
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
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
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
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
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
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:
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
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,
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
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
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
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
> >
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
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
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
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:
>
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
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
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
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
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
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..
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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:
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
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?
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,
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
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
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
>
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
-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
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
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
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
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
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 - 100 of 604 matches
Mail list logo