As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule ComSign
is the next request in the queue for public discussion.
ComSign (a private company owned by Comda, Ltd. in Israel) has applied
to add two new root CA certificates to the Mozilla root store, as
documented in the following bug:
are we planning to move the discussions of accepting CAs into the root
list over to the other list? I think that dev-security-policy is going now?
OK. If no one objects, I will post all future root inclusion request
discussions on mozilla.dev.security.policy instead of
dev.tech.crypto.
Certigna met our request to post and translate the relevant portions
of their CPS. There has been very little resulting discussion.
Are there still questions that need to be addressed in this public
discussion phase? Or shall I move forward with making the
recommendation to approve this request?
Many thanks to those of you who have participated in the discussions
for this root inclusion request, and reviewed the information that has
been provided.
The concerns that were raised during the first round of public
discussion have been addressed, and this second round of public
discussion has
Many thanks to those of you who have participated in the discussions
for this root inclusion request, and reviewed the information that has
been provided.
Certigna met the request from the first round of public discussion to
post and translate the relevant portions of their CPS. During the
There are a small number of external CAs that have been signed by our root.
Of the four roots being considered for inclusion (TC TrustCenter Class
1 CA, TC TrustCenter Class 2 CA II, TC TrustCenter Class 3 CA II, TC
TrustCenter Universal CA I) which one(s) have or will have subordinate
CAs that
To summarize this discussion, there are three areas that need to be
resolved. They are: 1) Inclusion of a root that expires in a year and
half. 2) Questions about the Class 0 certificates that are part of the
CPS. 3) Questions about the externally-operated subordinate CAs.
***
1) Inclusion of a
Thank you to those of you who have reviewed this request and
contributed to the discussion. Your time and commitment to this
process is greatly appreciated!
To summarize this discussion, there were three areas that were of
primary interest. They were:
1) Inclusion of a root that expires in a
When processing a cert chain, does Mozilla use a specified algorithm/
order for determining which root to use when there are two roots
included that are identical except for signature algorithm and serial
number?
Are there cases when Firefox might see a full cert chain, including
the root (which
Just to make sure I understand…
In the VeriSign case the MD2 roots expire on 2028-08-01, and the SHA1
roots expire on 2028-08-02, so the SHA1 roots would take precedence in
NSS. Therefore, there is no benefit in keeping the MD2 roots, and the
MD2 roots should be removed when the SHA1 roots are
Based on the Firefox 3.5 beta, I created a table of all of the CAs
that are Builtin Object Tokens. It is posted at:
https://wiki.mozilla.org/CA:Overview
which has a link called List of included root certificates which
points to
https://wiki.mozilla.org/images/c/ce/BuiltIn-CAs.pdf
I look forward
Is there an updated request in the queue for O=ABC.ECOM, INC?
That one expires 7/9/2009, which is less than a month from now.
I cannot find a request regarding ABA.ECOM in Bugzilla.
Could I suggest that you also send a copy of this message
(including URLs) to dev-security-policy?
Done
I posted my response in mozilla.dev.security.policy. Let's continue
the discussion there.
Thanks,
Kathleen
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
The discussions moved to mozilla.dev.security.policy. Do you have an
open bug for this request?
Netlock's CA rollover request is in
https://bugzilla.mozilla.org/show_bug.cgi?id=480966
It is also in the queue for public discussion
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
I am leading the effort to create a policy and a process for removing
a Certification Authority root certificate from distribution in
Mozilla products, and I would greatly appreciate your input and
feedback on the following.
Wiki page for ideas about the process and policy:
Is there an NSS environment variable that can be set such that a warning
is provided when a 1024-bit cert is used in Firefox?
My understanding is that if someone were to try to use a 512-bit cert in
Firefox they would get a warning message to the effect that the
connection is not secure, but
On 5/13/10 3:32 PM, Nelson B Bolyard wrote:
On 2010-05-13 14:30 PST, Kathleen Wilson wrote:
Is there an NSS environment variable that can be set such that a warning
is provided when a 1024-bit cert is used in Firefox?
No. Any NSS environment variable would disable a feature completely
On 5/15/10 10:48 AM, Nelson B Bolyard wrote:
On 2010-05-15 01:35 PDT, Wan-Teh Chang wrote:
On Fri, May 14, 2010 at 11:18 PM, Nelson B Bolyardnel...@bolyard.me wrote:
I looked through PSM for such a warning briefly. I found a warning for
sites that use symmetric encryption of strength= 90
Is there support in NSS to restrict an intermediate CA to only be able
to issue SSL certificates within a specified domain?
If yes, does this support apply to both SANs and CNs?
Can you point me to documentation on how to use this?
The reason that I’m asking is because there has been recent
On 6/1/10 2:05 PM, Nelson B Bolyard wrote:
On 2010/06/01 11:38 PDT, Kathleen Wilson wrote:
Is there support in NSS to restrict an intermediate CA to only be able
to issue SSL certificates within a specified domain?
Yes, the issuer of the intermediate CA cert can constrain the names that
may
On 6/2/10 11:13 AM, Ryan Sleevi wrote:
That's great news! Is there a corresponding bug number or other way I
can track the progress to see which version of NSS it gets into?
https://bugzilla.mozilla.org/show_bug.cgi?id=394919
Excellent! Thanks!
Kathleen
--
dev-tech-crypto mailing list
On 7/26/13 11:15 PM, jeffwang@gmail.com wrote:
Because: The Mainland's people know,the CNNIC is a branch unit of Chinese Acadmy of
Science,a ministerial level government organization of the Central Government of
China,name as The State Council of the people's Republic of China
So:CNNIC is
Draft Design Doc posted by Ryan Sleevi regarding Chrome migrating from
NSS to OpenSSL:
https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1
Switching to OpenSSL, however, has the opportunity to bring significant
performance and stability advantages to iOS,
All,
We have been working on a new certificate verification library for
Gecko, and would greatly appreciate it if you will test this new library
and review the new code.
Background
NSS currently has two code paths for doing certificate verification.
Classic verification has been used for
On 4/7/14, 3:33 PM, Kathleen Wilson wrote:
All,
We have been working on a new certificate verification library for
Gecko, and would greatly appreciate it if you will test this new library
and review the new code.
A special Bug Bounty program has been announced regarding this:
https
25 matches
Mail list logo
