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: 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: 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

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: 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

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

Results of September 2018 CA Communication

The responses to our latest survey are posted on the wiki [1]. I would like to thank all the CAs that responded promptly to the survey. We have now received responses from all but two CAs: - Visa - as of Firefox 64 [2], Visa will no longer be a program member. - Certicamara - I have emailed and

Re: Yet more undisclosed intermediates

Thank you Rob. On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > "ACTION 6" of Mozilla's September 2018 CA Communication [1] reminded CAs > of the Mozilla Root Store Policy requirement [2] that > non-technically-constrained

Re: Odp.: 46 Certificates issued with BR violations (KIR)

On Tue, Oct 9, 2018 at 5:30 AM Grabowski Piotr wrote: > Hello Wayne, > > Please find our comments below: > > > So far the process for modifying policy templates was controlled by only > one person at the moment. Although these persons > have an extensive experience in PKI and preparing

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

On Tue, Oct 9, 2018 at 12:48 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Oh, so rather than trying to define what "No Stipulation" means and when > it can be used, we could take a different approach -- list the sections > that cannot contain "No

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: 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)

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: 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

Re: InfoCert investment in LuxTrust

Thank you Yves. I do not have any other questions, and I do not believe that any further actions are required. - Wayne On Mon, Oct 1, 2018 at 8:07 AM Yves Nullens wrote: > Wayne, > > > > I confirm that the only change following this investment is the update of > the overview chapter. > > > >

Re: Increasing number of Errors found in crt.sh

Doug, Responding to your original question, I look at crt.sh and other data sources for certificate errors when reviewing inclusion requests or doing other sorts of investigations. I am not currently reviewing the crt.sh report for misissuance on a regular basis, but maybe I should. I went

Re: Visa Issues

On Fri, Sep 28, 2018 at 12:29 PM Eric Mill wrote: > > > On Thu, Sep 27, 2018 at 5:22 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Visa has filed a bug [1] requesting removal of the eCommerce root from the >>

Re: InfoCert investment in LuxTrust

Yves, Thank you for bringing this to our attention. Section 8.1 of the Mozilla Root Store policy [1] applies here. It is not completely clear to me that 50% ownership is a "controlling stake", but even if it is, InfoCert is already a member of the Mozilla root program by way of its acquisition of

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: 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: AC Camerfirma's CP & CPS disclosure

Hello Ramiro, On Tue, Sep 4, 2018 at 3:13 PM Wayne Thayer wrote: > Thank you for this response Ramiro. I have copied this to the bug [1] and > have described Mozilla's expectations for point-in-time audits that confirm > that these issues have been resolved. > > [1]

Re: InfoCert Acquisition of Camerfirma

I've held this discussion open for much longer than 3 weeks due to the qualified audit reports that were received from Camerfirma. Since no objections to the acquisition have been raised and the audit issues are being discussed separately [1][2], I would like to close this discussion and the

Re: Google Trust Services Root Inclusion Request

I'm disputing the conclusion that is being drawn from Jake's concerns, rather than the concerns themselves. Primarily, I disagree with the conclusion that because Google owns a browser with dominant market share and - due to the substantial contributions they make here - because Google has

Re: Request to Include SHECA UCA Global G2 Root and UCA Extended Validation Root

I believe that SHECA has addressed all the concerns raised during the discussion period. I am now closing the discussion with a recommendation to approve this inclusion request. Any further comments should be added directly to the bug [1]. I would like to thank everyone who contributed to this

Re: Identrust Commercial Root CA 1 EV Request

:34 -0700 > Wayne Thayer via dev-security-policy > wrote: > > > * The version of the CPS that I initially reviewed (4.0) describes a > > number of methods of domain name validation in section 3.2.10.5 that > > do not appear to fully comply with the BRs. This was corrected

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

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 > wrote: > > > ** EV Policy OID: 2.23.140.1.1 > > This reminds me of a question I keep meaning to as

