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
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
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,
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
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
dev
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
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 di
On 5/18/10 1:53 PM, Wan-Teh Chang wrote:
On Tue, May 18, 2010 at 11:16 AM, Kathleen Wilson
wrote:
So, is it the case that PSM is not actually checking for 512-bit certs?
Yes, I confirm that's the case. Nelson and I didn't find the
code or the bug report for checking for 512-bit
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 Bolyard wrote:
I looked through PSM for such a warning briefly. I found a warning for
sites that use symmetric encryption of strength<= 90 bits, but I found
no
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, not
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 t
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:
https://wiki.mozilla.or
> 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_Discussio
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
> 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
T
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
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 ad
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 n
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 year
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 ro
>> 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
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
discuss
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 n
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?
-
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?
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
> 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.
Kath
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:
27 matches
Mail list logo
