On 28/07/12 15:22 PM, Anders Rundgren wrote:
I won't bother you more on this topic but I honestly do not think
that there will be any progress worth mentioning (particularly on
the fragmented OSS side) until Intel comes out with a open version
of:
http://ipt.intel.com
Coincidentally, Apple ju
On Fri, 2012-07-27 at 12:07 -0700, Robert Relyea wrote:
> The news to me is that applications care, which means I need to
> figure out an api to give the application that information.
The applications actively don't *want* to care, but the existing
interface by which they use the sh
I won't bother you more on this topic but I honestly do not think
that there will be any progress worth mentioning (particularly on
the fragmented OSS side) until Intel comes out with a open version
of:
http://ipt.intel.com
I hope to make it easier for Intel by doing things in the opposite way,
e
On 07/27/2012 10:25 AM, David Woodhouse wrote:
On Fri, 2012-07-27 at 10:08 -0700, Robert Relyea wrote:
Oh, so you switch between sql:/etc/pki/nssdb and sql:$HOME/.pki/nssdb=20
depending on whether libnsssysinit.so exists.
It's worse than that. It's not just whether libnsssysinit.so *exists*,
bu
Unifying trust and even more private key storage has reasonable
solutions in other operating systems. These solutions make sense
for app-developers to use.
I don't think that a quick fix can compensate for the more over-arching
issue which really is a lack of product management. Fixing JDK would
On Fri, 2012-07-27 at 10:08 -0700, Robert Relyea wrote:
> Oh, so you switch between sql:/etc/pki/nssdb and sql:$HOME/.pki/nssdb=20
> depending on whether libnsssysinit.so exists.
It's worse than that. It's not just whether libnsssysinit.so *exists*,
but whether it's actually loaded by a line in /e
So what I actually want is
- To fix the API to the NSS system database so it isn't insane.
Do you have any suggestions on how the API would be changes. One thing=20
I'm always fighting is providing an API for apps without breaking=20
existing apps.
Well, *not* having to grub around for 'lib
On Fri, 2012-07-27 at 10:53 +0200, Anders Rundgren wrote:
> I think you need to take a step back and consider which
> market and user-base you are targeting.
No, I believe that's been clear from the beginning. Apologies if I
didn't make it explicit enough.
> Linux on the desktop? Why bother with
I think you need to take a step back and consider which
market and user-base you are targeting. Linux on the
desktop? Why bother with that? Linux servers? Well,
*that* could be interesting. Unfortunately it doesn't
help much since most servers run JBoss etc so it is
actually more a JDK problem.
On Thu, 2012-07-26 at 14:13 -0700, Robert Relyea wrote:
> Error verifying signature
> parse error
> --ms050908010406000106010405
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: quoted-printable
(Want to investigate that off-list, or is it expe
On 07/25/2012 03:02 AM, David Woodhouse wrote:
O³.
So what I actually want is
- To fix the API to the NSS system database so it isn't insane.
Do you have any suggestions on how the API would be changes. One thing
I'm always fighting is providing an API for apps without breaking
existing apps
David,
I don't find it particularly surprising that an effort directed towards the
enterprise and qualified individuals using desktop computers, doesn't come to
exactly the same conclusions as a project targeting consumers using mobile
devices for accessing applications like on-line banking. I
On Thu, 2012-07-26 at 14:00 +0200, Anders Rundgren wrote:
> On 2012-07-26 12:24, David Woodhouse wrote:
>
> >
> >> My same concerns would apply to private keys.
> >
> > An application-specific 'third slot' would certainly address that
> > concern.
>
>
>
> IMO, private keys is a very different
On 2012-07-26 12:24, David Woodhouse wrote:
>
>> My same concerns would apply to private keys.
>
> An application-specific 'third slot' would certainly address that
> concern.
IMO, private keys is a very different topic because they are not
really "owned" by the user and if misused they could
On Wed, 2012-07-25 at 18:03 -0700, Julien Pierre wrote:
> It is questionable to me that the trust should actually be shared for
> all applications running under the same user.
It's *not* "applications". It's *purposes".
So let me rephrase that: it's questionable (in fact, it's definitely
*not* t
Julien,
It is rather David that tries to unify the NSS trust database.
I agree with your comments regarding servers.
FWIW I'm working with a rather different project [1] which aims creating a
system that can be used by *consumers* for existing tasks such as on-line
banking. This project is tech
Anders.
On 7/24/2012 23:33, Anders Rundgren wrote:
Yes. It's an issue I'm actively trying to solve. NSS seems to have made
some *attempt* at solving it... which has some issues, and which doesn't
even seem to have been picked up by Mozilla's own products.
For the record, some Oracle server produ
On Wed, 2012-07-25 at 22:05 +0200, Anders Rundgren wrote:
> Apple will embed security HW directly in the CPU and there will be
> no need for any third-party middleware. It will just work.
I believe the first Intel Apple laptops had a TPM. It was dropped fairly
quickly, and current models don't ha
On 2012-07-25 11:32, helpcrypto helpcrypto wrote:
>> As I understand it, PKCS#11 token support was actually *removed* from
>> the Keychain in the latest versions of OSX, and is now a third-party
>> add-on?
>
> IIRC: Apple said smartcard services are not going to be suportted by
> them, but the com
On Wed, 2012-07-25 at 08:59 +0200, helpcrypto helpcrypto wrote:
>
> You are asking for: (paths are just for example purposes)
> a) To set up a $HOME/nss to store user certs + trusted by the user
> (actually more/less what already have). Doesnt Chrome use something
> like that already?
> b) To se
> As I understand it, PKCS#11 token support was actually *removed* from
> the Keychain in the latest versions of OSX, and is now a third-party
> add-on?
IIRC: Apple said smartcard services are not going to be suportted by
them, but the community (macosforge).
Apple didnt provide a supported altern
oherent way of
managing trusted CAs across the system, and across all applications used
by a given user.
The NSS shared system database *almost* gives us that... or would if
anyone actually used it properly.
That *is* something that all sensible Linux distributions will care
about doing; it's n
Let me ask to make it clear:
You are asking for: (paths are just for example purposes)
a) To set up a $HOME/nss to store user certs + trusted by the user
(actually more/less what already have). Doesnt Chrome use something
like that already?
b) To set up a /usr/nss to store system-wide certs and
I think the lack of progress [*] here has a lot to do with the fact that
there's really nothing to gather around. Making security solutions
for security-conscious people is probably quite fun but since this
only addresses a tiny fraction of the market the urge for consolidation
seems pretty limite
On Tue, 2012-07-24 at 16:12 +0200, Anders Rundgren wrote:
> IMO, this is not an NSS issue, it is rather a *NIX issue. All other
> operating systems (that I'm aware of NB...) including *NIX-derivates
> like Android, already have a system-wide cryptographic architecture.
Yes. It's an issue I'm acti
12-07-24 15:07, David Woodhouse wrote:
> Is the NSS "shared system database" actually going to be used for real?
> I note Firefox *still* isn't using it, four years after bug 449498 was
> opened.
>
> If even Mozilla products aren't using NSS "properly"
Is the NSS "shared system database" actually going to be used for real?
I note Firefox *still* isn't using it, four years after bug 449498 was
opened.
If even Mozilla products aren't using NSS "properly", do we really
expect anyone *else* to?
And what does "
27 matches
Mail list logo
