On Fri, Jan 19, 2018 at 1:58 PM, Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Given this discussion, there must be no other CAs using method 9 or 10,
> else they would have come forward by now with disclosures and have
> demonstrated their compliance..
-public.secure.force.com/mozillacommunications/
CACommResponsesOnlyReport?CommunicationId=a051J3mogw7&QuestionId=
Q00042,Q00048
On Tue, Jan 16, 2018 at 2:05 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> To recap, we've established that th
On Sun, Jan 21, 2018 at 2:14 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> > I think the whole CA incident reporting question has lots of room for
> > improvement. And I think this should be considered in a way that people
> > who are not familiar with
On Sat, Jan 20, 2018 at 1:07 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> > Based on this, do we need a ballot to remove them from the BRs, or put in
> > a statement in them to the effect that they can be used only if approved
> by
> > Google on this
Hi Everyone,
I have reviewed the responses we received from the November 2017 CA
Communication [1], and I have the following comments to share:
* Beginning with the good news, no new concerns related to the suspected
.tg Registry compromise were reported (Action #8)
* The deadline for submitting
In the past, new policy versions have not had a clearly defined future
effective date. That seems to have led some CAs to interpret the timing for
making changes to be "whenever we get around to it" instead of the intent
of "the policy is effective immediately and we expect you to comply with it
as
On Wed, Jan 24, 2018 at 9:54 AM, Gervase Markham wrote:
> We do actually do that, it's just not written in the policy itself. See:
> https://wiki.mozilla.org/CA/Root_Store_Policy_Archive
> which gives all the publication dates and compliance dates.
>
> Good. Then all I'm suggesting is that we add
I want to directly notify all CAs in the Mozilla program of the recently
exposed issues with domain validation methods and of some upcoming
deadlines. A draft is available below and at
https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication
I would appreciate your prompt and const
On Wed, Jan 24, 2018 at 6:56 AM, Ryan Sleevi wrote:
> This seems to be a perennial problem with CAs, and doesn't inspire
> confidence in them or their operations. I am also concerned that an
> extension of this nature does not inspire confidence in the Mozilla Root
> Program, either as relying pa
To the best of my knowledge, the only "standard" sanction we have today is
complete distrust of a root or intermediate, and in practice that rarely
happens. On the surface, the idea of lesser sanctions like removing the EV
indicator for some period of time is appealing to me, but I think we need
to
On Wed, Jan 24, 2018 at 1:50 PM, Jonathan Rudenberg
wrote:
>
> > On Jan 24, 2018, at 15:20, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > 2. On 19-December, significant concerns were raised about the reliabilit
On Wed, Jan 24, 2018 at 4:05 PM, Ryan Sleevi wrote:
>
>
> On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>>
>> > Is there a reason to make this deprecation conditional on the ballot?
>
4:05 PM, Ryan Sleevi wrote:
>
>>
>>
>> On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>> > Is there a reason to make this deprecation conditional on the ballot?
&g
On Thu, Jan 25, 2018 at 11:48 AM, Jonathan Rudenberg
wrote:
> This is a great improvement. I think we should also ask that any CAs using
> these methods immediate disclose that they are and the procedures they are
> using, as well as the date they expect to complete a review of their
> implementa
Based on the feedback we've received, but sticking with the original intent
of this communication, I have converted it into a survey. You can find a
draft at:
https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication
I would appreciate your comments on this. I have set the deadline
Thanks Jakob. I updated the draft as described below.
On Fri, Jan 26, 2018 at 10:42 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I think a number of the questions/actions need additional options:
>
> For ACTION 1:
>
> (These 3 are between the 1st and
Yair,
Will you please provide a detailed response to each of Ryan's points? Also,
please provide the specific version of the RSA Certificate Manager in use
by ComSign.
Thanks,
Wayne
On Mon, Jan 29, 2018 at 8:43 AM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
Thanks for pointing this out Ryan and Dimitris. You are both correct: we
should direct Taiwan GRCA to change their request from including the root
to including only the subordinate CAs that comply with the Mozilla policy.
The option of adding the non-compliant subordinate CAs to OneCRL does not
mee
You can find a link to the final version of the survey at
https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication
We're planning to send this out to all CAs in the Mozilla program later
today. The deadline for responses has been set to 9-February.
Thanks to everyone who contribut
The email has been sent, and we've published a blog post:
https://blog.mozilla.org/security/2018/01/29/january-2018-ca-communication/
On Monday, January 29, 2018 at 1:15:51 PM UTC-7, Wayne Thayer wrote:
> You can find a link to the final version of the survey at
> https://wiki.mozilla.org/CA/Comm
On Fri, Jan 19, 2018 at 3:04 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 18/01/18 14:24, Ryan Sleevi wrote:
> > Isn't this effectively the VISA situation? When were their first audits -
> > late 2016 / early 2017?
>
> I'm not certain; I'll ask K
I would like to thank everyone for your constructive input on this topic.
At the outset I stated a desire to ‘establish some objective criteria that
can be measured and applied fairly’. While some suggestions have been made,
no clear set of criteria has emerged. At the same time, we’ve heard the
ar
I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1435770
requesting an incident report from Certum.
On Mon, Feb 5, 2018 at 10:07 AM, Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> WoSign and StartCom are untrusted, but Certum is still trusted, right?
Gerv and I have made, and the CA/Browser Forum has accepted a proposal to
convene a "Validation Summit" on Tuesday March 6th during the next
regularly scheduled CA/Browser Forum face-to-face meeting that will be held
in the Washington DC area.
The intent of this summit is to perform an analysis of
On Mon, Feb 5, 2018 at 4:33 PM, Alex Cohn via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I logged two of those five certificates (https://crt.sh/?id=308392091
> and https://crt.sh/?id=307753186) to Argon, as part of a project to
> log every certificate in the censys.io d
Yair,
> Re Section 3.4, you seem to assume the domain holder is a ComSign
> > subscriber. In case of misissuance, that may not be true.
> >>> I understand, for that we added on the CPS on section 3.4 the
> following:
> "For the handling of revocation requests by other than the Subscriber or
> his
On Tue, Feb 6, 2018 at 6:03 PM, Paul Kehrer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> So, how long is too long?
>
This is the crux of the issue for me. If a CA (that really should have
stopped responding 'good' for unknown certs back in 2013) needs to select,
pur
On Thu, Feb 8, 2018 at 8:54 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 08/02/18 15:50, Gervase Markham via dev-security-policy wrote:
>
>> On 08/02/18 13:47, Hanno Böck wrote:
>>
>> OneCRL additions normally have an associated bug but I can't see
On Wed, Feb 7, 2018 at 8:18 AM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi Wyane,
> resopnding to your notes:
>
> Section 4.9 states that in any case that Comsign is notified about a
> misissuance (no matter if it was notified by a subscriber or in any other
On Thu, Feb 8, 2018 at 7:26 AM, Kai Engert via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 16.10.2017 19:32, Gervase Markham via dev-security-policy wrote:
> > The subCAs that we know of that fall into this category belong to Google
> > and Apple. If there are any othe
-Tugra
I will allow a grace period of a few days and then will open incident bugs
for those CAs that still haven't responded.
- Wayne
On Mon, Jan 29, 2018 at 5:14 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> The email has been sent, and we&
All of my questions regarding the CP/CPS and audits have been answered to
my satisfaction. I am left with two concerns:
1. This root was signed on 12-March 2013. The first end-entity certificate
that I'm aware of was signed later in 2013. Mozilla began requiring BR
audits in 2014, but the first BR
Hi Yair,
On Mon, Feb 12, 2018 at 11:50 AM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi Wayne,
> Please realize our situation versus the Israeli market. We are the major
> certificate authority and we comply with every piece of local regulation,
> we are also
On Tue, Feb 13, 2018 at 10:49 AM, Jonathan Rudenberg
wrote:
>
> > On Sep 19, 2017, at 11:12, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > In the light of this, I believe it is reasonable to discuss the question
> > of whether Visa's PKI (and, s
On Tue, Feb 13, 2018 at 11:26 PM, Paul Kehrer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On February 14, 2018 at 4:17:16 AM, Wayne Thayer via dev-security-policy (
> dev-security-policy@lists.mozilla.org) wrote:
>
> > The most recent BR audi
On Wed, Feb 14, 2018 at 10:47 AM, Tim Smith via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Wednesday, February 14, 2018 at 8:43:19 AM UTC-8, Wayne Thayer wrote:
> > In this particular case, my conclusion is that the existing Mozilla
> > process is working. We have doc
I have begun work on version 2.6 of the Root Store Policy by drafting some
changes that are [I hope] uncontroversial. The diff can be viewed at
https://github.com/mozilla/pkipolicy/compare/2.6
The changes I have already drafted are:
- Require disclosure of email validation practices in CPS (Issue
I've opened bugs for the following CAs that still haven't responded:
- GoDaddy
- Certinomis / Docapost
- Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)
- TurkTrust
- E-Tugra
You can find these bugs on the Incident Dashboard:
https://wiki.mozilla.org/CA/Incident_Dashboard
-
Based on this discussion, Mozilla is denying the ComSign Global Root CA
inclusion request. I'd like to thank everyone for your constructive input
into the discussion, and I'd like to thank ComSign for their patience and
work to address issues as they have been discovered.
ComSign may submit a new
Ryan,
On Fri, Feb 16, 2018 at 3:19 PM, Ryan Sleevi wrote:
>
> Hi Wayne,
>
> One point of possible clarification that should be undertaken is with
> respect to https://github.com/mozilla/pkipolicy/blob/master/rootstor
> e/policy.md#8-ca-operational-changes
>
> While this section is worded around
I've added the issue of subordinate CA transfers to the list for policy
version 2.6: https://github.com/mozilla/pkipolicy/issues/122
On Tue, Feb 20, 2018 at 4:50 PM, Ryan Sleevi wrote:
>
>
> On Tue, Feb 20, 2018 at 6:19 PM, Wayne Thayer wrote:
>
>> Ryan,
>>
>> On Fri, Feb 16, 2018 at 3:19 PM, R
The TunrootCA2 root operates under the following CPS:
http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf
The TunserverCA2 subordinate CA operates under a different CPS:
http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf
I have reviewed the supplied BR Se
The test site for the root referenced in bug 1172819 is working fine in
Firefox: https://gbvalidssl.hightrusted.com/
I am not able to locate any gov.sc websites properly configured for HTTPS
to test.
- Wayne
On Sat, Feb 24, 2018 at 3:45 AM, westmail24--- via dev-security-policy <
dev-security-po
The article also claims that bad actors are selling EV SSL certificates
that they obtain for real companies without their knowledge:
"to guarantee the issuance and lifespan of the products, all certificates
are registered using the information of real corporations. With a high
degree of confidence
On Mon, Feb 26, 2018 at 12:23 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 26/02/2018 10:27, Kurt Roeckx wrote:
>
>> I just came across this:
>>
>> https://www.recordedfuture.com/code-signing-certificates/
>>
>> I think the most important part of it i
If you have the letters from your auditor, you can upload them as an
attachment to a Bugzilla bug, then submit the links in your CCADB audit
case. It's preferable to be able to verify the audit letters via the seal
on the WebTrust site, but Mozilla doesn't require it - we can contact the
auditor di
I am seeking input on this proposal:
Work is underway to allow Firefox add-ons to read certificate information
via WebExtensions APIs [1]. It has also been proposed [2] that the
WebExtensions APIs in Firefox be enhanced to allow a 3rd party add-on to
change or ignore the normal results of certific
This request has been in public discussion for more than 6 months, so I
would like to make a decision soon. If you have comments or concerns with
this request, please post them here by 6-March 2018.
On Tue, Feb 27, 2018 at 7:33 AM, Olfa Kaddachi via dev-security-policy <
dev-security-policy@lists.
On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg
wrote:
>
> > On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> >
> >> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-
To conclude this discussion, Mozilla is denying the Japanese Government
ApplicationCA2 Root inclusion request. I'd like to thank everyone for your
constructive input into the discussion, and I'd like to thank the Japanese
Government representatives for their patience and work to address issues as
On Tue, Feb 27, 2018 at 3:40 PM, Peter Saint-Andre via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 2/27/18 3:26 PM, Hanno Böck via dev-security-policy wrote:
> > Hi,
> >
> > On Tue, 27 Feb 2018 09:20:33 -0700
> > Wayne Thayer v
On Wed, Feb 28, 2018 at 9:13 AM, Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Wed, Feb 28, 2018 at 12:58 AM, apca2.2013--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > "I would like to again point out that simply waiting
On Wed, Feb 28, 2018 at 12:13 PM, timx84039--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Regarding to our investigation they were only able to send the private
> keys for those certificates where the CSR / private key pair were generated
> within their online priv
Here is the report Ben filed in the bug. He tried to send it to the list
but for some reason it was rejected as spam.
Dear Mozilla Community,
As part of our efforts to meet the April 15 requirements imposed by the
Mozilla Root Store Policy v.2.5, DigiCert has been reviewing CA
On Thu, Mar 1, 2018 at 8:17 AM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Is it practical to remove the Symantec root certificates and (temporarily)
> add the Google and Apple intermediates to the trust store? This should
> facilitate removing trust in S
Thanks everyone for your input on this topic. The consensus seems to be
that allowing WebExtensions to muck with certificate validation decisions
is a bad idea. The bug [1] has been updated with that sentiment and a link
to this discussion.
- Wayne
[1] https://bugzilla.mozilla.org/show_bug.cgi?id
Update:
Mozilla is moving forward with our implementation of the consensus plan for
Symantec roots [1]. With the exception of whitelisted subordinate CAs using
the keys listed on the wiki [2], Symantec certificates are now blocked by
default on Nightly builds of Firefox. The preference
"security.p
On Fri, Mar 2, 2018 at 11:58 AM, Doug Beattie
wrote:
> Hi Wayne,
>
> Is the Firefox 60 update in May the same as the combination of the April
> and October Chrome updates, in that all Symantec certificates will be
> untrusted on this date (5 months before Chrome)?
>
> Sorry for not making that cl
This request is for inclusion of the Camerfirma CHAMBERS OF COMMERCE ROOT -
2016 (CCR2016) and GLOBAL CHAMBERSIGN ROOT - 2016 (GCSR2016) as documented
in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=986854
* BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi
On Fri, Mar 2, 2018 at 3:47 PM, David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 3/2/2018 2:05 PM, Wayne Thayer wrote [in part]:
>
> [snipped]
>
> NOTE: The fact that I have snipped some of the items under "==Bad=="
> does not mean I consider them
On Tue, Mar 6, 2018 at 4:45 AM, ramirommunoz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> 1 * The inclusion request references a much older CPS [3] that doesn't
> list the 2016 versions of these roots or comply with current policies. I
> only reviewed the newer CP
This incident, and the resulting action to "integrate GlobalSign's certlint
and/or zlint into our existing cert-checker pipeline" has been documented
in bug 1446080 [1]
This is further proof that pre-issuance TBS certificate linting (either by
incorporating existing tools or using a comprehensive
On Thu, Mar 15, 2018 at 12:22 PM, Tom via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Should another bug be opened for the certificate issued by IdenTrust with
> apparently the same encoding problem?
>
> Yes - this is bug 1446121 (
https://bugzilla.mozilla.org/show_bug.cg
I think this discussion has made it clear that the request for inclusion of
the TunRootCA2 root should be denied.
CAs inherently must be trusted, and trust must be earned. A CA can't simply
fix one problem after another as we find them during the inclusion process
and expect to be rewarded for the
TURKTRUST has the "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5"
root included in the Mozilla program with the 'websites' trust bit enabled
(not EV). Crt.sh identifies one unexpired and unrevoked subordinate CA [1],
and 13 unexpired end-entity certificates signed by this root [2]. The
audit
There are 17 proposed changes in total for version 2.6 of the policy, and
I'm about to kick off discussions on the first batch. I expect some of
these to be straightforward while others will hopefully generate good
dialogues. As always, everyone's constructive input is appreciated.
Thanks,
Wayne
This new version of the policy won’t be completed until after 15-April,
which is the revised deadline for disclosure and auditing of unconstrained
email subordinates. I propose removal of the following exception from
section 5.3.1:
Instead of complying with the above paragraph, intermediate certif
A few months ago, we discussed our root inclusion criteria [1], and came to
a conclusion that I summarized and proposed in policy as follows:
I would like to thank everyone for your constructive input on this topic.
> At the outset I stated a desire to ‘establish some objective criteria that
> can
Historically, the effective dates of new versions of the policy have been
maintained separately from the policy itself [1]. In our November
Communication, we learned that many CAs weren’t in compliance with policy
version 2.5 despite it having been in effect since June [2]. This proposal
is simply
Section 2.2(3) defines very specific requirements for use of the BR 3.2.2.4
domain validation methods. Now that 3.2.2.4.11 (“any other method”) has
been removed from the BRs and ballot 218 [1] has passed, the Mozilla policy
is out-of-date. I propose the following changes:
* Remove the reference to
Jakob,
On Mon, Mar 19, 2018 at 9:48 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 17/03/2018 01:23, Wayne Thayer wrote:
>
> Note, that if it is reasonably certain/validated that the only activity
> is maintaining CRLs/OCSP for the remaining unexpired
Tim,
On Tue, Mar 20, 2018 at 9:57 AM, Tim Hollebeek
wrote:
>
> > * Add a new bullet on IP Address validation that forbids the use of BR
> > 3.2.2.5(4) (“any other method”) and requires disclosure of IP Address
> > validation processes in the CA’s CP/CPS.
>
> This is a bit premature. Most CA's I
On Tue, Mar 20, 2018 at 8:22 AM, Ryan Sleevi wrote:
>
> So, one aspect of this is the recently discussed risk - that is, a CA that
> provides value for only 10 users presents a substantial amount of risk to
> all Mozilla users, for both compromise and non-compliance. This is,
> admittedly, a subj
On Tue, Mar 20, 2018 at 8:19 AM, Ryan Sleevi wrote:
>
> Looking through [1], it seems like the Compliance Date has only differed
> from the Publication Date once (with 2.0).
>
It's not clear to me that the 2.5 failure to adoption was related to
> ambiguity around compliance dates versus, say, CAs
On Tue, Mar 20, 2018 at 12:56 PM, Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I think it's not going to be productive to spend a lot of time on the list
> debating whether or not a CA can opt out of full BR compliance by simply
> saying "we're winding down
On Tue, Mar 20, 2018 at 2:46 PM, Ryan Sleevi wrote:
>
>
> On Tue, Mar 20, 2018 at 4:15 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Tue, Mar 20, 2018 at 8:19 AM, Ryan Sleevi wrote:
>>
>> >
&
On Wed, Mar 21, 2018 at 2:43 AM, Ryan Sleevi wrote:
>
>
> On Tue, Mar 20, 2018 at 8:27 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>>
>>
>> > I am specifically thinking of CP/CPS updates, which were a major
Jeremy filed the following incident report at
https://bugzilla.mozilla.org/show_bug.cgi?id=1447192 :
1. How your CA first became aware of the problem (e.g. via a problem
report submitted to your Problem Reporting Mechanism, via a discussion
in mozilla.dev.security.policy, or via a Bugzilla bug), a
Thank you for the response Jochem. I am glad to hear that Logius has
evaluated the risk and, given the passage of ballot 218, is moving to other
methods of domain validation.
- Wayne
On Fri, Mar 16, 2018 at 5:55 AM, Berge, J. van den (Jochem) - Logius via
dev-security-policy wrote:
> Dear MSDP
Hearing no objections, I've added this change to the 2.6 branch:
https://github.com/mozilla/pkipolicy/commit/5490d165f0d9b55cb75e5851303a21f9a250e199
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/l
> On Tue, Mar 20, 2018 at 2:45 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Tue, Mar 20, 2018 at 8:22 AM, Ryan Sleevi wrote:
>>
>> >
>> > So, one aspect of this is the recently discussed risk - that is,
security-policy@lists.mozilla.org> wrote:
> On 21/03/2018 10:43, Ryan Sleevi wrote:
>
>> On Tue, Mar 20, 2018 at 8:27 PM, Wayne Thayer via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>>
>>> I think it's reasonable
Recently I've received a few questions about audit requirements for
subordinate CAs newly issued from roots in our program. Mozilla policy
section 5.3.2 requires these to be disclosed "within a week of certificate
creation, and before any such subCA is allowed to issue certificates.", but
says noth
Given that TURKTRUST has stated that the "TÜRKTRUST Elektronik Sertifika
Hizmet Sağlayıcısı H5" root is no longer being audited or complying with
new policies, I believe there is consensus that it should be removed from
the Mozilla root store. Kathleen will file a bug for that action.
Ryan suggest
I've drafted these changes:
https://github.com/mozilla/pkipolicy/commit/e5269ff0d6ced93a6c6af65947712b8e4b2e18b8
On Tue, Mar 20, 2018 at 9:57 AM, Tim Hollebeek
wrote:
>
> > * Add a new bullet on IP Address validation that forbids the use of BR
> > 3.2.2.5(4) (“any other method”) and requires dis
Apologies. By choosing to use the term TSP when referring to an
organization operating a PKI, I thought I had made my meaning clear. I now
realize I inferred "certificate" when I used the term "subordinate CA". I
meant "subordinate CA certificate" in all cases where I wrote "subordinate
CA" or "sub
2018 at 6:18 PM, Peter Bowen wrote:
> On Fri, Mar 23, 2018 at 11:34 AM, Wayne Thayer via dev-security-policy
> wrote:
> > Recently I've received a few questions about audit requirements for
> > subordinate CAs newly issued from roots in our program. Mozilla policy
> &g
Mozilla policy section 2.2(2) requires validation of email addresses for
S/MIME certificates, but doesn't require disclosure of these practices as
it does for TLS certificates.
I propose adding the following language from 2.2 (3) (TLS) to 2.2(2)
(S/MIME):
The CA's CP/CPS must clearly specify the
Mozilla began requiring BR audits for roots in our program in 2013 [1], but
we have a vague policy statement in section 3.1 regarding audit
requirements prior to inclusion:
Before being included and periodically thereafter, CAs MUST obtain certain
> audits…
>
BR section 8.1 contains the following
When the Francisco Partners acquisition of Comodo was announced, it was
pointed out [1] that a strict reading of the current policy section 8.1
would have forced Comodo to stop issuing certificates for some period of
time:
If the receiving or acquiring company is new to the Mozilla root program,
>
Mozilla policy section 3.1.2.2 states:
ETSI TS 102 042 and TS 101 456 audits are only acceptable for audit periods
> ending in July 2017 or earlier.
>
Now that we are past this deadline, I propose that we remove all references
to ETSI TS 102 042 and 101 456 from the policy.
This is: https://gith
There has been a lot of confusion about the transition to the new
standards, and I believe that this change makes it clearer that Mozilla no
longer accepts audits based on the older ETSI standards.
On Tue, Mar 27, 2018 at 4:28 AM, Julian Inza via dev-security-policy <
dev-security-policy@lists.moz
Hi Ramiro,
On Fri, Mar 23, 2018 at 11:52 AM, ramirommunoz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi Ryan
>
> Thanks again for your remarks.
> In the end I am going to learn something of PKI :-).
> Surely I do not get a full understanding of you solution, but
Thank you for sharing this information.
On Mon, Mar 26, 2018 at 9:24 AM, juanangel.martingomez--- via
dev-security-policy wrote:
>
>
> We've done an automated analysis on 2018-03-13 of TSL/SSL certificates
> that have been issued by our CAs:
> - Camerfirma Corporate Server II - 2015
> - Camerfir
Thanks everyone for your input on this topic. I'm hearing consensus that we
should not require a newly issued subordinate CA certificate to appear on
an audit statement prior to being used to sign end-entity certificates.
This is something that could be clarified in our policy with a statement
such
On Thu, Mar 29, 2018 at 8:53 AM, Ryan Sleevi wrote:
>
> On Mon, Mar 26, 2018 at 3:46 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> When the Francisco Partners acquisition of Comodo was announced, it was
>> pointed ou
On Thu, Mar 29, 2018 at 8:57 AM, Ryan Sleevi wrote:
>
> I'm not fully sure I understand the proposal here.
>
> I would think that, for all roots created since 2012, the expectation
>
is that there is an unbroken series of audits, going from a Point in Time
> audit (of the policies and infrastruct
On Wed, Mar 28, 2018 at 3:45 AM, ramirommunoz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> On Tuesday, March 27, 2018 at 10:37:07 PM UTC+2, Wayne Thayer wrote:
> > Hi Ramiro,
> >
> > On Fri, Mar 23, 2018 at 11:52 AM, ramirommunoz--- via
> dev-security-policy <
> >
On Thu, Mar 29, 2018 at 2:12 PM, Ryan Sleevi wrote:
>
>
> On Thu, Mar 29, 2018 at 4:03 PM, Wayne Thayer wrote:
>
>> On Thu, Mar 29, 2018 at 8:53 AM, Ryan Sleevi wrote:
>>
>>>
>>> On Mon, Mar 26, 2018 at 3:46 PM, Wayne Thayer via dev-security-policy &
Tim,
On Fri, Mar 30, 2018 at 7:00 AM, crawfordtimj--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thursday, March 29, 2018 at 2:56:17 PM UTC-5, Ryan Sleevi wrote:
> > On Thu, Mar 29, 2018 at 2:46 PM, Wayne Thayer via dev-security-policy <
>
101 - 200 of 624 matches
Mail list logo