Identrust Commercial Root CA 1 EV Request

This request is to enable EV treatment for the Identrust Commercial Root CA 1 as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1339292 * BR Self Assessment is here: https://bugzilla.mozilla.org/attachment.cgi?id=8964414 * Summary of Information Gathered and

Re: Violation report - Comodo CA certificates revocation delays

I have created a bug and requested a response from Comodo: https://bugzilla.mozilla.org/show_bug.cgi?id=1492006 As noted, there are no specific requirements regarding how CAs validate revocation requests in the BRs. Every CA may do this however they choose, so I don't believe there is any action

Re: Google Trust Services Root Inclusion Request

On Mon, Sep 17, 2018 at 3:19 PM jtness--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > The risk of any given browser vendor also being a Root CA is small as most > browser vendors do not have the requisite market share to make unilateral > decisions. Google

Re: Google Trust Services Root Inclusion Request

On Mon, Sep 17, 2018 at 9:43 AM Wayne Thayer wrote: > Even though the discussion period has ended, Mozilla will continue to > consider factual information that is submitted as comments here: > https://bugzilla.mozilla.org/show_bug.cgi?id=1325532 > > Your concern about "without comment and then

Re: DRAFT September 2018 CA Communication

Thanks everyone for your feedback. The September 2018 CA Communication has just been sent to all primary points-of-contact for CAs in our program. CAs have been asked to respond by 30-September. I will also be adding a post to https://blog.mozilla.org/security/ announcing the survey, - Wayne On

Re: Google Trust Services Root Inclusion Request

Even though the discussion period has ended, Mozilla will continue to consider factual information that is submitted as comments here: https://bugzilla.mozilla.org/show_bug.cgi?id=1325532 Your concern about "without comment and then get approved" may stem from a misunderstanding of Mozilla's

Re: Google Trust Services Root Inclusion Request

The three week discussion period for this inclusion request has passed with no comments received. I am now closing this discussion with a recommendation to approve this request. Any further comments should be added directly to the bug. - Wayne On Thu, Aug 23, 2018 at 3:58 PM Wayne Thayer wrote:

Re: DRAFT September 2018 CA Communication

On Fri, Sep 7, 2018 at 8:22 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Fri, Sep 7, 2018 at 9:55 AM Bruce via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Thursday, September 6, 2018 at 7:44:15 PM UTC-4, Wayne

Re: Visa Issues

n 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 is included in the Mozilla program. I opened a bug [1] and >> r

Visa Issues

Visa recently delivered new qualified audit reports for their eCommerce Root that is included in the Mozilla program. I opened a bug [1] and requested an incident report from Visa. Visa was also the subject of a thread [2] earlier this year in which I stated that I would look into some of the

Re: Request to Include SHECA UCA Global G2 Root and UCA Extended Validation Root

Thank you Toria. On Tue, Sep 11, 2018 at 7:32 AM chenxiaotong--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 在 2018年9月1日星期六 UTC+8上午7:19:49，Wayne Thayer写道： > > > > * The CP/CPS documents contain version histories, but they didn’t > describe > > what changed in each

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

Josselin: thank you for filing this incident report, and for your answers to the questions being asked in this thread. Please add the incident report to the related bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1485413 I will also ask you to answer the new questions that have been asked to

Re: Certigna Root Renewal Request

On Tue, Sep 11, 2018 at 12:37 AM josselin.allemandou--- via dev-security-policy wrote: > Hello, > > Thanks Wayne and Devon for your reply. > > We took the time to respond because we wanted to verify through an audit > that the SSL certificate requests processed since September 8th were in >

Re: DRAFT September 2018 CA Communication

Thanks for the suggestion Jakob. I will pass it on to the engineering team. On Fri, Sep 7, 2018 at 8:04 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 07/09/2018 15:55, Bruce wrote: > > On Thursday, September 6, 2018 at 7:44:15 PM UTC-4, Wayne Thayer

Re: DRAFT September 2018 CA Communication

