Paul Hoffman wrote:
> Unless Mozilla says "we are going to yank that particular Verisign
> certificate, and all the ones with similar key lengths, decades before
> they expire", there is absolutely no reason for us to, 20 years in
> advance, start requiring "new" CAs to use stronger keys. It is ju
Here is an update with the results of my inquiries about handling of
http redirects when attempting to fetch OCSP responses, Certs or CRLs.
OCSP: we presently use POST requests, not GETs, and we do not support
re-POSTing of requests in response to redirects.
Certs and CRLs: We DO support http re
Paul Hoffman:
Proposal:
a) Starting January 1 2009, all new CA roots must be 2048 bit RSA or
256 bit EC.
b) Starting January 1 2014, all CA roots must be 2048 bit RSA or 256 bit EC.
Dates and sizes can be argued, of course. I would argue against the
date in (b) being more than five years after th
At 7:09 PM -0700 5/29/08, Justin Dolske wrote:
>So? While it might not improve security *immediately*,
It will not improve security for the foreseeable future (assuming
that we take the expiration dates on some of the root certs at face
value).
> I don't see why a
>gradual transition to strict
Another information I'd would like that we seek from CAs are the
validity length of EE certificates. As we discussed, we might consider
to limit this period in the policy and/or make it a best practice
requirement. The same applies to wild card certificates, about which
validations are performe
Paul Hoffman wrote:
> Thus, if we have any
> 1024-bit keys in the root pile (and we might still have ones
> shorter...), requiring all new CA keys to be 2048 bits (for example) has
> no effect on Mallory: he still attacks one of the current roots and gets
> the exact same effect.
So? While it mig
At 5:51 PM -0700 5/29/08, Wan-Teh Chang wrote:
>It is reasonable to impose a stricter key size requirement on new root
>CAs than the currently accepted root CAs.
Why? (I mean that seriously.) The attack we are worried about is
Mallory factoring the public key of any of the CAs in our root store
Paul Hoffman:
Unless we want to put a lower limit on the key size used in our CA
pile, saying that some (most!) of the ones we accept are "of concern"
is confusing at best.
Paul, I think that the general idea (of Frank and others) is, to make a
requirement on new roots and act on the 1024 bi
Hi,
I am not familiar with npapi.h. I just took a quick look at it. As far
as I can tell, you didn't do anything wrong.
We need to make the NSS headers usable with NO_NSPR_10_SUPPORT
defined. I filed a bug for this issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=436430
For now, you'll nee
It is reasonable to impose a stricter key size requirement on new root
CAs than the currently accepted root CAs.
Paul, are you questioning the stricter requirement for new root CAs,
or would you like us to improve the language in the wiki?
Wan-Teh
___
d
Hi,
I am trying to use NSS for using secure communication in my application. During
compilation I am getting conflicts in type defs as:
netscape/include/npapi.h:104: error: conflicting declaration ‘typedef long
unsigned int uint32’
/usr/include/nspr/obsolete/protypes.h:117: error: ‘uint32’ has
At 4:46 PM -0700 5/29/08, Nelson B Bolyard wrote:
>In http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf
>Nist publishes a table of equivalent crypto algorithm/key strengths.
>
>security Symmetric DSA,DHRSA ECDSA
>bits algorithms
> --
In http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf
Nist publishes a table of equivalent crypto algorithm/key strengths.
security Symmetric DSA,DHRSA ECDSA
bits algorithms
-- - -- -
80
The wiki currently says:
Modulus length. (The length of the RSA modulus for the root CA public
and private keys. Note that although the Mozilla CA certificate
policy does not specify a minimum modulus length, in practice a
modulus length of less than 2048 bits is cause for concern.) [What is
t
Frank Hecker:
One of the advantages of working with Gerv and (now) Kathleen is that it
forced me to write down more about the process of evaluating CA
requests. As part of my working with Kathleen I created an expanded
checklist of the information we gather (or should gather) in the course
of con
FYI.
- Forwarded Message -
From: "Matt Ball" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Wednesday, May 28, 2008 1:37:18 PM (GMT-0800) America/Los_Angeles
Subject: [P1619-3] Last reminder: Call for Speakers and Sponsors for the
2008 Key Management Summit Ends This Friday
(Ple
D3|\||\|!$ wrote:
I tried separately compiling the .cpp containing my server class and
the .cpp containing main() with g++. Then I tried building the object
files with g++ along with the "trace" option - this enables one to see
the order in which the files are accessed.
The output is as given be
One of the advantages of working with Gerv and (now) Kathleen is that it
forced me to write down more about the process of evaluating CA
requests. As part of my working with Kathleen I created an expanded
checklist of the information we gather (or should gather) in the course
of considering CA
Nelson B Bolyard wrote:
> Dave Townsend wrote, On 2008-05-28 15:08:
>> Wan-Teh Chang wrote:
>>> It seems that if the private key already exists, we modify its attributes:
> Yes.
>
>> The attribute type is 3584088832. This is with NSS_3_12_RC3
>
> 3584088832 is 0xD5A0DB00 which is CKA_NETSCAPE_DB.
Wan-Teh Chang wrote:
> Dave,
>
> Thanks for the info. So my time estimate is 100% off. Sorry about that.
>
> The attribute type 3584088832 is CKA_NETSCAPE_DB (0xD5A0DB00L).
>
> In security/nss/lib/softoken/legacydb/lgattr.c, function
> lg_FindRSAPrivateKeyAttribute,
> could you try adding case CK
I tried separately compiling the .cpp containing my server class and
the .cpp containing main() with g++. Then I tried building the object
files with g++ along with the "trace" option - this enables one to see
the order in which the files are accessed.
The output is as given below:-
**
21 matches
Mail list logo
