All,
It has been brought to my attention that there is a discrepancy between
Mozilla policy and the Baseline Requirements regarding 1024-bit root certs.
https://wiki.mozilla.org/CA:MD5and1024
"December 31, 2013 – Soon after this date, Mozilla will disable the SSL
and Code Signing trust bits f
On 10/8/13 12:41 PM, John Nagle wrote:
Date: Tue, 08 Oct 2013 07:16:54 +0200
From: Kaspar Brand
To: dev-security-policy@lists.mozilla.org
Subject: Re: Netcraft blog, violations of CABF Baseline Requirements,
any consequences?
Fine. So in the case of Verizon, why does Mozilla not p
All,
I'm going to be making the following changes to
http://www.mozilla.org/projects/security/certs/included/
1) Add "SHA1 Fingerprint" column
2) Convert the three trust bit columns into one column like pending list
(http://www.mozilla.org/projects/security/certs/pending/)
3) In the "EV Enab
On 10/11/13 6:25 AM, Rob Stradling wrote:
On 11/10/13 14:22, Rob Stradling wrote:
On 11/10/13 14:11, Rob Stradling wrote:
Hi Kathleen. The attached zipped .csv file
...was rejected by the listserver.
I've changed the extension from .zip to .txt. Maybe it'll work this
time.
It worked. J
On 10/10/13 4:03 PM, Kathleen Wilson wrote:
All,
I'm going to be making the following changes to
http://www.mozilla.org/projects/security/certs/included/
1) Add "SHA1 Fingerprint" column
2) Convert the three trust bit columns into one column like pending list
(http://www.mozil
On 10/14/13 4:35 AM, Rob Stradling wrote:
On 12/10/13 01:03, Kathleen Wilson wrote:
Please let me know if you notice any errors in the spreadsheet.
Thanks Kathleen. I've compared your updated spreadsheet to my records
and found the following errors in your spreadsheet...
Rob, Than
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", "Publ
All,
I think we should have a discussion about the level of involvement
required of a CA to go through the root inclusion process.
How much of the process can a CA pay someone else to do?
What should the CA do on their own to demonstrate their own commitment
to running a trust anchor?
I am
>> Another 10 days have passed without any apparent sign of Mozilla's
>> willingness to address the case of the non-existence of an OCSP
>> responder for the Cybertrust SureServer EV CA.
Here is my opinion on this topic.
I don't believe there was an additional security risk caused by Verizon
no
On 10/22/13 11:02 AM, Kathleen Wilson wrote:
>> Another 10 days have passed without any apparent sign of Mozilla's
>> willingness to address the case of the non-existence of an OCSP
>> responder for the Cybertrust SureServer EV CA.
Here is my opinion on this topic.
I
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 to
find the OCSP response on its own. Additionally
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 s
On 10/23/13 3:14 PM, Eddy Nigg wrote:
In the case of EV certs, Mozilla is still checking the CRL when the
OCSP URI is not provided.
Since when does Firefox check CRLs? I believe it never did except if
configured manually (which is probably almost never).
For EV certs Firefox has always che
On 10/24/13 11:45 AM, Eddy Nigg wrote:
On 10/24/2013 08:01 PM, From Kathleen Wilson:
For EV certs Firefox has always checked the CRL when the OCSP AIA URI
was not provided. EV treatment would not be given if current
revocation information was not obtained.
If Firefox really uses the CRLDP
On 10/17/13 10:18 AM, Kathleen Wilson wrote:
All,
I need to update
https://wiki.mozilla.org/CA:SubordinateCA_checklist
to reflect the current policy (technically constrain or disclose/audit).
Thanks to Jeremy and Rob for your recommendations.
I have updated this wiki page
https
On 8/6/13 10:59 AM, Kathleen Wilson wrote:
Firmaprofesional has applied to enable EV treatment for the “Autoridad
de Certificacion Firmaprofesional CIF A62634068” root certificate that
was included in NSS via Bugzilla #521439.
Thank you Erwann for providing feedback on this request.
The OCSP
On 10/1/13 10:53 AM, Kathleen Wilson wrote:
T-Systems has applied to include the “T-TeleSec GlobalRoot Class 2” root
certificate, and turn on the Websites and Email trust bits. This SHA-256
root will eventually replace the “Deutsche Telekom Root CA 2” root
certificate that was included via
On 10/1/13 11:32 AM, Kathleen Wilson wrote:
The first discussion of the Atos Root Inclusion Request may be found here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/zEfkTiu_Uqk/SkN1oUSykGcJ
To summarize:
Atos applied to include the “Atos TrustedRoot 2011” root certificate and
On 10/23/13 2:20 PM, Jan Schejbal wrote:
Hi,
there have been repeated issues where CAs were claimed to be
untrustworthy due to prior misconduct not related to certificates.
Usually, this was dismissed by saying that no certificate was issued
contrary to Mozilla Policy, and thus there is no reason
https://wiki.mozilla.org/CA:How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_request
"An official representative of the CA must submit and/or participate in
the root inclusion request. According to Mozilla's CA Certificate
Inclusion Policy: "To request that its certifica
On 10/29/13 5:20 AM, fhw...@gmail.com wrote:
Changing the subject line because compliance is at the heart of this
issue. I also would like to thank Brian for his comment below, because
it seems we're discussing less the merits of CRLs and more rationalizing
the cost to implement.
So...if Mo
On 10/28/13 10:47 AM, Kathleen Wilson wrote:
On 8/6/13 10:59 AM, Kathleen Wilson wrote:
Firmaprofesional has applied to enable EV treatment for the “Autoridad
de Certificacion Firmaprofesional CIF A62634068” root certificate that
was included in NSS via Bugzilla #521439.
Thank you to those
On 10/28/13 11:06 AM, Kathleen Wilson wrote:
On 10/1/13 10:53 AM, Kathleen Wilson wrote:
T-Systems has applied to include the “T-TeleSec GlobalRoot Class 2” root
certificate, and turn on the Websites and Email trust bits. This SHA-256
root will eventually replace the “Deutsche Telekom Root CA 2
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 certificat
On 10/31/13 7:40 AM, Jean-Marc Desperrier wrote:
Eddy Nigg a écrit :
If Firefox really uses the CRLDP
No, it has never used the CRLDP to download the CRL.
People need to import the CRL manually and then activate the
auto-update, and nobody does it. What's more if the CRL becomes outdated
for s
On 10/31/13 9:50 AM, Rick Andrews wrote:
I noticed that Wikipedia lists EV OIDs
(http://en.wikipedia.org/wiki/Extended_validation).
If any are missing, it's easy to update that page.
I only put the EV OID(s) in
http://www.mozilla.org/projects/security/certs/included/
if the root is actually
All,
I propose adding the following bullet point to the list in
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Technical_Constraints_or_Auditing.2FDisclosure_of_Intermediate_Certificates
"- A pre-existing subordinate CA certificate that expires before May 15,
2014 may be re-issued in order t
this
addition.
Thanks,
Kathleen
On 10/31/13 1:03 PM, Kathleen Wilson wrote:
All,
I propose adding the following bullet point to the list in
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Technical_Constraints_or_Auditing.2FDisclosure_of_Intermediate_Certificates
"- A pre-exi
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 for the
On 11/1/13 1:39 PM, Jeremy Rowley wrote:
Hi Kathleen,
Can you clarify whether this applies only to third-party Sub CA certificates
or internal subordinate CAs? A lot of the inclusion policy seems applicable
only to external sub CAs. If the certificate is covered by our WebTrust
audit, is opera
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. WoSig
All,
Thank you to those of you who have participated in this discussion.
Here’s my response to this discussion so far.
> We could require CAs to notify us of intermediate
> certificate revocations even if, at that point in time,
> we were not intending to include them in the
> push mechanism.
Thank you David, Wendy, and Gerv for your input.
Here are my current thoughts on this.
> Can a CA hire someone to manage the inclusion process for them?
Yes, but a known individual within the CA must also get a Bugzilla
account and comment in the bug to say that they will be the primary
point
On 11/4/13 4:19 PM, fhw...@gmail.com wrote:
Kathleen,
Is it captured somewhere that the CA will provide Mozilla with updated
contact info if a new person becomes the point of contact for the CA? I
wasn't sure.
http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html
"6.
On 11/5/13 5:45 AM, Rob Stradling wrote:
On 05/11/13 00:07, Kathleen Wilson wrote:
> What is the role of the CA’s primary point of contact (POC) with
regard to Mozilla’s CA program?
The CA’s POC must be someone within the CA’s organization who has
authority to speak on behalf of the CA,
To help with this discussion, I’ve updated the wiki page, so we can see
it in context.
The old text was:
https://wiki.mozilla.org/CA:Information_checklist#General_information_about_the_associated_organization_of_the_CA
“6. CA Contact Information
- CA Email Alias: An email alias is being requeste
On 11/13/13 4:48 AM, wos...@gmail.com wrote:
Very thanks to Mr Erwann Abalea’s comments.
I am very sorry that we don’t update the related document in Mozilla bugzilla
in time. My company changed the company name from “WoSign eCommerce Services
Limited” to “WoSign CA Limited” at Sept 10th, so we
On 11/12/13 11:31 AM, fhw...@gmail.com wrote:
There are a couple good points here, starting with hard-fail. Why is it
not already turned on by default? What is the argument against it?
OCSP responders are not yet reliable enough for us to do hard fail.
This is old news:
http://news.netcraft.c
Mozilla Security Blog post:
https://blog.mozilla.org/security/2013/12/09/revoking-trust-in-one-anssi-certificate/
Google's blog post:
http://googleonlinesecurity.blogspot.com/2013/12/further-improving-digital-certificate.html
The CA's public statement:
http://www.ssi.gouv.fr/fr/menu/actualites/
On 12/9/13 9:42 AM, Kathleen Wilson wrote:
Mozilla Security Blog post:
https://blog.mozilla.org/security/2013/12/09/revoking-trust-in-one-anssi-certificate/
Google's blog post:
http://googleonlinesecurity.blogspot.com/2013/12/further-improving-digital-certificate.html
The CA
All,
I appreciate you sharing your findings and opinions about this incident
and CA.
Based on some of the CA responses noted in the January CA
Communication[1], I have thought about constraining CAs that are unable
to meet the timelines that have been provided regarding compliance with
the
All,
There are a few cases where customers are asking CAs for more time to
transition off of their 1024-bit certificates.
According to the Baseline Requirements, 1024-bit Subscriber Certificates
are supposed to be no longer valid by 31 Dec 2013.
According to https://wiki.mozilla.org/CA:MD5a
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 such
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 l
For those of you who have been waiting for this...
Firefox 26, released this week, has support for OCSP stapling in it.
https://wiki.mozilla.org/CA:ImprovingRevocation#OCSP_Stapling
Cheers,
Kathleen
___
dev-security-policy mailing list
dev-security-po
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 na
Maybe it would help that the spreadsheet also says what period is
covered, or when it's going to expire.
Certainly. Note that for some CAs, I have provided both the covered
periods and the date when the report was issued in my mail.
I have a column in the spreadsheet that I'll make public, ca
On 1/5/14 12:58 PM, Kurt Roeckx wrote:
I've been going over Mozilla's policy. In the inclusion policy
(V2.2), under 12 it says that you need to conform to the
CA/Browser baseline requirements V1.1.5, but it doesn't say
anything about when you need to comply with the EV Guidelines,
currently at V
This discussion has been started in mozilla.dev.tech.crypto
Please post questions/comments about it in that forum.
Original Message
Subject: Chrome: From NSS to OpenSSL
Date: Mon, 27 Jan 2014 10:28:51 -0800
Newsgroups: mozilla.dev.tech.crypto
Draft Design Doc posted by Ryan Sle
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) DigiCert Assured ID Root G2 -- This SHA-25
On 1/29/14 11:22 AM, Ryan Sleevi wrote:
On Wed, January 29, 2014 10:50 am, Jeremy Rowley wrote:
5) Having only one root with multiple sub CAs emphasizes the "Too Big To
Fail" issue. At DigiCert, and in the spirit of the Microsoft root policy,
we try to segregate the type of certificates i
On 2/15/14 10:42 AM, David E. Ross wrote:
I noticed in the open bug reports for adding new root certificates that
several national certification authorities are actually acting as super
CAs without complete accountability for the operations of their
subsidiary CAs. Is the plan to eventually incl
On 2/19/14 1:43 PM, Jan Schejbal wrote:
Am 2014-02-19 01:52, schrieb Kathleen Wilson:
- don't have external, third-party audits
I think the current policy for these is "do not let/keep them in the
root program", and I think that this policy needs enforcement, not changes.
Ki
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 constrain
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.
Tha
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 se
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 and
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 of the
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 be
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/4/14, 11:38 AM, Kathleen Wilson wrote:
All,
I will appreciate your input on how to proceed with the KISA root
inclusion request.
All,
Thank you for your thoughtful and constructive input.
I believe that there is consensus on the following three points.
1) The KISA CA does not issue
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 subordinat
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 C
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
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/CA:SubordinateCA_checklist
“In the situation where the root 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
Reply-To: mozilla's crypto code discussion list
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
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 for the RCA2 root cert. The request
is to also
On 4/7/14, 4:27 PM, Kurt Roeckx wrote:
On Mon, Apr 07, 2014 at 04:18:17PM -0700, Kathleen Wilson wrote:
If I'm understanding the input on this correctly, then an outside auditor
needs to be involved in some way. But that can mean that the outside auditor
verifies that the audit criteria
On 4/8/14, 3:07 PM, Kurt Roeckx wrote:
Here's the pending and included Super-CAs that I'm aware of.
KISA (Government of Korea, Bug #335197)
ICP-Brasil (Government of Brazil, Bug #438825)
SUSCERTE (Government of Venezuela, Bug #489240)
CCA (Government of India, Bug #557167)
US FPKI (Government of
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/24/14, 10:15 AM, Eddy Nigg wrote:
On 04/24/2014 05:04 AM, Radu Hociung wrote:
On Wednesday, April 23, 2014 6:00:41 PM UTC-4, Eddy Nigg wrote:
I do have a few questions to you! How can you know that a site using a
certificate from ANY CA isn't or wasn't affected by the Heartbleed bug?
I'm
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 for
en and frank
communication, and to be diligent in looking for ways to improve.
Thank you for your cooperation in this pursuit.
Regards,
Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module
** END DRAFT **
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On 4/28/14, 2:05 PM, Jan Lühr wrote:
Does StartSSL violate Mozilla's policies by not revoking certificates
assumed to be compromised?
(Compromised, due to heartbleed, not revoked, because of non-paying
subscribers?)
In regards to policy…
In general, Mozilla’s CA Policy does not tell CAs ho
On 4/28/14, 5:41 PM, Peter Bowen wrote:
On Mon, Apr 28, 2014 at 12:04 PM, Kathleen Wilson wrote:
1) Ensure that Mozilla’s spreadsheet of included root certificates has the
correct link to your most recent audit statement, and that the date of the
audit statement is correct. As per Mozilla'
On 4/29/14, 3:44 AM, Gervase Markham wrote:
On 28/04/14 20:04, Kathleen Wilson wrote:
Please respond with one of the following:
A) Mozilla’s spreadsheet of included root certificates has the correct
link to our most recent audit statement, and the audit statement date is
correct.
B) Here is the
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 "T
We want people to stop using the obsolete Netscape SGC OID.
So, how about if I just add the word "intermediate"?
It'll become:
--
1. Stop using the "Netscape Server Gated Crypto (2.16.840.1.113730.4.1)"
(SGC) EKU. For all new intermediate certificate issuance, use the "TLS
Web Server Authent
On 4/28/14, 12:04 PM, Kathleen Wilson wrote:
All,
Here is a DRAFT CA Communication that I would like to send next week. I
will greatly appreciate your thoughtful and constructive feedback on it.
All,
I have moved the draft of the CA Communication to the wiki page:
https://wiki.mozilla.org
On 5/2/14, 11:17 AM, Peter Bowen wrote:
On Fri, May 2, 2014 at 10:05 AM, Kathleen Wilson wrote:
In regards to action #5, I think we need to add another option to allow CAs
to specify if they have certain subordinate CAs who aren’t quite ready to
move off of their legacy systems for reasons
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 is
On 4/28/14, 6:47 PM, Brian Smith wrote:
[+dev-tech-crypto; Please discuss technical details of mozilla::pkix on
dev-tech-crypto and save dev-security-policy for discussion about Mozilla's
CA inclusion policies. There has been and will be a lot of technical
discussion on the behavior differences a
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
wrote:
>
> OK. Changed to the following.
>
>
https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix
> --
> 1. For all new intermediate cert
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 wit
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
On 4/8/14, 4:38 PM, Kathleen Wilson wrote:
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
On 5/6/14, 5:39 PM, Brian Smith wrote:
On Tue, May 6, 2014 at 3:48 PM, Kathleen Wilson wrote:
It has been brought to my attention that the above statement is very
difficult to understand.
Any preference?
Let's just fix bug 989051 so that we can remove this statement completel
On 5/6/14, 12:05 PM, Kathleen Wilson wrote:
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 all
All,
The final draft of the CA Communication is here:
https://wiki.mozilla.org/CA:Communications#May_12.2C_2014
If you have further comments or feedback on this, please send your input
now.
Otherwise, I will send the communication (via email) this afternoon.
Thanks,
Kathleen
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
do
https://bugzilla.mozilla.org/show_bug.cgi?id=991815#c24
...sounded like a reasonable plan to me.
Yet AFAICT somewhere between comment 24 and comment 28 you've elected to
bypass the CABForum process.
The BRs permit OCSP Responses for Intermediate CA Certificates to be valid
for <=12 months. Sud
1 - 100 of 1007 matches
Mail list logo