Thanks for the response Bruce. On Fri, Sep 7, 2018 at 6:55 AM Bruce via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, September 6, 2018 at 7:44:15 PM UTC-4, Wayne Thayer wrote: > > All, > > > > I've drafted a new email and survey that I hope to send to all

DRAFT September 2018 CA Communication

All, I've drafted a new email and survey that I hope to send to all CAs in the Mozilla program next week. it focuses on compliance with the new (2.6.1) version of our Root Store Policy. I would appreciate your feedback on the draft:

Re: Telia CA - problem in E validation

Telia has described their plans to remediate the qualifications listed in their latest audit reports: https://bugzilla.mozilla.org/show_bug.cgi?id=1475115#c13 In summary: * Telia is planning to obtain point-in-time audit reports to confirm that the issues have been resolved. I have asked Telia

Re: AC Camerfirma's CP & CPS disclosure

Thank you for this response Ramiro. I have copied this to the bug [1] and have described Mozilla's expectations for point-in-time audits that confirm that these issues have been resolved. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1478933 On Tue, Sep 4, 2018 at 5:47 AM ramirommunoz--- via

Request to Include SHECA UCA Global G2 Root and UCA Extended Validation Root

This request is for inclusion of the Shanghai Electronic Certification Authority Co., Ltd. UCA Global G2 Root and UCA Extended Validation Root as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1309797 * BR Self Assessment is here:

Re: AC Camerfirma's CP & CPS disclosure

Hello Juan, Was this message intended to be a response to the discussion of Camerfirma's qualified audits in https://bugzilla.mozilla.org/show_bug.cgi?id=1478933 ? I am awaiting a full response to comment #7 in which I requested a full remediation plan for the issues identified by these audits.

Re: 2018.08.23 Let's Encrypt OCSP Responder Incident

Josh, Thank you for submitting this incident report. I created a bug to track the incident and remediation efforts: https://bugzilla.mozilla.org/show_bug.cgi?id=1486650 - Wayne On Fri, Aug 24, 2018 at 1:07 PM josh--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > To

Re: Audit Reminder Email Summary

On Sun, Aug 26, 2018 at 11:25 PM reinhard.dietrich--- via dev-security-policy wrote: > Dear all > > This is a joint answer to Waynes' request. > > it was mentioned that the audit period was exceeded. We would like to > explain the situation and what was undertaken to avoid such situation again.

Google Trust Services Root Inclusion Request

This request is for inclusion of the Google Trust Services R1, R2, R3, and R4 roots as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1325532 Google’s application states: Google is a commercial CA that will provide certificates to customers from around the world.

Re: Audit Reminder Email Summary

Kurt, Thank your for raising this issue. As documented in the bug you referenced, there was a good deal of confusion about Mozilla's acceptance (or not) of SwissSign's 2017 audit statements. Mozilla rejected the first statements and then asked questions about the second set of statements but

Re: Certigna Root Renewal Request

Thank you for your response. On Wed, Aug 22, 2018 at 11:51 AM josselin.allemandou--- via dev-security-policy wrote: > We confirm that no, this is not the case. This is what we said in the CP / > CPS because we thought that these constraints could be regularly > encountered and that it could be

Re: Certigna Root Renewal Request

On Wed, Aug 22, 2018 at 2:10 AM josselin.allemandou--- via dev-security-policy wrote: > > > > CPS Section 4.2.1: If the request is valid and allows to obtain with > accuracy the authorization to issue the certificate by

Re: GoDaddy Revocation Disclosure

Thank you for the disclosure Daymion. I have created bug 1484766 to track this issue. I've requested an incident report to help the community better understand what happened and what can and is being done to prevent similar problems in the future, as described in the last two topics [1]: 6.

Re: Misissuance and BR Audit Statements

Thank you for responding on behalf of ETSI ESI and ACABc! I believe that this is an important topic and I hope that ETSI ESI and ACABc members will continue to participate in the discussion. On Thu, Aug 16, 2018 at 11:11 AM clemens.wanko--- via dev-security-policy <

