https://bugzilla.mozilla.org/show_bug.cgi?id=1531817 has been created to
track this issue.
On Wed, Feb 27, 2019 at 10:52 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi Cynthia,
>
> We've figured out what happened with your certificate but are still
On Mon, Mar 4, 2019 at 3:29 AM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Writing with my personal hat on:
>
>
> > -Ursprüngliche Nachricht-
> > Von: dev-security-policy
> Im Auftrag von Matthew Hardeman via dev-security-policy
> > On Sun,
On Mon, Mar 4, 2019 at 9:04 AM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Sun, Mar 3, 2019 at 6:13 PM Ryan Sleevi wrote:
>
> >
> > It is not clear how this follows. As my previous messages tried to
> > capture, the program is, and has always
The recent Reuters report on DarkMatter [1] has prompted numerous questions
about their root inclusion request [2]. The questions that are being raised
are equally applicable to their current status as a subordinate CA under
QuoVadis (recently acquired by DigiCert [3]), so it seems appropriate to
Neil,
On Sat, Mar 2, 2019 at 8:52 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> All,
>
> Included is an incident report, formatted per the Mozilla recommendations,
> with timelines and resolutions.
>
> Thank you for completing an excellent incident
I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1532429 to track
this incident.
On Fri, Mar 1, 2019 at 1:55 PM David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 2/28/2019 7:45 PM, 孙圣男 wrote:
> > Dear Mozilla：
> > This problem had been
Li-Chun: thank you for this incident report. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1532436 to track this issue.
On Fri, Mar 1, 2019 at 5:59 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 28/02/2019 17:48, lcchen.ci...@gmail.com
Ryan - Thank you for the feedback.
On Fri, Mar 15, 2019 at 6:14 PM Ryan Sleevi wrote:
> While I realize the thinking is with regards to the recent serial number
> issue, a few questions emerge:
>
> 1) Based on the software vendor reporting, they don’t view this as a
> software defect, but a CA
Thank you for this incident report. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1535871 to track this issue.
- Wayne
On Wed, Mar 13, 2019 at 9:56 AM Berge, J. van den (Jochem) - Logius via
dev-security-policy wrote:
> Hello MDSP,
>
> Logius PKIoverheid wants to report a
Thank you for the incident report. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1535873 to track this issue.
- Wayne
On Wed, Mar 13, 2019 at 1:35 PM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> When the serial number issue was first
In bug 1523221 [1], GRCA (Government of Taiwan) has responded to a
misissuance report by stating that the certificates in question are not
intended for serverAuth or emailProtection. However, our policy applies to
certificates **capable** of being used for serverAuth or emailProtection,
including
On Fri, Mar 15, 2019 at 8:54 AM Andrew via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Perhaps the solution should be to amend the BRs to allow for more flexible
> handling of situations such as this.
>
>
After a long debate, the BR revocation requirements were recently
Thank you for this incident report Fotis. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1534145 to track this issue.
On Fri, Mar 8, 2019 at 4:37 PM Fotis Loukos via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> ### Problem description
>
> SSL.com has issued
I am happy to create the bugs, and have done so for this issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=1534147
On Sun, Mar 10, 2019 at 11:52 AM James Burton via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi Fotis,
>
> You need to file this as a bugzilla bug.
>
>
I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1533774 to track
this issue.
Apple has also submitted the following bug for this issue listing a large
number of impacted certificates:
https://bugzilla.mozilla.org/show_bug.cgi?id=1533655
- Wayne
On Thu, Mar 7, 2019 at 7:14 PM Matthew
On Thu, Mar 7, 2019 at 9:20 AM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> What the people of the UAE don't have today is the ability to acquire
> globally trusted certificates from a business in their own legal
> jurisdiction who would be able to
Nadim and Matthew,
Can you explain and provide examples for how this "set of empirical
requirements" differs from the objective requirements that currently exist?
Nadim, your latest suggestion sounds different from your earlier suggestion
that Mozilla provide a "set of unambiguous statements for
Ryan beat me to the punch. so I'll reinforce his message with my own:
The overall potential impact from revocations in the current scenario feels
quite similar to the potential for disruption from revoking certificates
containing underscores a few months ago. Mozilla's guidance for revocation
[1]
Later this month, I would like to begin discussing a number of proposed
changes to the Mozilla Root Store policy [1]. I have reviewed the list of
issues on GitHub and labeled the ones that I recommend discussing:
https://github.com/mozilla/pkipolicy/labels/2.7 They are:
173 - Strengthen
On Fri, Mar 8, 2019 at 4:03 PM Jeremy Rowley
wrote:
> Apologies, I realize that Mozilla’s policy is that revocation is up to the
> CA and there is no such thing as an exception. A more careful way to state
> what I meant is that I’m surprised that there is not more discussion around
> the
As I mentioned last week [1], the "serial number entropy" issue has
identified some improvements that could be made to Mozilla's guidance for
CAs on revocation when responding to an incident. These are relatively
minor clarifications and in no way do they represent a fundamental change
in our
On Sat, Mar 9, 2019 at 12:49 PM Dimitris Zacharopoulos via
dev-security-policy wrote:
>
> The question I'm having trouble answering, and I would appreciate if
> this was answered by the Mozilla CA Certificate Policy Module Owner, is
>
> "does Mozilla treat this finding as a violation of the
On Fri, Mar 22, 2019 at 9:19 AM Benjamin Gabriel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> On 2/24/19 11:08 AM, Nex wrote:
>
> > The New York Times just published another investigative report that
> mentions
> > DarkMatter at length, with additional testimonies
I've been asked if the section 5.1.1 restrictions on SHA-1 issuance apply
to timestamping CAs. Specifically, does Mozilla policy apply to the
issuance of a SHA-1 CA certificate asserting only the timestamping EKU and
chaining to a root in our program? Because this certificate is not in scope
for
I just noticed that my response to David's question was only sent to his
(nobody@nowhere.invalid) reply address and not to the list.
On Wed, Sep 26, 2018 at 4:41 PM David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 9/26/2018 3:21 PM, Wayne Thayer wrote:
>
Telia has supplied the point-in-time audit reports required to verify
remediation of the audit issues that were described in this thread and in
https://bugzilla.mozilla.org/show_bug.cgi?id=1475115
Links to the PiT reports:
Perhaps more concerning, this sounds a lot like bug #1462844 in which
misissued certificates were reported that had not been found and revoked
despite GoDaddy having previously scanned their database for the issue.
GoDaddy never identified or described how they would remediate the cause of
that
Thanks Corey and Jakob, I opened a bug for this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1527423
Corey, did you report this via DigiCert's problem reporting mechanism?
Thanks,
Wayne
On Mon, Feb 11, 2019 at 8:01 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org>
Mozilla's guidance for incident response lives at
https://wiki.mozilla.org/CA/Responding_To_An_Incident
I just made some significant changes to the Revocation section that reflect
the approach we took with the recent underscore sunset.
Most notably, the following paragraph:
However, it is not
Thank you for the incident report. I have created a bug for tracking:
https://bugzilla.mozilla.org/show_bug.cgi?id=1528290
- Wayne
On Fri, Feb 15, 2019 at 7:21 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> (Sending from the right e-mail)
>
> On Fri,
"Pre-production" CPS
> will be version 5, replacing the current CPS.
>
> If any member has other comments, you're welcome to bring it out.
>
>
> On 16-Jan-19 5:30 AM, Wayne Thayer via dev-security-policy wrote:
>
>
> I think you and David are also suggesting that
This may be of interest:
https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-own-root-certificate-store/
- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
On Tue, Feb 5, 2019 at 11:55 AM Matthias van de Meent via
dev-security-policy wrote:
> On Tue, 5 Feb 2019 at 16:58, Ryan Sleevi wrote:
>
> > CAs are not presently required to disclose those profiles in that
> detail, but it sounds as if the issue is that Sectigo did not update the
> CP/CPS
Izenpe posted the following response to the bug [1]:
My apologies for the delayed follow up response. First we must say that we
don't see any benefit for the community of publishing the name and version
of our PKI software, regardless of security issues.
As previously stated, we have two filters
Ryan,
On Mon, Feb 18, 2019 at 4:58 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Mon, Feb 18, 2019 at 2:49 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On 15/02/2019 19:33, Ryan Sleevi wrote:
> > > On
I have replaced some outdated information on Mozilla's wiki about
revocation checking [1] [2] with a new page on the wiki describing how
Firefox currently performs revocation checking on TLS certificates:
https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox
It also includes a brief
On Tue, Feb 19, 2019 at 10:51 AM Ryan Sleevi wrote:
>
>
> On Tue, Feb 19, 2019 at 9:56 PM Wayne Thayer wrote:
>
>> Ryan,
>>
>> On Mon, Feb 18, 2019 at 4:58 PM Ryan Sleevi via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> On Mon, Feb 18, 2019 at 2:49 PM Jakob Bohm
Thank you George, this is indeed interesting. As you and Ryan have noted,
there is a lot of human interaction required, but I would like to find ways
to better automate some of the work involved in managing incident bugs,
especially since there seems to be no end of them in sight.
Meanwhile, I
Thanks Corey and Ben. This issue does appear to have been resolved. I've
created a bug requesting an incident report:
https://bugzilla.mozilla.org/show_bug.cgi?id=1523676
- Wayne
On Sun, Jan 27, 2019 at 5:48 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
Piotr just filed an incident report on the misissuance that was reported on
18-January: https://bugzilla.mozilla.org/show_bug.cgi?id=1523186
The report discloses another misissuance that occurred during testing,
resulting in a serverAuth certificate with a duration of over 5 years.
On Sun, Jan
It was pointed out to me that the OCSP status of the misissued certificate
that is valid for over 5 years is still "unknown" despite having been
revoked a week ago. I asked KIR about this in the bug [1] and am surprised
by their response:
This certificate is revoked on CRL. Because the
Thanks everyone for your input on this topic.
As a result of this discussion, I have concluded that this is not a clear
violation of Mozilla policy. I've closed the DFN bug as INVALID, and I am
planning to propose a ballot to the CAB Forum to clarify this requirement.
- Wayne
On Wed, Jan 30,
On Mon, Feb 4, 2019 at 1:33 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> All,
>
> As you know, CCADB sends audit reminder emails regarding root certs in
> Mozilla's program on the 3rd Tuesday of each month.
>
> We are going to update the date checks
On Tue, Feb 5, 2019 at 4:37 AM Matthias van de Meent via
dev-security-policy wrote:
> On Mon, 4 Feb 2019 at 18:06, Ryan Sleevi wrote:
> >
> > On Mon, Feb 4, 2019 at 10:46 AM Matthias van de Meent via
> dev-security-policy wrote:
> >>
> >> Hi,
> >>
> >> Today we've bought a wildcard certificate
While a certain amount of latency in OCSP updates is expected when a
certificate is first issued or revoked, KIR intended this to be a permanent
"unknown" status for a revoked certificate. My conclusion from this
discussion is that such a policy is not permitted, and the existing
requirements are
The BRs define Repository as:
Repository: An online database containing publicly-disclosed PKI governance
documents (such as Certificate Policies and Certification Practice
Statements) and Certificate status information, either in the form of a CRL
or an OCSP response.
I see no evidence to
It's not clear that there is anything for DigiCert to respond to. Are we
asserting that the existence of this Arabtec certificate is proof that
DigiCert violated section 3.2.1 of their CPS?
- Wayne
On Thu, Apr 11, 2019 at 6:57 PM Jakob Bohm via dev-security-policy <
ivate key, but that was never implemented, slated for a
> phase 2 that never came. We've since disabled that system, although we
> didn't file any incident report (for the reasons discussed so far).
>
> -Original Message-
> From: dev-security-policy
> On Behalf Of
Ryan - Again, thank you for the feedback, and please forgive me for the
delayed response. I've attempted to address your concerns on the wiki page
(since this isn't official policy, I'm editing the live document):
Unless additional feedback is posted, I will include this change as
originally proposed in version 2.7 of our policy.
- Wayne
On Fri, Mar 29, 2019 at 11:23 AM Wayne Thayer wrote:
> On Fri, Mar 29, 2019 at 4:32 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
I will will include this change in policy version 2.7.
- Wayne
On Wed, Mar 27, 2019 at 8:04 PM Ryan Sleevi wrote:
> I'm not sure whether it's necessary to indicate support, but since silence
> can sometimes be ambiguously interpreted: I support these changes and
> believe they achieve the
On Fri, Mar 29, 2019 at 11:59 AM Wayne Thayer wrote:
> On Thu, Mar 28, 2019 at 5:29 PM Ryan Sleevi wrote:
>
>>
>> On Thu, Mar 28, 2019 at 7:42 PM Wayne Thayer wrote:
>>
>>> On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi wrote:
>>>
>>>>
Mozilla has decided that there is sufficient concern [1] about the
activities and operations of the CA Certinomis to collect together a list
of issues. That list can be found here:
https://wiki.mozilla.org/CA/Certinomis_Issues
Note that this list may expand or contract over time as issues are
Yesterday, Andrew Ayer filed a bug [1] identifying 14 pre-certificates
issued by Certinomis in February 2019 containing an unregistered domain
name. Since the cause described in the incident report is similar, I added
this under issue F.1.
On Tue, Apr 16, 2019 at 11:44 AM Wayne Thayer wrote:
>
My conclusion from this discussion is that we should not add an explicit
requirement for EKUs in end-entity certificates. I've closed the issue.
- Wayne
On Tue, Apr 16, 2019 at 9:56 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tue, Apr 16, 2019 at
I went ahead and added this change to the 2.7 branch:
https://github.com/mozilla/pkipolicy/commit/1e7f4edb97c4497e2e04442797ebc670e9d80b44
I removed the phrase "In addition to existing rules placed on the structure
of CPs and CPSes that comply with the CA/Browser Forum Baseline
Requirements"
I would like to thank everyone for your constructive input during this
discussion. Since my post last week suggesting two options for distrusting
the existing Certinomis root, a number of events have occurred, including
the following:
* Certinomis confirmed that they have implemented pre-issuance
On Thu, May 16, 2019 at 4:23 PM Wayne Thayer wrote:
I will soon file a bug requesting removal of the “Certinomis - Root CA”
> from NSS.
>
This is https://bugzilla.mozilla.org/show_bug.cgi?id=1552374
___
dev-security-policy mailing list
Thank you for sharing this information Scott.
On Wed, May 15, 2019 at 2:49 AM Scott Rea wrote:
>
> Please advise if additional information relating to this change is
> required.
>
>
As pointed out in earlier discussions about DarkMatter's QuoVadis-signed
intermediates [1], and the policy 2.7
First off, I would like to remind everyone that participation in this forum
is subject to Mozilla's Community Participation Guidelines [1].
The arguments that have been made for adding an exception to our policy for
Policy CAs have not, in my opinion, made a clear and compelling case for
the
On Mon, Apr 29, 2019 at 7:31 AM Peter Bowen wrote:
> I support this, as long as Policy CAs meet the same operations standards
> and have the same issuance restrictions as root CAs. This would result in
> no real change to policy, as I assume roots not directly included in the
> Mozilla root
Having received no comments on these proposed changes, I plan to include
them in version 2.7 of our policy.
- Wayne
On Fri, Apr 19, 2019 at 11:55 AM Wayne Thayer wrote:
> Ryan Sleevi made the following proposal:
>
> Issue #122 [1] previously discussed Section 8 in the context of
>> subordinate
I have drafted the change as proposed, moving the exact "Required Practice"
language into section 3.3 of the policy:
https://github.com/mozilla/pkipolicy/commit/803ec1a1414318a69491854a867dc69889442b7b
On Sat, Apr 27, 2019 at 11:36 AM Pedro Fuentes via dev-security-policy <
DigiCert CPS section 1.5.2 [1] could also more clearly state that
rev...@digicert.com is the correct address for 'reporting suspected Private
Key Compromise, Certificate misuse, or other types of fraud, compromise,
misuse, inappropriate conduct, or any other matter related to
Certificates.' Since
Thank you for this response Francois. I have added it to the issues list
[1]. Because the response is not structures the same as the issues list, I
did not attempt to associate parts of the response with specific issues. I
added the complete response to the bottom of the page.
On Thu, May 9, 2019
policy, there's no requirement to revoke a
> certificate mis-issued that's non-TLS.
>
> -Original Message-
> From: dev-security-policy
> On Behalf Of Wayne Thayer via dev-security-policy
> Sent: Friday, May 3, 2019 12:44 PM
> To: mozilla-dev-security-policy <
> moz
The BRs forbid delegation of domain and IP address validation to third
parties. However, the BRs don't forbid delegation of email address
validation nor do they apply to S/MIME certificates.
Delegation of email address validation is already addressed by Mozilla's
Forbidden Practices [1] state:
On Sun, May 12, 2019 at 9:59 AM Nemo via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi,
>
> I've been running a public DNSCrypt resolver[0] for the last 2 years,
> and would like to start a DoH resolver as well. I went through the
> DoH-Resolver-Policy page[1] and have
On Mon, May 13, 2019 at 7:06 AM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi Wayne,
> inserting my comments below.
> Best,
> Pedro
>
> El viernes, 10 de mayo de 2019, 23:54:40 (UTC+2), Wayne Thayer escribió:
> > I have drafted the change as proposed,
Thanks for reporting this Alex.
I have created the following bugs to track these issues:
Sectigo: https://bugzilla.mozilla.org/show_bug.cgi?id=1551362
DigiCert: https://bugzilla.mozilla.org/show_bug.cgi?id=1551363
SwissSign: https://bugzilla.mozilla.org/show_bug.cgi?id=1551364
Government of
two cents...
>
> Pedro
>
> El lunes, 13 de mayo de 2019, 19:58:46 (UTC+2), Ryan Sleevi escribió:
> > On Mon, May 13, 2019 at 1:25 PM Wayne Thayer via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > The BRs forbid del
I've gone ahead and made this change in the 2.7 branch:
https://github.com/mozilla/pkipolicy/commit/3a70cf31cf81f5e00b62f958fe8a3b59c7cb0f34
I'll consider this issue resolved unless further comments are received.
- Wayne
On Mon, May 13, 2019 at 11:41 PM Pedro Fuentes via dev-security-policy <
On Tue, May 14, 2019 at 11:21 AM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 5/10/19 5:46 PM, Wayne Thayer wrote:
> > I've attempted to update section 6 to incorporate revocation requirements
> > for S/MIME certificates:
> >
> >
>
On Mon, May 13, 2019 at 9:13 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Though it seems the thread has largely expressed my concerns I do want to
> chime in and stress that I believe that it is important that this text gets
> clarified.
>
>
Does
On Thu, May 9, 2019 at 8:56 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 10/05/2019 02:22, Wayne Thayer wrote:
> > Thank you for this response Francois. I have added it to the issues list
> > [1]. Because the response is not structures the same as the
On Fri, May 10, 2019 at 8:09 AM fchassery--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Dear Wayne,
>
> I’m not arguing that signing the new Startom root was a mistake.In fact,
> as soon as we were told, we backed off.
> Our understanding at that time was that the
On Tue, May 21, 2019 at 12:59 PM Adrian R via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hello
>
> Today, as part of an "upgrade" to version 19.5 Avast Antivirus has
> forcefully enabled the entire Microsoft PKI for all Firefox users that also
> happen to be users of
On Tue, May 21, 2019 at 1:23 PM Adrian R via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Wayne Thayer wrote:
> >
> >
> > That is not my understanding of how this setting works: it only imports
> > roots that have been added to the Windows root store, e.g. by a program
>
On Wed, May 8, 2019 at 10:32 AM Ryan Sleevi wrote:
>
> On Tue, May 7, 2019 at 7:48 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> To continue to participate in the Mozilla CA program, I recommend that we
>> requ
On Wed, May 1, 2019 at 3:25 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 01/05/2019 22:29, mono.r...@gmail.com wrote:
> >> 2017 assessment report
> >> LSTI didn't issue to Certinomis any "audit attestation" for the
> browsers in 2017. The document
The required practice "Publicly Available CP and CPS" [1] states:
The CP/CPS must clearly indicate which root and subordinate certificates
> the practices and processes described in those documents apply to.
This can be done in (at least) two ways:
* the policy document can unambiguously list
On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi wrote:
>
> On Mon, Apr 22, 2019 at 6:20 PM Brian Smith wrote:
>
>> There are three (that I can think of) sources of confusion:
>>
>> 1. Is there any requirement that the signature algorithm that is used to
>> sign a certificate be correlated in any
In version 2.6 of our Root Store Policy, we added the requirement to
section 5.3 that intermediate certificates contain an EKU and separate
serverAuth and emailProtection uses. Version 2.6.1 updated the requirement
to exclude cross certificates [1]. Last month, an issue [2] was filed
requesting
Since I began this discussion, additional recent misissuances by Certinomis
have been discovered and reported. [1] [2] [3] One investigation [1] led us
to suspect that Certinomis had continued to employ BR domain validation
method 3.2.2.4.5 after it was banned [4]. A former Certinomis employee
.
On April 17, 2019 at 2:44:44 AM, Wayne Thayer via dev-security-policy (
> dev-security-policy@lists.mozilla.org) wrote:
>
> Mozilla has decided that there is sufficient concern [1] about the
> activities and operations of the CA Certinomis to collect together a list
> of issues
t.
I will appreciate everyone's feedback on this proposal.
Ryan
> On Wednesday, April 17, 2019 at 12:27:49 PM UTC-7, Brian Smith wrote:
> > Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> > wrote:
> >
> > > My conclusion from
Ryan Sleevi made the following proposal:
Issue #122 [1] previously discussed Section 8 in the context of subordinate
> CAs, with a change [2] being made to include subordinate CAs (in the
> context of Section 5.3.2) within scope of notification requirements.
>
> However, as presently worded, it's
Thank you for the report Alex. The following compliance bugs have been
created:
Sectigo: https://bugzilla.mozilla.org/show_bug.cgi?id=1548713
SECOM: https://bugzilla.mozilla.org/show_bug.cgi?id=1548714
DigiCert: https://bugzilla.mozilla.org/show_bug.cgi?id=1548716
- Wayne
On Thu, May 2, 2019 at
On Fri, May 3, 2019 at 8:36 AM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I'm against having to continually update the exact URL of the CP and CPS
> in the CCADB.
A relatively simple solution to this problem is to create a "permanent
link" to the
Kathleen and Pedro,
Thank you for raising these legitimate concerns. I continue to believe that
a literal reading of the current requirement is that it already does apply
to S/MIME certificates, and the discussion I mentioned supports that
interpretation.
I propose two new options to solve this
On Fri, Apr 26, 2019 at 5:14 PM Wayne Thayer wrote:
> Section 6 ("Revocation") of Mozilla's Root Store Policy states:
>
> CAs MUST revoke Certificates that they have issued upon the occurrence of
>> any event listed in the appropriate subsection of section 4.9.1 of the
>> Baseline Requirements,
Based on this discussion, I propose adding the following statement to the
Mozilla Forbidden Practices wiki page [1]:
** Logotype Extension **
Due to the risk of misleading Relying Parties and the lack of defined
validation standards for information contained in this field, as discussed
here [2],
Russ,
On Wed, Jul 10, 2019 at 11:41 AM housley--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Friday, July 5, 2019 at 7:53:45 PM UTC-4, Wayne Thayer wrote:
> > Based on this discussion, I propose adding the following statement to the
> > Mozilla Forbidden
On Wed, Jul 10, 2019 at 2:31 PM Phillip Hallam-Baker
wrote:
> On Wed, Jul 10, 2019 at 4:54 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Russ,
>>
>> >
>> Perhaps one of us is confused because I think we're
On Wed, Jul 10, 2019 at 7:26 PM Phillip Hallam-Baker
wrote:
>
> On Wed, Jul 10, 2019 at 6:11 PM Wayne Thayer wrote:
>
>> On Wed, Jul 10, 2019 at 2:31 PM Phillip Hallam-Baker <
>> ph...@hallambaker.com> wrote:
>>
>>> On Wed, Jul 10, 2019 at 4:54 PM Wayn
I would like to thank everyone for their constructive input on this
difficult issue. I would also like to thank DarkMatter representatives for
participating in the open, public discussion. I feel that the discussion
has now, after more than 4 months, run its course.
The question that I originally
I'm either confused, or I disagree. We're talking about a certificate that
deviates from a "SHOULD" in RFC 5280, correct? Our guidance on incidents
[1] defines misissuance, in part, as "RFC non-compliant". The certificate
as described strictly complies with RFC 5280 (and presumably all other
from Certinomis
to issue F.3: Inadequate Controls on Production Testing
On Thu, Apr 25, 2019 at 9:30 AM Ryan Sleevi wrote:
>
> On Wed, Apr 17, 2019 at 5:22 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Yesterday, An
On Fri, Apr 19, 2019 at 7:12 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Fri, Apr 19, 2019 at 01:22:59PM -0700, Wayne Thayer via
> dev-security-policy wrote:
> > Okay, then I propose adding the following to section 5.2 "For
On Tue, Apr 16, 2019 at 12:02 PM Wayne Thayer wrote:
>
> I've drafted a specific proposal for everyone's consideration:
>
>
> https://github.com/mozilla/pkipolicy/commit/5f1b0961fa66f824adca67d7021cd9c9c62a88fb
>
>
Having received no new comments on this proposal, I'll consider this issue
closed
401 - 500 of 604 matches
Mail list logo
