For everyone's reference, here is a link to the old thread:
https://groups.google.com/d/msg/mozilla.dev.security.policy/wnuKAhACo3E/ujxPTWTlCQAJ
To be clear, the Kazakhstan government CA's root inclusion request
referenced in that thread was denied:
It seems to me that this discussion has veered away from the original
question, which was seeking consent to "experiment" with logotypes in
publicly-trusted certificates. I don't think there is much doubt that RFC
3709 has been and can be implemented, and as pointed out, it can be tested
in
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
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
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
The bug requesting that the existing subordinate CAs be added to OneCRL is
https://bugzilla.mozilla.org/show_bug.cgi?id=1564544
On Tue, Jul 9, 2019 at 8:31 AM Wayne Thayer wrote:
> I would like to thank everyone for their constructive input on this
> difficult issue. I would also like to thank
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
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],
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 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 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
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
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
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
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 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
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
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,
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:
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
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
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 <
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
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 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 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
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
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
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 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
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, 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,
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
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
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
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
Having received no new comments, I'll plan to include this change in policy
version 2.7.
- Wayne
On Tue, Apr 16, 2019 at 3:40 PM Wayne Thayer wrote:
> I went ahead and added this change to the 2.7 branch:
> https://github.com/mozilla/pkipolicy/commit/1e7f4edb97c4497e2e04442797ebc670e9d80b44
>
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
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
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
.
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
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:
>
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"
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
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
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
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):
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
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 <
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
On Wed, Apr 3, 2019 at 6:30 PM Brian Smith wrote:
> Wayne Thayer wrote:
>
>> On Mon, Apr 1, 2019 at 5:36 PM Brian Smith via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> Here when you say "require EKUs," you mean that you are proposing that
>>> software that uses
On Thu, Apr 4, 2019 at 1:50 PM Brian Smith wrote:
> Ryan Sleevi wrote:
>
>> Given that CAs have struggled with the relevant encodings, both for the
>> signatureAlgorithm and the subjectPublicKeyInfo field, I’m curious if
>> you’d
>> be open to instead enumerating the allowed (canonical)
On Thu, Apr 4, 2019 at 7:57 AM CERT Coordination Center
wrote:
> Thanks Rob!
>
> Actually, as I look at one of these cases:
>
> https://crt.sh/?spkisha256=8628d8106b72c39d98e8e731fc3b9364940efea0dfbb4816b1382542a979c834
>
> The latest certificate using the above key expires in just a few days.
>
A number of ECC certificates that fail to meet the requirements of policy
section 5.1 were recently reported [1]. There was a lack of awareness that
Mozilla policy is more strict than the BRs in this regard. I've attempted
to address that by adding this to the list of "known places where this
Brian,
I think we are in agreement that this isn't a desirable addition to our
policy.
On Mon, Apr 1, 2019 at 5:36 PM Brian Smith via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozil
In October we discussed the use of "No Stipulation", empty sections, and
blank sections in CP/CPSes. [1] The result was an update to the "Required
Practices" wiki page. [2] I propose moving this into policy by adding the
following paragraph to the bottom of section 3.3 "CPs and CPSes"
In addition
Pedro,
Thank you for reporting this issue.
On Tue, Mar 19, 2019 at 2:10 AM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> In light of the recent discussion related to serial number Entropy, at
> WISeKey we could verify that we were also affected by this
The BRs require EKUs in leaf TLS certs, but there is no equivalent
requirement for S/MIME certificates. This leads to confusion such as [1] in
which certificates that are not intended for TLS or S/MIME fall within the
scope of our policies.
Simply requiring EKUs in S/MIME certificates won't solve
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:
>>
>>> On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy <
>>> de
On Fri, Mar 29, 2019 at 4:32 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 28/03/2019 21:52, Wayne Thayer wrote:
> > Our current Root Store policy assigns two different meanings to the term
> > "technically constrained":
> > * in sections 1.1 and 3.1,
On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi wrote:
>
> On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> We currently expect CAs to deliver incident reports whenever they fail to
&
he context of TLS certificates. Does that help?
On Thu, Mar 28, 2019 at 4:00 PM Ryan Sleevi wrote:
>
>
> On Thu, Mar 28, 2019 at 4:53 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Our current Root Store policy assig
We currently expect CAs to deliver incident reports whenever they fail to
comply with our policy, but this is not a requirement of our policy. There
is no obvious place to add this in the existing policy, so I propose
creating a new top-level section that reads as follows:
**Incidents**
> When a
Our current Root Store policy assigns two different meanings to the term
"technically constrained":
* in sections 1.1 and 3.1, it means 'limited by EKU'
* in section 5.3 it means 'limited by EKU and name constraints'
The BRs already define a "Technically Constrained Subordinate CA
Certificate"
I'd like to remind CAs of Mozilla's disclosure requirement for
unconstrained intermediate CA certificates:
The CA with a certificate included in Mozilla’s root program MUST disclose
> this information within a week of certificate creation, and before any such
> subordinate CA is allowed to issue
I'm [hopefully] beginning with a simple change that clarifies the language
used for Point-in-Time (PiT) audits used in policy. Section 3.1.3 of our
policy currently references a "point-in-time assessment", and section 8
uses the undefined abbreviation "PITRA", which stands for "point-in-time
I've added a few more issues that were recently created to the list for
2.7: https://github.com/mozilla/pkipolicy/labels/2.7
176 - Clarify revocation requirements for S/MIME certs
175 - Forbidden Practices wiki page says email validation cannot be
delegated to 3rd parties
I plan to begin posting
Doug: You'll need to connect directly to the certwatch database using a
tool like psql:
psql -h crt.sh -p 5432 -U guest certwatch
Here's Rob's announcement of direct database access:
https://crt.sh/forum?place=msg%2Fcrtsh%2FsUmV0mBz8bQ%2FK-6Vymd_AAAJ
On Tue, Mar 26, 2019 at 11:34 AM Doug Beattie
Melis: Thank you for this incident report. I have filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1539190 and assigned it to you
to track this issue.
Will you please have one of your colleagues add you as a Kamu SM contact in
CCADB? That will allow me to confirm that you are representing Kamu
Thank you for the report Will and for the tracking info Rob.
It appears that all but one of these certificates is currently revoked, but
roughly 5 more weren't revoked until earlier today, which I assume was more
than 24 hours since they were reported to the CA.
Will: can you share an
My general sense is that we should be doing more to discourage the use of
SHA-1 rather than less. I've just filed an issue [1] to consider a ban on
SHA-1 S/MIME certificates in the future.
On Mon, Mar 25, 2019 at 10:54 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org>
I agree with Ryan on this. From a policy perspective, we should be
encouraging [and eventually requiring] EKU constraints, not making it
easier to exclude them.
On Mon, Mar 25, 2019 at 1:03 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> While it may be
On Fri, Mar 22, 2019 at 6:54 PM Peter Bowen wrote:
>
>
> On Fri, Mar 22, 2019 at 11:51 AM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> I've been asked if the section 5.1.1 restrictions on SHA-1 issuance apply
>>
t 4:00 PM Andrew Ayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Fri, 22 Mar 2019 12:50:43 -0600
>> Wayne Thayer via dev-security-policy
>> wrote:
>>
>> > I've been asked if the section 5.1.1 restrictions on SHA-1 issuan
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
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
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
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
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
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
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 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
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.
>
>
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
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 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
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
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
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
101 - 200 of 604 matches
Mail list logo