Re: A vision of an entirely different WebPKI of the future...

What problem(s) are you trying to solve with this concept? If it's misissuance as broadly defined, then I'm highly skeptical that Registry Operators - the number of which is on the same order of magnitude as CAs [1] - would perform better than existing CAs in this regard. You also need to consider

Re: DEFCON Talk - Lost and Found Certificates

On Thu, Aug 16, 2018 at 7:25 AM Eric Mill wrote: > > I think this paper provides a good impetus to look at further shortening > certificate lifetimes down to 13 months. That would better match the annual > cadence of domain registration so that there's a smaller window of time > beyond domain

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

://bugzilla.mozilla.org/show_bug.cgi?id=1403591 On Tue, Aug 14, 2018 at 3:49 PM Ryan Sleevi wrote: > Sorry for the delay in responding. I think this resolves the ambiguity as > to the gaps and is a good path forward. > > On Wed, Aug 1, 2018 at 7:37 PM, Wayne Thayer via dev-security-po

Re: Misissuance and BR Audit Statements

32431 > [D] https://crt.sh/?id=351449246 > [E] https://bugzilla.mozilla.org/show_bug.cgi?id=1447192 > [F] https://bugzilla.mozilla.org/show_bug.cgi?id=1465600 > [G] https://bugzilla.mozilla.org/show_bug.cgi?id=1398269#c29 > > On Tue, Aug 7, 2018 at 1:32 PM, Wayne Thayer via dev-securi

Re: Do We Now Require Separate Cross-certificates for SSL and S/MIME?

The updated 2.6.1 version of the Mozilla Root Store policy resulting from this discussion is now published: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ - Wayne On Mon, Aug 6, 2018 at 3:28 PM Wayne Thayer wrote: > Having received no comments on this

DEFCON Talk - Lost and Found Certificates

I'd like to call this presentation to everyone's attention: Title: Lost and Found Certificates: dealing with residual certificates for pre-owned domains Slide deck:

Re: How to submit WebTrust audits in CCADB

I don't think I'm giving away any big secret by revealing that the seal website is just doing an http_referer check. If you are blocked when trying to access an audit report on cert.webtrust.org, just set the referer to the CA's domain name and refresh. You can do this with any number of Firefox

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

