Nelson Bolyard wrote, On 2008-08-12 22:59:
I didn't understand that very well, but I _think_ you're saying that if
adding a CA cert that trusted to issue client certs causes that CA to also
be trusted to issue server certs, that would be bad.
Indeed, that would be bad, and it definitely
Nelson Bolyard wrote:
When you trust a cert as a peer, you trust it for all the names that
appear in that cert, just as if it had been issued by a CA you trust.
If it has 50 subject alt names, or a wildcard name, you trust that cert
for all those names.
It turned out that browser users
Howard Chu wrote, On 2008-08-12 19:12:
That was the other point I was trying to make about global state... It's
common practice to set up services with private CAs, so that random nosy
clients cannot connect to them. In an OpenLDAP proxy installation you'll
have one server cert/key and
Howard Chu wrote:
Nelson B Bolyard wrote:
Howard Chu wrote, On 2008-08-10 03:30:
When one considers all the important reasons to choose a crypto
implementation, support for one file format which is not used in any
standard protocols (e.g. TLS, SMIME) doesn't seem like a biggie.
The issue
Howard Chu wrote:
Likewise in the Mozilla Browser/nss_ldap situation, the credentials
needed for LDAP authentication will probably be quite different from the
credentials needed for web browsing or personal addressbook lookups. It
would be extremely bad if simply using Mozilla on a system
Nelson B Bolyard wrote:
Howard Chu wrote, On 2008-08-11 20:07:
Nelson B Bolyard wrote:
Howard Chu wrote, On 2008-08-10 14:13:
It would make it impossible to use in e.g. OpenLDAP/nss_ldap because
applications would be unable to load their own configuration settings
after
Howard,
Howard Chu wrote:
Did any of those FIPS audits red-flag the above code snippet?
Of course not.
You seem to be mistaken about the purpose and scope of FIPS140 validation.
Only cryptographic code needs to be validated. The libnss initialization
code is not cryptographic code, and thus
Bob,
Robert Relyea wrote:
SECMOD_OpenUserDB() will open new database slots in the internal
database module.
Unfortunately, those additional DBs can't be manipulated separately.
This is particularly a problem for trust.
___
dev-tech-crypto mailing
Julien R Pierre wrote on 2008-08-12 16:53 PDT:
Robert Relyea wrote:
SECMOD_OpenUserDB() will open new database slots in the internal
database module.
Unfortunately, those additional DBs can't be manipulated separately.
huh?
- key gens can be done in each one separately,
- certs can be
Nelson,
Nelson Bolyard wrote:
Julien R Pierre wrote on 2008-08-12 16:53 PDT:
Robert Relyea wrote:
SECMOD_OpenUserDB() will open new database slots in the internal
database module.
Unfortunately, those additional DBs can't be manipulated separately.
huh?
- key gens can be done in each
Julien R Pierre - Sun Microsystems wrote:
Nelson,
Nelson Bolyard wrote:
Julien R Pierre wrote on 2008-08-12 16:53 PDT:
Robert Relyea wrote:
SECMOD_OpenUserDB() will open new database slots in the internal
database module.
Unfortunately, those additional DBs can't be manipulated
Actually, most of the developers who work on it are
developing it for
servers. It is revenue from server sales that pay the salaries of
most of NSS developers (since revenues from browser sales
are ... low :).
They must be using it in pretty simple scenarios so far. The
whole who
David Stutzman wrote:
Actually, most of the developers who work on it are
developing it for
servers. It is revenue from server sales that pay the salaries of
most of NSS developers (since revenues from browser sales
are ... low :).
They must be using it in pretty simple scenarios so far.
On Sun, Aug 10, 2008 at 2:13 PM, Howard Chu [EMAIL PROTECTED] wrote:
There's other relics lying around in the code, waiting to bite:
nss/lib/nss/nssinit.c:561
#ifndef XP_MAC
/* only servers need this. We currently do not have a mac server */
if ((!noModDB) (!noCertDB)
Robert Relyea wrote:
Nelson B Bolyard wrote:
Joe Orton wrote, On 2008-07-28 16:09:
On Sat, Jul 26, 2008 at 05:17:56PM -0700, Nelson Bolyard wrote:
Daniel Stenberg wrote, On 2008-07-26 13:45:
As a user of OpenSSL, NSS, yassl and GnuTLS I can certainly agree that
GnuTLS has flaws in its API
Howard Chu wrote, On 2008-08-10 03:30:
Nelson B Bolyard wrote:
Someone could write a PKCS#11 module that uses PEM files as its storage.
It wouldn't be FIPS validated, at least not initially.
In that case, there's even less motivation to adopt NSS, since OpenSSL is
moving ahead with
Nelson B Bolyard:
Howard Chu wrote, On 2008-08-10 03:30:
Following on from the discussion in
https://bugzilla.mozilla.org/show_bug.cgi?id=292127 today I took a look
at what would be involved in adding NSS support to OpenLDAP. Aside from
the lack of hassle-free PEM support (which it appears
Nelson B Bolyard wrote:
Howard Chu wrote, On 2008-08-10 03:30:
When one considers all the important reasons to choose a crypto
implementation, support for one file format which is not used in any
standard protocols (e.g. TLS, SMIME) doesn't seem like a biggie.
The issue isn't about a specific
Eddy Nigg wrote:
Well, consider that people are familiar with OpenSSL commands and new
users get quickly used to it. This might be what others are looking
for when checking out NSS and other libraries (and decide to forget
about it).
Look into the other thread started by me Creating
Howard Chu wrote, On 2008-08-10 14:13:
The issue isn't about a specific file format, it's about overall
usability. Ignoring the issue of hiding things in a fragile DB the
problem is that it's a one-shot monolithic configuration. A process may
only call NSS_Init once, and provides a single
Nelson B Bolyard wrote:
Howard Chu wrote, On 2008-08-10 14:13:
The issue isn't about a specific file format, it's about overall
usability. Ignoring the issue of hiding things in a fragile DB the
problem is that it's a one-shot monolithic configuration. A process may
only call NSS_Init once,
Nelson B Bolyard wrote:
Joe Orton wrote, On 2008-07-28 16:09:
On Sat, Jul 26, 2008 at 05:17:56PM -0700, Nelson Bolyard wrote:
Daniel Stenberg wrote, On 2008-07-26 13:45:
As a user of OpenSSL, NSS, yassl and GnuTLS I can certainly agree that
GnuTLS has flaws in its API but NSS
On Jul 27, 2:17 am, Nelson Bolyard [EMAIL PROTECTED]
wrote:
Daniel Stenberg wrote, On 2008-07-26 13:45:
As a user of OpenSSL, NSS, yassl and GnuTLS I can certainly agree that
GnuTLS has flaws in its API but NSS most certainly also has flaws as well
_and_ notable missing features that
-Original Message-
The requirement to put all cryptographically sensitive
information into a
well defined crypto boundary seems very elegant. It explains
how NSS was
able to work with so many third party crypto gizmos starting
in the late
90's, and how it was able to get 4 FIPS
On Sat, 26 Jul 2008, Nelson Bolyard wrote:
As a user of OpenSSL, NSS, yassl and GnuTLS I can certainly agree that
GnuTLS has flaws in its API but NSS most certainly also has flaws as well
_and_ notable missing features that GnuTLS offers.
Daniel, please tell us what features are missing
Daniel Stenberg wrote, On 2008-07-28 09:12:
On Sat, 26 Jul 2008, Nelson Bolyard wrote:
As a user of OpenSSL, NSS, yassl and GnuTLS I can certainly agree that
GnuTLS has flaws in its API but NSS most certainly also has flaws as well
_and_ notable missing features that GnuTLS offers.
On Mon, 28 Jul 2008, Nelson B Bolyard wrote:
NSS is quite capable of importing certificates in PEM format.
Importing them where? If I want to use NSS for the TLS layer and I have the ca
cert in a PEM format file, how can I make NSS use that file when I connect to
the peer?
My current code
On Sat, Jul 26, 2008 at 05:17:56PM -0700, Nelson Bolyard wrote:
Daniel Stenberg wrote, On 2008-07-26 13:45:
As a user of OpenSSL, NSS, yassl and GnuTLS I can certainly agree that
GnuTLS has flaws in its API but NSS most certainly also has flaws as well
_and_ notable missing features that
This is, honestly, a matter of NSS's implementors decided to force
administrators and users to jump through hoops. There may be
legitimate policy concerns with certain policies that require
everything to be inside the database that NSS uses... but for those
who don't have those policy
Kyle Hamilton wrote, On 2008-07-28 17:23:
This is, honestly, a matter of NSS's implementors decided to force
administrators and users to jump through hoops. There may be
legitimate policy concerns with certain policies that require
everything to be inside the database that NSS uses.
Nothing
Joe Orton wrote, On 2008-07-28 16:09:
On Sat, Jul 26, 2008 at 05:17:56PM -0700, Nelson Bolyard wrote:
Daniel Stenberg wrote, On 2008-07-26 13:45:
As a user of OpenSSL, NSS, yassl and GnuTLS I can certainly agree that
GnuTLS has flaws in its API but NSS most certainly also has flaws as well
On Mon, Jul 28, 2008 at 5:44 PM, Nelson B Bolyard [EMAIL PROTECTED] wrote:
NSS's own PKCS#11
module claims to be 2.10 (don't know why, because it has many features from
2.20).
I believe we claim to be 2.20. See the NSC_GetInfo function:
http://mxr.mozilla.org/security/ident?i=NSC_GetInfo
Wan-Teh Chang wrote, On 2008-07-28 18:20:
On Mon, Jul 28, 2008 at 5:44 PM, Nelson B Bolyard [EMAIL PROTECTED] wrote:
NSS's own PKCS#11 module claims to be 2.10 (don't know why, because it
has many features from 2.20).
I believe we claim to be 2.20. See the NSC_GetInfo function:
Nelson Bolyard a écrit :
[...]
Daniel, please tell us what features are missing that you would actually use
if they were present!
I recently selected Gnutls for a project, only because it was the only
library supporting TLS 1.1's Maximum Fragment Length Negotiation.
Wan-Teh Chang wrote:
On Thu, Jul 24, 2008 at 7:31 PM, Nelson B Bolyard [EMAIL PROTECTED] wrote:
I've been told that GnuTLS's API only supports carrying non-binary
text strings as application data, and doesn't facilitate the transmission
of pure binary files (e.g. containing lots of zero
On Sat, 26 Jul 2008, Michael Ströder wrote:
http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/18#comment:1
(Well, they even aren't keeping their issue tracker spam-free...)
Please, spam is hardly their fault and I don't think you help them any way by
being rude.
As a user of OpenSSL, NSS,
Daniel Stenberg wrote, On 2008-07-26 13:45:
As a user of OpenSSL, NSS, yassl and GnuTLS I can certainly agree that
GnuTLS has flaws in its API but NSS most certainly also has flaws as well
_and_ notable missing features that GnuTLS offers.
Daniel, please tell us what features are missing that
Julien R Pierre - Sun Microsystems wrote:
Copyright owner :
RSA security should be removed !
Netscape/Sun/Red Hats are the original developers of most of the code.
But they don't hold the copyright (see GPL/LPGL/MPL licenses)
Let's not confuse licensing with copyright ownership. AFAIK
On Thu, Jul 24, 2008 at 7:31 PM, Nelson B Bolyard [EMAIL PROTECTED] wrote:
I've been told that GnuTLS's API only supports carrying non-binary
text strings as application data, and doesn't facilitate the transmission
of pure binary files (e.g. containing lots of zero bytes). I find that
Daniel Stenberg wrote, On 2008-07-23 14:43:
On Wed, 23 Jul 2008, Ruchi Lohani wrote:
Since a lot of open source softwares are using NSS, I wish to know whether
we have some documentation on specifics of
OpenSSL and NSS and the advantages NSS has over OpenSSL. If so, can anybody
direct me
Hi all,
Since a lot of open source softwares are using NSS, I wish to know
whether we have some documentation on specifics of
OpenSSL and NSS and the advantages NSS has over OpenSSL. If so, can
anybody direct me over that or just give a brief comparison of both.
Thanks
Ruchi
On Wed, 23 Jul 2008, Ruchi Lohani wrote:
Since a lot of open source softwares are using NSS, I wish to know whether
we have some documentation on specifics of
OpenSSL and NSS and the advantages NSS has over OpenSSL. If so, can anybody
direct me over that or just give a brief comparison of
42 matches
Mail list logo
