On 10/15/13 3:00 AM, Rob Stradling wrote:
The Izenpe Root has 2 EV OIDs, but this one is missing:
1.3.6.1.4.1.14777.6.1.2
The ValiCert Class 2 Policy Validation Authority Root has 2 EV OIDs,
but this one is missing:
2.16.840.1.114414.1.7.23.3
I didn't think it was important to included the
All,
I need to update
https://wiki.mozilla.org/CA:SubordinateCA_checklist
to reflect the current policy (technically constrain or disclose/audit).
I propose the following changes.
1) Remove the Terminology section. Given the current policy, the terms
In-House, Third-Party, Private, Public do
On 10/23/13 12:31 PM, Kathleen Wilson wrote:
On 10/22/13 1:19 PM, Eddy Nigg wrote:
I've been on the sidelines for most of this and other discussions here,
however I don't think this is correct at all - if the server doesn't
provide a correct stapled response, the browser must still be able
On 10/30/13 3:35 AM, martin.kra...@atos.net wrote:
We will update the affected section in version 1.7 of our CPS to:
77 [SSL-CA]: A legal entity, represented by a device or system, which requests
a certificate is identified and authenticated for the first time via the
subject of the
On 10/30/13 1:37 PM, Kathleen Wilson wrote:
On 10/30/13 3:35 AM, martin.kra...@atos.net wrote:
We will update the affected section in version 1.7 of our CPS to:
77 [SSL-CA]: A legal entity, represented by a device or system, which
requests a certificate is identified and authenticated
WoSign has applied to include the “Certification Authority of WoSign”
and “CA WoSign” root certificates, turn on all three trust bits for both
root certs, and enable EV treatment for both root certs.
WoSign is a privately-owned CA in China which issues certificates to the
general public.
On 12/11/13 2:55 PM, Gervase Markham wrote:
On 11/12/13 14:31, Kathleen Wilson wrote:
There are a few cases where customers are asking CAs for more time to
transition off of their 1024-bit certificates.
What exactly are CAs asking for? Are they asking for permission to
continue issuing
On 12/12/13 2:11 AM, Jan Schejbal wrote:
Roots can be removed by disabling the trust bits (i.e. a reasonably
simple change). This should be done ASAP after the relevant date -
shouldn't it have been included in the Gecko/Firefox 27 beta currently
running? Can it still be included, or is it too
On 12/13/13 4:03 AM, Rob Stradling wrote:
On 12/12/13 01:08, fhw...@gmail.com wrote:
That's the great part about this, Rob, you don't actually have to revoke
anything.
Peter, thanks for sharing your interpretation. What concerns me is that
the same interpretation is not shared by everyone.
On 12/20/13 11:45 AM, Rob Stradling wrote:
To me, cert revocation means replying revoked via OCSP for that
cert's serial number, and also adding that cert's serial number to the CRL.
I understand that new versions of browsers will stop accepting 1024-bit
certs and that site operators will
All,
I received the following question from an auditor, and would appreciate
hearing your opinions on it. This question is in regards to a new CA
inclusion request. New CAs are frequently not members of the CA/Browser
Forum, so they tend to find out about the Baseline Requirements audit
when
All,
I will appreciate your input on how to proceed with the KISA root
inclusion request.
My personal preference is to proceed with the process to approve/include
the KISA root under the condition that Mozilla would constrain the CA
hierarchy to *.kr. However, KISA does not want to
On 3/4/14, 8:00 AM, Rich Smith wrote:
On Mon, Mar 3, 2014 at 8:33 PM, Kathleen Wilson wrote:
For those CA who have done the compliance with the Baseline Requirements
for the first time, will your root certificate program accept a
point-in-time readiness assessment audit against the WebTrust
On 1/28/14, 4:25 PM, Kathleen Wilson wrote:
DigiCert has applied to include 5 new root certificates that will
eventually replace the 3 DigiCert root certificates that were included
in NSS via bug #364568. The request is to turn on all 3 trust bits and
enable EV for all of the new root certs.
1
On 3/4/14, 4:00 PM, moun...@paygate.net wrote:
as my understanding,
one of LCAs of KISA was audited by WebTrust regulations.
CrossCert, they have partnership with Verisign
and also they are LCA of KISA.
I think, at least one of LCAs is enough to be included into Mozilla Root
Repository.
On 3/3/14, 10:33 AM, Kathleen Wilson wrote:
All,
I received the following question from an auditor, and would appreciate
hearing your opinions on it. This question is in regards to a new CA
inclusion request. New CAs are frequently not members of the CA/Browser
Forum, so they tend to find out
Actalis has applied to enable EV treatment for the “Actalis
Authentication Root CA” root certificate that was included in NSS via
bug #520557.
Actalis is a public CA offering PKI services to a wide number of
customers, mainly banks and local government. Actalis is a Qualified
certification
On 3/4/14, 2:51 PM, Kathleen Wilson wrote:
On 1/28/14, 4:25 PM, Kathleen Wilson wrote:
DigiCert has applied to include 5 new root certificates that will
eventually replace the 3 DigiCert root certificates that were included
in NSS via bug #364568. The request is to turn on all 3 trust bits
On 3/6/14, 9:58 AM, Kathleen Wilson wrote:
On 3/3/14, 10:33 AM, Kathleen Wilson wrote:
All,
I received the following question from an auditor, and would appreciate
hearing your opinions on it. This question is in regards to a new CA
inclusion request. New CAs are frequently not members
On 3/13/14, 3:23 AM, Adriano Santoni - Actalis S.p.A. wrote:
See below:
Il 13/03/2014 01:09, Erwann Abalea ha scritto:
When requesting the OCSP responder to check the subscriber certificate
(thus signed by the intermediate), the response contains a self-signed
certificate for your intermediate
All,
The only place where we currently describe Super-CAs is here:
https://wiki.mozilla.org/CA:SubordinateCA_checklist
“In the situation where the root CA functions as a super CA such that
their CA policies don't apply to the subordinate CAs (including
auditing), then the root CA should not
On 3/6/14, 1:43 PM, Kathleen Wilson wrote:
Actalis has applied to enable EV treatment for the “Actalis
Authentication Root CA” root certificate that was included in NSS via
bug #520557.
Actalis is a public CA offering PKI services to a wide number of
customers, mainly banks and local government
On 3/18/14, 11:54 AM, Kathleen Wilson wrote:
All,
The only place where we currently describe Super-CAs is here:
https://wiki.mozilla.org/CA:SubordinateCA_checklist
“In the situation where the root CA functions as a super CA such that
their CA policies don't apply to the subordinate CAs
On 3/31/14, 8:27 PM, Man Ho (Certizen) wrote:
Hi All,
In this discussion of KISA CA, it seems to conclude that KISA root
certificate should not be included in Mozilla trust list AND the
subordinate CAs should apply for inclusion themselves. On the other
hand, in the discussion regarding Super
On 3/31/14, 4:01 PM, Kathleen Wilson wrote:
On 3/18/14, 11:54 AM, Kathleen Wilson wrote:
All,
The only place where we currently describe Super-CAs is here:
https://wiki.mozilla.org/CA:SubordinateCA_checklist
“In the situation where the root CA functions as a super CA such that
their CA
The following discussion has been stared in mozilla.dev.tech.crypto.
Original Message
Subject: Announcing Mozilla::PKIX, a New Certificate Verification Library
Date: Mon, 07 Apr 2014 15:33:50 -0700
From: Kathleen Wilson kwil...@mozilla.com
Reply-To: mozilla's crypto code
On 4/1/14, 8:11 PM, Kathleen Wilson wrote:
On 4/1/14, 11:12 AM, Kathleen Wilson wrote:
On 3/31/14, 4:01 PM, Kathleen Wilson wrote:
On 3/18/14, 11:54 AM, Kathleen Wilson wrote:
All,
The only place where we currently describe Super-CAs is here:
https://wiki.mozilla.org
The first discussion of this request was here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/DYrrxCsD6CA/9y8a5NnshRgJ
The discussion was closed because one of the root certificates under
consideration had been recently created and not audited. WoSign has
determined that they would
On 4/30/14, 3:59 AM, Gervase Markham wrote: On 30/04/14 00:24, Kathleen Wilson
wrote:
On 4/29/14, 3:44 AM, Gervase Markham wrote:
Does the list on that wiki page need to include the Microsoft equivalent
of the SGC EKU? Or are we not mentioning that?
Yes, it's item #1 in the Things for CAs
On 5/5/14, 4:12 AM, Gervase Markham wrote:
On 01/05/14 17:55, Kathleen Wilson wrote:
Do we need to _stop_ people using this OID, or is it sufficient to
merely start to require that people use the correct one (Server Auth)?
We want people to stop using the obsolete Netscape SGC OID.
Why
On 5/2/14, 1:36 PM, Peter Bowen wrote:
I don't think the policy allows for c (in regards to SSL certs). I hope
that eventually all of the non-technically constrained intermediate certs
will be part of some sort of database of allowed (known and audited)
intermediates. Then SSL certificate path
On 5/6/14, 12:58 PM, Brian Smith wrote:
On Mon, May 5, 2014 at 4:45 PM, Kathleen Wilson kwil...@mozilla.com
wrote:
OK. Changed to the following.
https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix
--
1. For all new intermediate certificate
On 5/6/14, 11:36 AM, Kathleen Wilson wrote:
I updated
https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes
5. A certificate will not be considered an EV certificate if
mozilla::pkix cannot build a path to a trusted root that does not
contain any certificates
On 4/24/14, 1:16 PM, Kathleen Wilson wrote:
On 4/7/14, 5:42 PM, Kathleen Wilson wrote:
QuoVadis has applied to include the “QuoVadis Root CA 1 G3”, “QuoVadis
Root CA 2 G3”, and “QuoVadis Root CA 3 G3” root certificates, turn on
all three trust bits for the RCA1 and RCA3 root certs, and turn
On 5/6/14, 5:39 PM, Brian Smith wrote:
On Tue, May 6, 2014 at 3:48 PM, Kathleen Wilson kwil...@mozilla.com wrote:
It has been brought to my attention that the above statement is very
difficult to understand.
snip
Any preference?
Let's just fix bug 989051 so that we can remove
On 5/12/14, 11:07 AM, Kurt Roeckx wrote:
On Mon, May 12, 2014 at 10:40:27AM -0700, Kathleen Wilson wrote:
All,
The final draft of the CA Communication is here:
https://wiki.mozilla.org/CA:Communications#May_12.2C_2014
So I've asked about this before but I think you never replied. It
doesn't
On 5/13/14, 8:46 AM, Jeremy Rowley wrote:
That actually clears things up. Intermediate certs aren't required to have
an EKU but, if they do and the intermediate will be used for SSL, they must
have the id-kp-serverAuth (1.3.6.1.5.5.7.3.1) EKU.
I think I understand the concern now.
I have
I have sent the CA Communication.
A copy of it will remain here:
https://wiki.mozilla.org/CA:Communications#May_13.2C_2014
Thanks to all of you who contributed to the discussions about this
communication.
Kathleen
___
dev-security-policy mailing
On 5/13/14, 1:13 PM, Kathleen Wilson wrote:
I have sent the CA Communication.
A copy of it will remain here:
https://wiki.mozilla.org/CA:Communications#May_13.2C_2014
Thanks to all of you who contributed to the discussions about this
communication.
Kathleen
Also posted a security blog
All,
In response to the CA Communication, I have received the following question.
Question: Please clarify Action #5: Do you expect public disclosure of
all subordinate CA certificates, or just those issued to third parties?
Answer:
On 5/19/14, 9:40 AM, Rick Andrews wrote:
Kathleen, that means we'll be disclosing a number of intermediates
used to sign certificates that are not used for SSL, Code Signing or
Mail (the three trust bits that Firefox lets me view/edit). For
example, we issue a lot of client auth certs from
On 5/20/14, 10:03 AM, Kurt Roeckx wrote:
I've been working on checking that certificates made by the CAs
are following requirements, and how it changes over time. You can
see the results at:
http://www.roeckx.be/certificates/
Kurt
Kurt, Great work! Thank you for sharing this analysis!
On 5/20/14, 11:08 AM, Kathleen Wilson wrote:
On 5/19/14, 9:40 AM, Rick Andrews wrote:
Kathleen, that means we'll be disclosing a number of intermediates
used to sign certificates that are not used for SSL, Code Signing or
Mail (the three trust bits that Firefox lets me view/edit
On 5/20/14, 12:32 PM, Kurt Roeckx wrote:
On Tue, May 20, 2014 at 11:23:54AM -0700, Kathleen Wilson wrote:
On 5/20/14, 10:03 AM, Kurt Roeckx wrote:
Conclusions
Some of CA/Browser forum baseline requirements seems to be getting
adopted good, but there are still some certificates generated
Hi Rick,
Please see item #3 of
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Frequently_Asked_Questions
--
3. How do I technically constrain a subordinate CA certificate that will
only be used to issue end-user certificates intended for client
authentication?
For the subCA certificate to
On 5/21/14, 2:54 PM, Ryan Sleevi wrote:
On Wed, May 21, 2014 12:12 pm, Kathleen Wilson wrote:
On 5/20/14, 9:53 AM, Rick Andrews wrote:
Ryan, they're not, but the root is not trusted for SSL (via meta-data).
AFAIK, Firefox won't trust any SSL cert chaining to it. Will Chrome?
-Rick
On 5/22/14, 9:38 AM, Kurt Roeckx wrote:
On Thu, May 22, 2014 at 08:50:02AM -0700, Kathleen Wilson wrote:
But really, since the websites and code signing trust bits are not enabled,
the hierarchy is already essentially constrained -- NSS would give an
exception for path validation of an SSL
On 5/21/14, 5:02 PM, Kathleen Wilson wrote:
On 5/21/14, 2:54 PM, Ryan Sleevi wrote:
On Wed, May 21, 2014 12:12 pm, Kathleen Wilson wrote:
On 5/20/14, 9:53 AM, Rick Andrews wrote:
Ryan, they're not, but the root is not trusted for SSL (via meta-data).
AFAIK, Firefox won't trust any SSL cert
On 5/22/14, 3:53 PM, Kathleen Wilson wrote:
On 5/22/14, 1:18 PM, Kurt Roeckx wrote:
On Thu, May 22, 2014 at 02:57:26PM -0500, Steve Roylance wrote:
Hi Kathleen,
The policy group responsible for control of our certificates and keys
have a
question for you concerning the disclosure
On 5/14/14, 6:42 AM, fhw...@gmail.com wrote:
Thanks for pointing out my oversight, Rob. When I read that first paragraph I
skipped over the first word, which is an important first word!
I was a little thrown by the last sentence, a single issuing CA. I took that
to mean root cert, but I guess
On 4/7/14, 5:42 PM, Kathleen Wilson wrote:
QuoVadis has applied to include the “QuoVadis Root CA 1 G3”, “QuoVadis
Root CA 2 G3”, and “QuoVadis Root CA 3 G3” root certificates, turn on
all three trust bits for the RCA1 and RCA3 root certs, and turn on the
websites and code signing trust bits
Thank you to all of you CAs who have responded to the CA Communication.
It will take me a few days to get through all of the responses.
I appreciate your patience.
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
On 5/28/14, 5:17 PM, Kathleen Wilson wrote:
On 5/22/14, 3:53 PM, Kathleen Wilson wrote:
On 5/22/14, 1:18 PM, Kurt Roeckx wrote:
On Thu, May 22, 2014 at 02:57:26PM -0500, Steve Roylance wrote:
Hi Kathleen,
The policy group responsible for control of our certificates and keys
have a
question
On 6/3/14, 1:52 AM, Rob Stradling wrote:
On 03/06/14 01:42, Kathleen Wilson wrote:
On 5/28/14, 5:17 PM, Kathleen Wilson wrote:
snip
I could create another spreadsheet for SubCAs that are in CRL/OCSP mode,
and it could have columns for
Name of SubCA (optional)
SubCA Cert's Issuer Hash
SubCA
On 5/30/14, 1:32 PM, Kathleen Wilson wrote:
Thank you to all of you CAs who have responded to the CA Communication.
It will take me a few days to get through all of the responses.
I appreciate your patience.
Kathleen
I have tabulated all of the responses that I have received.
https
ANF Autoridad de Certificación has applied to include the “ANF Server
CA” and “ANF Global Root CA” root certificates, turn on the websites
trust bit for both, and enable EV treatment for the “ANF Global Root CA”
certificate.
ANF Autoridad de Certificación (ANF AC) is a private Certification
GlobalSign has applied to include the “GlobalSign ECC Root CA - R4” and
“GlobalSign ECC Root CA - R5” root certificates, and turn on all three
trust bits and enable EV treatment for both roots.
GlobalSign, a privately owned organization, provides businesses and
individuals with SSL, SMIME and
On 7/25/14, 3:11 PM, Kathleen Wilson wrote:
== Background ==
We have begun removal of 1024-bit roots with the following 2 bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=936304
-- Remove Entrust.net, GTE CyberTrust, and ValiCert 1024-bit root
certificates from NSS
https
Comodo has applied to include the “COMODO RSA Certification Authority”,
“USERTrust RSA Certification Authority”, and “USERTrust ECC
Certification Authority” root certificates and turn on all three trust
bits and enable EV treatment for the new roots.
Comodo, a private corporation, is a
On 7/31/14, 1:17 PM, Kathleen Wilson wrote:
Here's what we are doing for this first batch of root changes that was
made in NSS 3.16.3, and is currently in Firefox 32, which is in Beta.
NSS 3.16.4 will be created and included in Firefox 32. It will only
contain these two changes:
1) https
On 7/29/14, 2:00 PM, Kathleen Wilson wrote:
All,
Thank you to those of you who have reviewed and commented on this
inclusion request from CFCA. I will appreciate your opinions in response
to my questions below regarding how to move forward with this request.
Note that the “CFCA GT CA” root
Let's please discuss the auditor questions a little more...
The auditor's statement (http://www.cfca.com.cn/file/PwC_CFCA(en).rar)
says that the auditor performed the procedures according to the
WebTrust for Certification Authorities - SSL Baseline Requirements
Audit Criteria Version 1.1
ECC Roots
OK, let's dive into the CPS dissection game...
On Tue, Jul 29, 2014 at 03:26:08PM -0700, Kathleen Wilson wrote:
** CPS section 3.2.2.3, Extended Validation Certificates (SSL and Code
Signing): For Extended Validation Certificates, the EV Guidelines are
followed.
I'm new to this, so
On 8/12/14, 10:58 PM, Steve Roylance wrote:
Hi Kathleen,
I see the underlying question that you (and Matt) wanted us to answer.
Apologies in not being complete in my response the first time around.
The reason we are specific in the CPS with regards to Organizational vetting
(for everything
On 8/12/14, 9:43 PM, fhw...@gmail.com wrote:
It is a separate discussion. I wanted only some sort of statement
from Mozilla about time frames and anticipated functionalities, if there are
any.
Here's my understanding...
There are folks at Mozilla who are closely following CT (RFC 6962).
We
All,
As the CFCA discussion showed, there are a few things still to figure
out regarding the audits of CA conformance to the BRs.
Here are my proposals.
1) BR Audits should always include the whole-population audit of
intermediate certificates.
The CA's roots and all of their intermediate
I added a paragraph about this to the Recommended Practices wiki page...
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
==
It is not sufficient to simply reference section 11 of the CA/Brower
Forum's Baseline Requirements (BR). BR #11.1.1 lists several ways in
On 7/31/14, 2:36 PM, Kathleen Wilson wrote:
Comodo has applied to include the “COMODO RSA Certification Authority”,
“USERTrust RSA Certification Authority”, and “USERTrust ECC
Certification Authority” root certificates and turn on all three trust
bits and enable EV treatment for the new roots
All,
I started a new wiki page to document Mozilla's expectations regarding
CA compliance with the BRs, and auditing according to the BRs.
https://wiki.mozilla.org/CA:BaselineRequirements
It is a very rough draft, but I would appreciate feedback on it.
Thanks,
Kathleen
On 8/19/14, 5:37 PM, Kathleen Wilson wrote:
All,
I started a new wiki page to document Mozilla's expectations regarding
CA compliance with the BRs, and auditing according to the BRs.
https://wiki.mozilla.org/CA:BaselineRequirements
It is a very rough draft, but I would appreciate feedback
On 8/20/14, 5:30 PM, kirk_h...@trendmicro.com wrote:
Sorry for this late response, but Peter Bowen's post below in subpart 2) is
exactly correct - FF needs to accept PITRAs from new CA roots, or else you will
never have any new CA roots.
I updated the wiki page to make it more clear that I
On 8/20/14, 5:57 PM, Ryan Sleevi wrote:
Regarding Whole-Population BR Audit of Intermediate Certs, since the BRs
are for SSL certs, this should probably only apply to intermediate certs
that are capable of issuing SSL certs.
Agreed, which will require a definition of capability. This was
On 7/29/14, 3:26 PM, Kathleen Wilson wrote:
GlobalSign has applied to include the “GlobalSign ECC Root CA - R4” and
“GlobalSign ECC Root CA - R5” root certificates, and turn on all three
trust bits and enable EV treatment for both roots.
Thanks to those of you who have already contributed
On 8/14/14, 11:43 AM, Kathleen Wilson wrote:
On 7/31/14, 2:36 PM, Kathleen Wilson wrote:
Comodo has applied to include the “COMODO RSA Certification Authority”,
“USERTrust RSA Certification Authority”, and “USERTrust ECC
Certification Authority” root certificates and turn on all three trust
On 8/21/14, 4:28 PM, Kathleen Wilson wrote:
On 8/14/14, 11:43 AM, Kathleen Wilson wrote:
On 7/31/14, 2:36 PM, Kathleen Wilson wrote:
Comodo has applied to include the “COMODO RSA Certification Authority”,
“USERTrust RSA Certification Authority”, and “USERTrust ECC
Certification Authority” root
On 8/20/14, 2:03 PM, Peter Bowen wrote:
On Wed, Aug 20, 2014 at 1:55 PM, fhw...@gmail.com wrote:
I've encountered a wildcard end-entity certificate on a live server that chains
directly to the root cert. There is no intermediate certificate and the root is
in the Mozilla trust store.
I
On 8/26/14, 12:10 PM, Peter Bowen wrote:
Could you publish a list of BR section numbers which one or more CA is
saying they do not yet comply with, not including any CA names? That
would help determine the scope of the request and provide some
guidance on the possible impact of the
On 8/26/14, 1:14 PM, Chris Palmer wrote:
On Tue, Aug 26, 2014 at 1:09 PM, Kathleen Wilson kwil...@mozilla.com wrote:
BR 9.5 – 1024-bit certs with validity beyond 2013 (in order to support
legacy customer apps)
BR 13.2.6 - OCSP giving status “good” for unknown serial numbers.
BR 16.5 - multi
On 8/26/14, 1:42 PM, Chris Palmer wrote:
If CAs can't meet the baseline requirements that they themselves
helped set, and prove so to the public, perhaps the current situation
is the end of the road.
Sigh. It'll get better. I can see in those audit statements that the
issues either were
On 8/21/14, 8:59 AM, Kathleen Wilson wrote:
On 8/20/14, 5:30 PM, kirk_h...@trendmicro.com wrote:
Sorry for this late response, but Peter Bowen's post below in subpart
2) is exactly correct - FF needs to accept PITRAs from new CA roots,
or else you will never have any new CA roots.
I updated
On 8/27/14, 7:11 AM, Jean-Marc Desperrier wrote:
David E. Ross a écrit :
With a redacted audit report, the presumption
should be that hidden negative information exists that would disqualify
the certification authority from having its root certificate in the NSS
database if such information
On 8/27/14, 9:15 AM, Kathleen Wilson wrote:
Based on the discussion so far, I think the answer is that the CAs need
to work with their auditors to create a public-facing audit statement
that does not have information in it that the CA considers sensitive,
but that sufficiently lists the BRs
On 8/26/14, 4:14 PM, Kathleen Wilson wrote:
I updated the wiki page to make it more clear that I am concerned about
the case where the CA did not know about the BRs, so there are an
unknown number of certs in that CA hierarchy that do not conform to the
BRs.
https://wiki.mozilla.org
On 8/28/14, 8:01 PM, Eric Mill wrote:
I hadn't caught the wiki update -- that's terrific! Thanks for pointing it
out.
I had planned to say something about the change in the wiki page in this
discussion forum, but just hadn't gotten around to it yet. So, I
appreciated the reminder.
I can
I updated the wiki page some more, here's the text...
https://wiki.mozilla.org/CA:BaselineRequirements#BR_Point_in_Time_Readiness_Assessment_.28BR_PITRA.29
== BR Point in Time Readiness Assessment (BR PITRA) ==
We previously said: Any Certificate Authority being considered for root
inclusion
On 9/2/14, 10:53 AM, Hubert Kario wrote:
I've finally found some time to analyse the data from last months scan
to see what happens when additional roots are removed[1,2].
The scan took place between 11th and 19th of July 2014.
Sites scanned are taken from Alexa top 1 million sites as of 11th
I updated this part of the wiki page:
https://wiki.mozilla.org/CA:BaselineRequirements#Audit_Mistakes
The section is long, so I won't copy it all here.
The most significant change is the addition of the last sentence in this
paragraph:
When egregious mistakes were overlooked by the auditor,
On 9/3/14, 3:53 PM, David E. Ross wrote:
On 9/3/2014 2:43 PM, Matt Palmer wrote:
On Wed, Sep 03, 2014 at 02:24:04PM -0700, Kathleen Wilson wrote:
The most significant change is the addition of the last sentence in
this paragraph:
When egregious mistakes were overlooked by the auditor
All,
I posted a security blog about 1024-bit certs...
https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
On 8/21/14, 3:25 PM, Kathleen Wilson wrote:
On 7/29/14, 3:26 PM, Kathleen Wilson wrote:
GlobalSign has applied to include the “GlobalSign ECC Root CA - R4” and
“GlobalSign ECC Root CA - R5” root certificates, and turn on all three
trust bits and enable EV treatment for both roots.
Thanks
On 9/9/14, 3:43 PM, Kathleen Wilson wrote:
On 8/21/14, 3:25 PM, Kathleen Wilson wrote:
On 7/29/14, 3:26 PM, Kathleen Wilson wrote:
GlobalSign has applied to include the “GlobalSign ECC Root CA - R4” and
“GlobalSign ECC Root CA - R5” root certificates, and turn on all three
trust bits
All,
I updated the following sections of the CA:BaselineRequirements wiki
page based on feedback that I received from auditors. Please re-review
these sections, and reply if you have feedback on them.
On 9/6/14, 8:38 AM, Kosuke Kaizuka wrote:
On Sat, 06 Sep 2014 16:34:06 +0200, Sjw wrote:
Hi everyone
At present, there are a lot of articles, that the weak SHA1 certificates
with a long duration will be marked as weak/insecure in some browsers
soon and in a few years they won't be accepted
On 9/20/14, 2:35 PM, Eric Mill wrote:
Spitting out dev console warnings is certainly a step forward. I'm not sure
how the new dev console and Firebug interact, but I assume these added
warnings would also show up in Firebug.
I've noted to make sure the warnings show up in Firebug too.
Krajowa Izba Rozliczeniowa (KIR) S.A. has applied to include the “SZAFIR
ROOT CA” root certificate and enable all three trust bits.
KIR S.A. is a private corporation in Poland which currently mainly
issues qualified certificates for general public and plans to issue
non-qualified certificates
On 9/30/14, 1:40 PM, Matt Palmer wrote:
The CPS is a Certification *Practice* Statement,
not a Certification *Principles* Statement, and so I think it is reasonable
to expect a description of the practices undertaken in issuing certificates.
Matt is correct.
BR section 8.2.1 says: The CA
Staat der Nederlanden has applied to include the “Staat der Nederlanden
Root CA - G3” and “Staat der Nederlanden EV Root CA” root certificates;
turn on the Websites and Email trust bits for the “Staat der Nederlanden
Root CA - G3” root; turn on the Websites trust bit for the “Staat der
On 10/27/14, 2:05 PM, Kathleen Wilson wrote:
On 10/24/14, 4:24 PM, Daniel Roesler wrote:
Howdy all,
I'm trying to understand the trust flags in the root CA list[1].
According to Bug #605187[2] , the AOL root cert[3] should be removed.
However, it is still in the list and all the flags
On 10/22/14, 4:02 PM, Kathleen Wilson wrote:
On 9/23/14 5:49 PM, Kathleen Wilson wrote:
Krajowa Izba Rozliczeniowa (KIR) S.A. has applied to include the “SZAFIR
ROOT CA” root certificate and enable all three trust bits.
Thanks to all of you who have contributed to this discussion
IdenTrust has applied to include the “IdenTrust Commercial Root CA 1”
and “IdenTrust Public Sector Root CA 1” root certificates, and turn on
the Websites and Email trust bits for both. The “IdenTrust Commercial
Root CA 1” root will eventually replace the “DST Root X3” certificate,
and the
1 - 100 of 747 matches
Mail list logo