The proposed "Revocation Timeline Extension" ballot (formerly #213, soon to become #SC6) [1] includes the following: The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise,

Re: AC Camerfirma's organizationName too long incident report

Thank you for the incident report Juan. I created https://bugzilla.mozilla.org/show_bug.cgi?id=1481862 to track this issue. Please update the bug as action items are completed. On Wed, Aug 8, 2018 at 8:41 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: >

Misissuance and BR Audit Statements

Given the number of incidents documented over the past year [1][2] for misissuance and other nonconformities, I would expect many of the 2018 period-of-time WebTrust audit statements being submitted by CAs to include qualifications describing these matters. In some cases, that is exactly what

Re: Do We Now Require Separate Cross-certificates for SSL and S/MIME?

Having received no comments on this proposal, I plan to go ahead and publish version 2.6.1 of the Mozilla Root Store Policy with the third paragraph of section 5.3 clarified as follows: Intermediate certificates created after January 1, 2019, with the exception of cross-certificates that share a

Re: Telia CA - problem in E validation

Thank you for supplying this incident report. For reference, this is in response to https://bugzilla.mozilla.org/show_bug.cgi?id=1475115 On Fri, Aug 3, 2018 at 1:55 AM pekka.lahtiharju--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Incident report: > > PROBLEM IN

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

Having received the audit reports covering the period from the creation of this root, I would like to resume this discussion. Please post any remaining comments that you have on this inclusion request by next Friday, 10-August. - Wayne On Tue, Jul 31, 2018 at 2:47 AM Pedro Fuentes via

Re: Possible violation of CAA by nazwa.pl

This discussion has covered a lot of ground. Here are my comments: 1. Nazwa is not independently audited, nor are they a member of the Mozilla root program. I am also unable to locate any information that makes Nazwa an Affiliate of Certum. I believe they are simply a Certum reseller. In this

Re: GoDaddy Revocations Due to a Variety of Issues

Thank you for this report Daymion. 3 of the issues were recent: | e_dnsname_not_valid_tld, | | |e_subject_common_name_not_from_san,| | |e_dnsname_bad_character_in_label |4

Re: InfoCert Acquisition of Camerfirma

On Wed, Jul 18, 2018 at 1:56 PM Wayne Thayer wrote: > I would like to begin a 3-week public discussion period for InfoCert's > acquisition of Camerfirma [1] as described in section 8.1 of the Mozilla > Root Store Policy. I believe that the intent of our policy in this scenario > is to identify

Re: GlobalSign Root CA - R6 Inclusion Request

3 weeks have passed and no comments have been made on this inclusion request. Meanwhile, I have requested and received additional information from GlobalSign confirming that this root certificate has been included in their BR audits back to its creation [1], in compliance with section 7.1 of

Re: InfoCert Acquisition of Camerfirma

I would like to begin a 3-week public discussion period for InfoCert's acquisition of Camerfirma [1] as described in section 8.1 of the Mozilla Root Store Policy. I believe that the intent of our policy in this scenario is to identify and consider any risks introduced by the acquisition of

Re: Do We Now Require Separate Cross-certificates for SSL and S/MIME?

Kathleen pointed out that one of the purposes of this section is to require disclosure of cross-certificates, and my first attempted fix seems to violate that purpose. Here is my second attempt to clarify the language in section 5.3:

Re: Chunghwa Telecom eCA Root Inclusion Request

While I sincerely appreciate the efforts of Chunghwa Telecom to respond to questions and to remediate some of the issues that were identified here, this discussion ha made it clear that this request should be denied. There is a significant degree of misissuance associated with this root, some of

Re: Do We Now Require Separate Cross-certificates for SSL and S/MIME?

On Fri, Jul 13, 2018 at 3:50 PM Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Yeah, I agree I don’t think it was intended. But now that I am aware of > the issue, I think the crossing workaround per EKU is actually a good thing > for people to be doing.

Re: GlobalSign Root CA - R6 Inclusion Request

Reminder: this request will complete the 3-week minimum discussion period on Thursday. If you have any comments on this request, please post them before July 19th. On Thu, Jun 28, 2018 at 12:16 PM Wayne Thayer wrote: > This request is for inclusion of the GlobalSign Root CA - R6 as documented >

Re: Chunghwa Telecom eCA Root Inclusion Request

On Fri, Jul 13, 2018 at 3:03 AM lcchen.cissp--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Dear Wayne, > >Those programs for checking field of ToBeSign SSL certificate are > online on June 22. > >We suggest that CA "in principle" must comply with the string

Do We Now Require Separate Cross-certificates for SSL and S/MIME?

During a 2.6 policy discussion [1], we agreed to add the following language to section 5.3 "Intermediate Certificates": > Intermediate certificates created after January 1, 2019: > > > * MUST contain an EKU extension; and, > * MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and, > * MUST

Re: Chunghwa Telecom eCA Root Inclusion Request

The specific CP/CPS concerns that I identified have been addressed in the latest version of these documents (attached to bug #1341604). Some of the misissuances [1] have been addressed - in particular, the 10 "dedicated server application software certificates" have been revoked and replaced with

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: 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: 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: Root Store Policy 2.6

Version 2.6 of the policy has been reviewed and (with some minor changes to section 7.3) approved by Mozilla's Legal department. I've set the effective date to July 1, 2018 and requested publication of the new version. Meanwhile, it can be found here:

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 >

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: 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

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

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, >

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: 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: 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

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)

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

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)

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

<    1   2   3   4   5   6   7   >