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 l
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
>
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.
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
th
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:
https://github.com/mozilla/pkipolicy/commit/43bdf5d6e97cdda0d8b1
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
Camerfir
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
versio
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 an
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
|
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 inst
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 dev-securit
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 SUB
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 p
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 we’re
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:
> On
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, Ce
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
ex
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:
https://media.defcon.org/DEF%20CON%2026/DEF%20CON%2026%20presentations/DEFCON-26-Foster-and-Ayrey-Lost-and-Found-Certs-residual-cert
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 prop
=8999669
> [C] https://crt.sh/?id=23432431
> [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
://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
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 exp
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
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 <
dev-security-policy@lists.mozil
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. Explan
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
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 b
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 neve
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. We
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.
>
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 s
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.
-
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:
https://bugzilla.mozilla.org/attach
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 d
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 to
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:
https://ccadb-public.secure.force.com/mozillacommunications/CACo
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 CAs
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 wr
On Sun, Sep 9, 2018 at 7:31 PM chenxiaotong--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 在 2018年9月1日星期六 UTC+8上午7:19:49，Wayne Thayer写道：
>
> > ==Bad==
> > * A few unrevoked certificates with IP Addresses encoded as DNSName type
> in
> > the SAN [4]. I reported these t
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
> compl
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 th
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 ve
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 conc
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 is included in the Mozilla program. I opened a bug [1] and
>&
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 Thayer
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:
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 proce
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 T
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 ge
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 possesses
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 r
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 Verifie
0, 2018 at 1:49 AM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tue, 18 Sep 2018 17:53:34 -0700
> Wayne Thayer via dev-security-policy
> wrote:
>
> > ** EV Policy OID: 2.23.140.1.1
>
> This reminds me of a question I keep mea
17:53: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 corr
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 dis
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 consider
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 corres
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] https://bugzilla.mozilla.org/
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 t
nt/Calendar
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
>&
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
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
>>
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 throug
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.
>
>
>
> Be
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 unlikely
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> wro
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 discoverabl
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,
>
>
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
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 Sti
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 certificat
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 inte
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 wi
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 surv
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 t
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:
https://bug144233
?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 four
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
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 Certu
>> templates for management on the 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=3
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 UTC
Having given this some more thought, I suggest the following changes:
* Forbid "no stipulation" altogether. While there are a few sections where
it would be convenient to use "No stipulation" (e.g. 4.2.3 Time to Process
Certificate Applications), I don't see a requirement for more descriptive
lang
I believe that the discussion over Certigna's reported CAA misissuance
[1][2] has reached an end, even though some questions remain unanswered. If
anyone has additional comments or concerns about this inclusion request,
please respond by Friday 26-October. This request [3] has been in
discussion si
/CPS in August 2018 to comply with
> > new BRs, and again in May 2019 due to annual review, they need not comply
> > until May 2019.
> >
> > >
> > >> -Original Message-
> > >> From: dev-security-policy
> > >> On
On Tue, Oct 23, 2018 at 1:46 PM David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 10/23/2018 11:45 AM, Wayne Thayer wrote:
> > I believe that the discussion over Certigna's reported CAA misissuance
> > [1][2] has reached an end, even though some questions r
On Wed, Oct 24, 2018 at 3:02 PM David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 10/24/2018 1:07 PM, Wayne Thayer wrote:
> > On Tue, Oct 23, 2018 at 1:46 PM David E. Ross via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >>
On Thu, Oct 25, 2018 at 11:17 AM Joanna Fox via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Questions about blank sections, thinking of a potential future
> requirement. Sections such as 1.INTRODUCTION would remain blank as they are
> more titles than components, correct?
On Thu, Oct 25, 2018 at 10:11 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 26/10/2018 01:13, Ryan Sleevi wrote:
> > On Thu, Oct 25, 2018 at 5:47 PM Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On 25/10
.com or through the website
> http://webcrm.camerfirma.com/incidencias/incidencias.php
>
>
> -Mensaje original-
> De: dev-security-policy
> [mailto:dev-security-policy-boun...@lists.mozilla.org] En nombre de Wayne
> Thayer via dev-security-policy
> Enviado el: jueves, 27 de septiem
Having received no further comments, I am recommending approval of
Certigna's inclusion request.
I would first like to thank Certigna for their patience as this request
spent a long time waiting on Mozilla.
The disregard for CAB Forum requirements shown by Certigna's CAA exception
process is a ve
Thank you for the incident report Pedro.
On Thu, Nov 1, 2018 at 1:36 AM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> This intermediate was created under a new Root and its main purpose was to
> issue the required test certificates to request inclusion.
I am recommending denial of this request.
It was not uncommon for CAs to treat the .int TLD as an Internal Name, so
I'm not going to argue this point and claim that these certificates were
misissued because 'identrust.int' and 'identrus.int' were not registered
domain names.
Under the assumption
I am particularly disturbed by three points made by TUVIT during this
discussion:
1. A malformed qcStatement extension is a minor non-conformity because
there is no known security risk - This argument is incredibly dangerous and
harmful. It implies that all sorts of well-defined requirements can b
In addition, I take exception to the statement that open criticism is a bad
approach and the implication that private discussions are the best way to
make improvements. This is clearly not Mozilla's philosophy.
I do believe that we all need to be careful to follow Mozilla forum
etiquette [1] and c
It might be helpful for me to provide a better explanation of the thinking
that went into my recommendation:
The timeline of the Internal Name incident is as follows:
* Identrust appears to have stopped issuing certificates containing .INT
names prior to the BR deadline.
* They then failed to revo
I'm not convinced there is an answer here. It seems that most would agree
with the premise that we should consider the circumstances and context for
an issue and make a balanced assessment. That leaves the matter of what
this means in practice up for debate. Often, it appears to be a debate
between
As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1]
creating a sunset period for TLS certificates containing an underscore
("_") character in the SAN. This practice was widespread until a year ago
when it was pointed out that underscore characters are not permitted in
dNSName
uirement.
- Man Ho
>
> On 11/13/2018 7:18 AM, Wayne Thayer via dev-security-policy wrote:
> > As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1]
> > creating a sunset period for TLS certificates containing an underscore
> > ("_") character in
relevant compliance dates in the email are correct, so I'm not planning
to resend the CA communication.
- Wayne
On 11/13/2018 7:18 AM, Wayne Thayer via dev-security-policy wrote:
>> > As you may be aware, the CA/Browser Forum recently passed ballot SC12
>> [1]
>> >
Since there haven't been any further comments regarding my recommendation
to deny this request, I would like to ask for feedback on next steps that
Identrust can take in the event of a denial. I believe that Identrust would
still like to pursue EV recognition in Firefox, but I think it's unlikely
t
301 - 400 of 624 matches
Mail list logo
