qca-softstore

Hello,

I've added a new plugin, qca-softstore.

        qca-softstore provides simple persistent certificate
store for
QCA framework.

        The plug-in defers the private key access and
passphrase
prompt to the point
        it is actually required, thus enabling the use of
files stored
on removable media.

        The plug-in also handles the private key objects as
not
exportable for applications.

        In order to defer the passphrase prompt, the
certificate
object must be extracted
        during configuration, this also apply to PKCS#12
files, since
the certificate
        is encrypted within the format.

This will be usable for environment such as KDE, were the
configuration needs to set up user store.

Justin, this code turned out to be a lot more complex than
I
intended... Two options:
a. I don't use QCA API currectly... This would be easy for
you to inspect.
b. The provider API is very complex.

Also I have an issue with requested feature.
I use TokenAsker to as for "Please insert file"

I guess we need a better solution...
a. Solution that will not force me to add each entry as
separate store.
b. Solution that will enable me to poll for file existence,
and if
found report this to the asker.
c. Any other thought... 

I hope you like the idea.

I think that the trusted root certificates should be moved
into a
provider... Actually I think that almost all functionality
should be
implemented in a provider and not in core QCA... It will be
much
easier to configure/modify/fix/replace this way.

Alon.
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On Sunday 27 May 2007 2:19 pm, Alon Bar-Lev wrote:
> I've added a new plugin, qca-softstore.

Interesting.  I'll have to look at this a little more
later.

First thought: For entry_##_private_type, you have
rsa-file-pem and 
pkcs8-file.  QCA makes no distinction between the rsa and
pkcs8 formats.  
fromDER/fromPEM can work with both (it must at least do
pkcs8, but supporting 
rsa is provider optional), and toPEM/toDER is always pkcs8. 
I suggest 
dropping/changing rsa-file-pem.

> Justin, this code turned out to be a lot more complex
than I
> intended... Two options:
> a. I don't use QCA API currectly... This would be easy
for you to inspect.
> b. The provider API is very complex.

I'll look at this after Beta 6.

> Also I have an issue with requested feature.
> I use TokenAsker to as for "Please insert
file" 
> I guess we need a better solution...

We could have more metadata for the token event, just like
how the password 
event works.

> a. Solution that will not force me to add each entry as
separate store.

You could have one store with many entries.  Use
storeUpdated() to indicate if 
the entry list has changed.

> b. Solution that will enable me to poll for file
existence, and if
> found report this to the asker.

QCA::FileWatch.  Use this only for reporting changes of the
keystore.  The app 
will do the token accept if it wishes (like qcatool does).

> I think that the trusted root certificates should be
moved into a
> provider... Actually I think that almost all
functionality should be
> implemented in a provider and not in core QCA... It
will be much
> easier to configure/modify/fix/replace this way.

The default provider is a QCA::Provider, but it is compiled
in and has special 
properties.  It is also configurable.  I think this is fine
for now.

You can have additional root storages.  All you have to do
is claim to be a 
store of type KeyStore::System, and you can do this in an
external provider 
plugin.

-Justin
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On 5/28/07, Justin Karneges <justin-psi2affinix.com> wrote:
> First thought: For entry_##_private_type, you have
rsa-file-pem and
> pkcs8-file.  QCA makes no distinction between the rsa
and pkcs8 formats.
> fromDER/fromPEM can work with both (it must at least do
pkcs8, but supporting
> rsa is provider optional), and toPEM/toDER is always
pkcs8.  I suggest
> dropping/changing rsa-file-pem.

Done.
But I have a problem... I cannot handle any other than RSA
key without
writing a speparate class for each algoritm...

I tried to:
class softstorePKeyBase : public PKeyBase

Instead of:
class softstoreRSAContext : public RSAContext

All should be fine... I even set up the right string type
out of
public.type ()...

But then qca-openssl calls methods to obtain q, p etc... And
I don't
have them in my class as I am algorithm blind.

A good solution for this is to have "getProperty
()" methods that
exists on PKeyBase so it can overridden and deligated.

> > Also I have an issue with requested feature.
> > I use TokenAsker to as for "Please insert
file" 
> > I guess we need a better solution...
>
> We could have more metadata for the token event, just
like how the password
> event works.

OK. Tell me what you are thinking.

>
> > a. Solution that will not force me to add each
entry as separate store.
>
> You could have one store with many entries.  Use
storeUpdated() to indicate if
> the entry list has changed.

But then I must allocate a new id, right?
Invalidating all current entries...
As a result I must create my out private key cache, to keep
the ones
that already authenticated...

> > b. Solution that will enable me to poll for file
existence, and if
> > found report this to the asker.
>
> QCA::FileWatch.  Use this only for reporting changes of
the keystore.  The app
> will do the token accept if it wishes (like qcatool
does).

I don't understand how this relates to the key store... 

> > I think that the trusted root certificates should
be moved into a
> > provider... Actually I think that almost all
functionality should be
> > implemented in a provider and not in core QCA...
It will be much
> > easier to configure/modify/fix/replace this way.
>
> The default provider is a QCA::Provider, but it is
compiled in and has special
> properties.  It is also configurable.  I think this is
fine for now.
>
> You can have additional root storages.  All you have to
do is claim to be a
> store of type KeyStore::System, and you can do this in
an external provider
> plugin.

So can you please enable it to be disabled by
configuration?

Thanks!
Alon.
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On Sunday 27 May 2007 10:46 pm, Alon Bar-Lev wrote:
> But I have a problem... I cannot handle any other than
RSA key without
> writing a speparate class for each algoritm...

I'll think about this more after Beta 6.

> > > Also I have an issue with requested feature.
> > > I use TokenAsker to as for "Please
insert file" 
> > > I guess we need a better solution...
> >
> > We could have more metadata for the token event,
just like how the
> > password event works.
>
> OK. Tell me what you are thinking.

Well, for example, we could reuse the fileName() field to
refer to a 
file/directory that the user needs to make available.

But first, we need to decide on how to adapt this file
concept to our existing 
use of stores.  As it is, if an entry is available, it is
used.  If an entry 
is not available, then you prompt for the store that the
entry is known to be 
contained on.  If an entry is not available, but the store
that the entry is 
known to be contained on *is* available, well...  what does
that mean?

I have two ideas to solve the above problem.  One is to make
each identity its 
own store.  That is, each one has a store, with exactly one
entry.  Then the 
token prompt would prompt for this store, and the fileName
could be a path to 
a pkcs12 file.  In this case, it would never be possible for
a store to be 
available and yet the associated single entry is not
available.

The other idea would be to make a store refer to a directory
of identities.  
The fileName would be a path to a directory.  With this
method, if the store 
is present (directory exists) and the entry doesn't (pkcs12
or other files 
don't exist), then the entry doesn't exist and can never
exist.

Both cases should work for removable devices (like USB
storage) as well as 
files on a plain hard disk.  Also, in both cases, the token
prompt concept 
should map sanely, as there is no "store is available
but entry isn't" 
problem.  I personally perfer the second method.

So, apps might prompt: "Please make directory X
available.  If this directory 
exists on a storage device, insert that device now."

Do you think that is sufficient?

> > > a. Solution that will not force me to add
each entry as separate store.
> >
> > You could have one store with many entries.  Use
storeUpdated() to
> > indicate if the entry list has changed.
>
> But then I must allocate a new id, right?
> Invalidating all current entries...
> As a result I must create my out private key cache, to
keep the ones
> that already authenticated...

When updating a store, you don't need a new store id.  You
also shouldn't need 
to invalidate any entries.  Allow the user to continue to
use old entries if 
those same objects still exist.

> > > b. Solution that will enable me to poll for
file existence, and if
> > > found report this to the asker.
> >
> > QCA::FileWatch.  Use this only for reporting
changes of the keystore. 
> > The app will do the token accept if it wishes
(like qcatool does).
>
> I don't understand how this relates to the key store...


The application uses KeyStoreManager, KeyStore, and
KeyStoreEntryWatcher to 
monitor for store and entry availability.  Token auto-accept
is performed by 
the application, based on this monitoring.

> > > I think that the trusted root certificates
should be moved into a
> > > provider... Actually I think that almost all
functionality should be
> > > implemented in a provider and not in core
QCA... It will be much
> > > easier to configure/modify/fix/replace this
way.
> >
> > The default provider is a QCA::Provider, but it is
compiled in and has
> > special properties.  It is also configurable.  I
think this is fine for
> > now.
> >
> > You can have additional root storages.  All you
have to do is claim to be
> > a store of type KeyStore::System, and you can do
this in an external
> > provider plugin.
>
> So can you please enable it to be disabled by
configuration?

Disable what?

-Justin
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On 5/28/07, Justin Karneges <justin-psi2affinix.com> wrote:
> On Sunday 27 May 2007 10:46 pm, Alon Bar-Lev wrote:
> > But I have a problem... I cannot handle any other
than RSA key without
> > writing a speparate class for each algoritm...
>
> I'll think about this more after Beta 6.

This is important to any delegate provider, also for
PKCS#11...
Also remember we talked about separating the
PKeyBase::convertToPublic
() into two classes, so the public key may be returned as-is
in
private key delegation? This is important too... remove a
lot of
code... And better abstraction.

So basically I request that a delegation provider will be
able to only
handle the private key, without caring which algorithm it
is, and not
handle any public key operation.

> Both cases should work for removable devices (like USB
storage) as well as
> files on a plain hard disk.  Also, in both cases, the
token prompt concept
> should map sanely, as there is no "store is
available but entry isn't"
> problem.  I personally perfer the second method.
>
> So, apps might prompt: "Please make directory X
available.  If this directory
> exists on a storage device, insert that device
now."
>
> Do you think that is sufficient?

I regret to say...  But no...
We have talked about this a long time ago...
I don't believe hiding available objects from user is a good
idea.

A user browse to a web server, the web server require
client
certificate, the browser enumerate available certificates,
and prompt
the user to select one.
Now... If I hide certificates because their private key is
not
available, the user will not be able to know that he is able
to select
these.
Not all users know which certificate is available on which
device...

So basically, you wanted to be user friendly, but the result
is the opposite.

I am long in favor Microsoft oriented approach... Cache
every
certificate you encouter.... Show the cache to the user,
enable the
application to query if the private key accessible, if this
is
important the application may show only accessible
cetificates.

So I know that I am opening an old issue... But please
reconsider this
issue in view of common usability.

This also applied to smartcards... If the system knows that
a
certificate exists on smartcard it should be available
during
enumeration even if the private key is unaccessable.

> When updating a store, you don't need a new store id. 
You also shouldn't need
> to invalidate any entries.  Allow the user to continue
to use old entries if
> those same objects still exist.

OK... In PKCS#11 I am doing so... As you suggested...

> > > > b. Solution that will enable me to poll
for file existence, and if
> > > > found report this to the asker.
> > >
> > > QCA::FileWatch.  Use this only for reporting
changes of the keystore.
> > > The app will do the token accept if it wishes
(like qcatool does).
> >
> > I don't understand how this relates to the key
store... 
>
> The application uses KeyStoreManager, KeyStore, and
KeyStoreEntryWatcher to
> monitor for store and entry availability.  Token
auto-accept is performed by
> the application, based on this monitoring.

But how QCA::FileWatch is related?

> > > You can have additional root storages.  All
you have to do is claim to be
> > > a store of type KeyStore::System, and you can
do this in an external
> > > provider plugin.
> >
> > So can you please enable it to be disabled by
configuration?
>
> Disable what?

The automatic load of root certificates... Or any other
internal
provider functionality.
BTW: If you have two providers that support the same
feature, tls for
example... How do you select which one will be used?

Alon.
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On Monday 28 May 2007 11:57 am, Alon Bar-Lev wrote:
> On 5/28/07, Justin Karneges <justin-psi2affinix.com> wrote:
> > Both cases should work for removable devices (like
USB storage) as well
> > as files on a plain hard disk.  Also, in both
cases, the token prompt
> > concept should map sanely, as there is no
"store is available but entry
> > isn't" problem.  I personally perfer the
second method.
> >
> > So, apps might prompt: "Please make directory
X available.  If this
> > directory exists on a storage device, insert that
device now."
> >
> > Do you think that is sufficient?
>
> I regret to say...  But no...
> We have talked about this a long time ago...
> I don't believe hiding available objects from user is a
good idea.
>
> A user browse to a web server, the web server require
client
> certificate, the browser enumerate available
certificates, and prompt
> the user to select one.
> Now... If I hide certificates because their private key
is not
> available, the user will not be able to know that he is
able to select
> these.
> Not all users know which certificate is available on
which device...
>
> So basically, you wanted to be user friendly, but the
result is the
> opposite.
>
> I am long in favor Microsoft oriented approach... Cache
every
> certificate you encouter.... Show the cache to the
user, enable the
> application to query if the private key accessible, if
this is
> important the application may show only accessible
cetificates.
>
> So I know that I am opening an old issue... But please
reconsider this
> issue in view of common usability.
>
> This also applied to smartcards... If the system knows
that a
> certificate exists on smartcard it should be available
during
> enumeration even if the private key is unaccessable.

You can show a cached list.  When the user tries to use an
entry that has an 
unavailable private key, then you prompt for him to make the
private key 
available.  This is easy with smartcards, you just prompt
for the card.

How should this be handled for files?  Do you prompt the
user for a filename?  
I was simply trying to find a way to map the token event to
the file-based 
stuff.

> > > > > b. Solution that will enable me to
poll for file existence, and if
> > > > > found report this to the asker.
> > > >
> > > > QCA::FileWatch.  Use this only for
reporting changes of the keystore.
> > > > The app will do the token accept if it
wishes (like qcatool does).
> > >
> > > I don't understand how this relates to the
key store... 
> >
> > The application uses KeyStoreManager, KeyStore,
and KeyStoreEntryWatcher
> > to monitor for store and entry availability. 
Token auto-accept is
> > performed by the application, based on this
monitoring.
>
> But how QCA::FileWatch is related?

You can use it (or perhaps DirWatch) for polling for file
existence.

> > > > You can have additional root storages. 
All you have to do is claim
> > > > to be a store of type KeyStore::System,
and you can do this in an
> > > > external provider plugin.
> > >
> > > So can you please enable it to be disabled by
configuration?
> >
> > Disable what?
>
> The automatic load of root certificates... Or any other
internal
> provider functionality.

Loading root certificates is a configuration option.
  qcatool config edit default

The only other things provided by the default provider are
sha1, md5, and 
random (based on libc rand()).  You cannot disable these,
they act as a qca 
bare minimum feature baseline.  E.g. apps don't have to
check for existence 
of their support.

> BTW: If you have two providers that support the same
feature, tls for
> example... How do you select which one will be used?

Undefined (or, technically, whichever provider is first
discovered during the 
plugin loading procedure).  There is also
setProviderPriority().  The default 
provider is always chosen as a last resort, and its priority
cannot be 
changed.

-Justin
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On 5/28/07, Justin Karneges <justin-psi2affinix.com> wrote:
> You can show a cached list.  When the user tries to use
an entry that has an
> unavailable private key, then you prompt for him to
make the private key
> available.  This is easy with smartcards, you just
prompt for the card.

I don't understand... You told me in the past to show only
existing
(inserted) cards...
If we would like to cache stores, it should not be on
provider side,
but there should be a cache provider that handle persistence
cache...

> How should this be handled for files?  Do you prompt
the user for a filename?
> I was simply trying to find a way to map the token
event to the file-based
> stuff.

Exactly!
But the idea of many store is not logical for user... He
would like to
see software store, within many certificates...

> > BTW: If you have two providers that support the
same feature, tls for
> > example... How do you select which one will be
used?
>
> Undefined (or, technically, whichever provider is first
discovered during the
> plugin loading procedure).  There is also
setProviderPriority().  The default
> provider is always chosen as a last resort, and its
priority cannot be
> changed.

I guess, priority is configurable?

Alon.
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On Monday 28 May 2007 1:06 pm, Alon Bar-Lev wrote:
> On 5/28/07, Justin Karneges <justin-psi2affinix.com> wrote:
> > You can show a cached list.  When the user tries
to use an entry that has
> > an unavailable private key, then you prompt for
him to make the private
> > key available.  This is easy with smartcards, you
just prompt for the
> > card.
>
> I don't understand... You told me in the past to show
only existing
> (inserted) cards...
> If we would like to cache stores, it should not be on
provider side,
> but there should be a cache provider that handle
persistence cache...

Oops, right, showing a cached list from a provider
perspective requires making 
the store appear to be available when it isn't, and that
conflicts with the 
token prompt (you shouldn't ever prompt for a token that is
considered 
available).

What applications can do is provide a list of known entries,
independent of 
store availability.  In fact, this is what cmssigner does.

I've put a note about caching in the TODO (my local copy),
as something to 
consider in the future.  For now, I'm content that
applications can do it 
themselves if they want to.  KDE could also put this in
kdelibs.

> > How should this be handled for files?  Do you
prompt the user for a
> > filename? I was simply trying to find a way to map
the token event to the
> > file-based stuff.
>
> Exactly!
> But the idea of many store is not logical for user...
He would like to
> see software store, within many certificates...

If the softstore is always available, then the certificates
within it must 
also always be available.  If not all certificates will be
available at the 
same time, then you will need to split this into multiple
stores.

But think about this...  practically speaking, if the certs
are on the main 
hard disk, then they are always available.  Why would some
certs, but not 
others, be unavailable?  A cert would only be unavailable if
it were on 
removable media, and in that case having the removable media
be its own store 
seems very appropriate.

This is why I suggested the use of directories for holding
certs.  Each 
directory would be a single store.  This would work very
well for both fixed 
and removable storage.

> > > BTW: If you have two providers that support
the same feature, tls for
> > > example... How do you select which one will
be used?
> >
> > Undefined (or, technically, whichever provider is
first discovered during
> > the plugin loading procedure).  There is also
setProviderPriority().  The
> > default provider is always chosen as a last
resort, and its priority
> > cannot be changed.
>
> I guess, priority is configurable?

It isn't.  Maybe I could add another option, similar to
skip_plugins, but for 
setting priorities.  I've noted this for Test 1.

-Justin
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On 5/29/07, Justin Karneges <justin-psi2affinix.com> wrote:
> Oops, right, showing a cached list from a provider
perspective requires making
> the store appear to be available when it isn't, and
that conflicts with the
> token prompt (you shouldn't ever prompt for a token
that is considered
> available).
>
> What applications can do is provide a list of known
entries, independent of
> store availability.  In fact, this is what cmssigner
does.
>
> I've put a note about caching in the TODO (my local
copy), as something to
> consider in the future.  For now, I'm content that
applications can do it
> themselves if they want to.

Well...
It is more than caching...
Returning to our old discussions....

As I see it.... There should be some keystore manager, that
provide
the keystore service... The provider should not provide
this
service...

Every time the application enumerate keystore the keystore
manager
will enumerate provider objects and return an updated list
to the
user.

The keystore service will have optionally persistent
caching.

There should be s separation between private key and public
objects,
the keystore will handle the public operation by it-self,
while the
private objects will be deserialized/serialized by
provider.

The serialization of a complete entry will be done by
keystore
service, appending the public serialization with the private
provider
serialization.

The chain complete should be performed by the keystore
service, it is
best as it is not provider specific and it can have a view
of the
complete object list gathers from many providers.

The keystore service will use a specific provider in order
to try to
complete incomplete chains, this provider will implement CRL
fetch by
CDP extension, fetch intermediates by AIA extension.

We also need a provider that return certificate status,
based on its
chain, CRL, optional CDP and CTL.

We also need CTL implementation that will enable QCA to
report a
status of a certificate based on the requested user.

I don't think the current implementation will enable users
to have
usable system without store caching, and I think providers
or too
complex because they must handle the store by them-self.
Also I think
that the chain completion is very important, and should not
be handled
by provider at all.

> If the softstore is always available, then the
certificates within it must
> also always be available.  If not all certificates will
be available at the
> same time, then you will need to split this into
multiple stores.

But then the user will see a very strange list...
Most user would like to see the list of their available
certificates... (not accessible).

> But think about this...  practically speaking, if the
certs are on the main
> hard disk, then they are always available.  Why would
some certs, but not
> others, be unavailable?  A cert would only be
unavailable if it were on
> removable media, and in that case having the removable
media be its own store
> seems very appropriate.

But a lot harder to configure and set up.
The dialog for configuring the softstore should not care
where the
keys are stored.
As does the users.

> This is why I suggested the use of directories for
holding certs.  Each
> directory would be a single store.  This would work
very well for both fixed
> and removable storage.

But again... object will be appear and disappear... I don't
think this
is best for users.

> KDE could also put this in kdelibs.

As you know, we have long way for this one...
Next attempt should be made after we complete at least the
following:
1. Add persistant working softstore.
2. Add certificate policy validation, including CTL and
OCSP.
3. Complete chain completion including including
intermediate, CRL fetching,
4. Have persistant keystore with CRL, intermediate caching.
5. Look at KDE cryptography, see what is generic and missing
in QCA
and evaluate.
6. A prompt provider, which will handle Asker prompts
automatically.
If enabled applications will not required to implement
prompt at all
(of course they will be able to override this).
7. A provider to store software keys in KWallet, for SSO.

Targets:
1. We should replace all OpenSSL code in KDE.
2. We should allow minimal use of QCA in applications (Don't
force to
register askers... etc...)
3. We should be ready to perform all our tasks by setting
up
persistence configuration (CTL, keystore).

Alon.
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On Monday 28 May 2007 10:38 pm, Alon Bar-Lev wrote:
> On 5/29/07, Justin Karneges <justin-psi2affinix.com> wrote:
> > Oops, right, showing a cached list from a provider
perspective requires
> > making the store appear to be available when it
isn't, and that conflicts
> > with the token prompt (you shouldn't ever prompt
for a token that is
> > considered available).
> >
> > What applications can do is provide a list of
known entries, independent
> > of store availability.  In fact, this is what
cmssigner does.
> >
> > I've put a note about caching in the TODO (my
local copy), as something
> > to consider in the future.  For now, I'm content
that applications can do
> > it themselves if they want to.
>
> Well...
> It is more than caching...
> Returning to our old discussions....
>
> As I see it.... There should be some keystore manager,
that provide
> the keystore service... The provider should not provide
this
> service...
>
> Every time the application enumerate keystore the
keystore manager
> will enumerate provider objects and return an updated
list to the
> user.
>
> The keystore service will have optionally persistent
caching.

As it is today, this can't work in the KeyStore system. 
With the KeyStore 
system there are stores that may or may not be available,
and a store may 
have entries.  The system can't have a store available and
its entries not 
available.  That's an illogical combination in the KeyStore
system, and yes, 
it hinders the ability to provide caching within a
provider.

However, caching can be added as an abstraction on top of
KeyStore.  As I 
mentioned, this is what cmssigner does.  If I ever decide to
add this into 
QCA, it would be done similarly, as another API layer.  I
probably wouldn't 
mess with KeyStore.

> There should be s separation between private key and
public objects,
> the keystore will handle the public operation by
it-self, while the
> private objects will be deserialized/serialized by
provider.
>
> The serialization of a complete entry will be done by
keystore
> service, appending the public serialization with the
private provider
> serialization.

Yes, these would be nice conveniences.

> The chain complete should be performed by the keystore
service, it is
> best as it is not provider specific and it can have a
view of the
> complete object list gathers from many providers.
>
> The keystore service will use a specific provider in
order to try to
> complete incomplete chains, this provider will
implement CRL fetch by
> CDP extension, fetch intermediates by AIA extension.
>
> We also need a provider that return certificate status,
based on its
> chain, CRL, optional CDP and CTL.
>
> We also need CTL implementation that will enable QCA to
report a
> status of a certificate based on the requested user.

It is not a goal of QCA to support every crypto format or
protocol in the 
world, nor is it a goal to provide an operating system
service.  What is a 
goal is allowing these things to be built with QCA.

Ideally, QCA should be configuration-free and network-free,
providing 
abstractions to the most popular algorithms and protocols,
and protecting the 
developer from ASN.1 and low-level libraries (openssl).  We
can make 
exceptions where appropriate, but these are the basic
goals.

Let's consider some future features then.  For example, what
about xmldsig?  
I'd say that should be implemented outside of QCA.  Qt has
an XML library 
anyway, so this should not be hard.  What about OSCP?  Hmm,
maybe we could 
support the packet format (to hide ASN.1), but then let the
user deal with 
transmitting it.  What about OTR?  Blah, who knows right
now.  It can be 
implemented outside of QCA anyway.

I think with every feature we consider post-2.0, we must ask
if it really 
needs to go into QCA.  I'm going to be particularly
resistant to features 
that save state to the hard disk, access the network, or
involve the GUI.

Keep in mind the kinds of projects I'm trying to support:
Psi (cross-platform, 
independent application), Leapfrog (Mac-only, doesn't use
QtGui), and KDE 
(linux platform, sharing among applications).  I hope you
can appreciate my 
stance.

> > If the softstore is always available, then the
certificates within it
> > must also always be available.  If not all
certificates will be available
> > at the same time, then you will need to split this
into multiple stores.
>
> But then the user will see a very strange list...
> Most user would like to see the list of their
available
> certificates... (not accessible).

If what you want is to show a flat list of known
certificates that may not be 
accessible, then you can't use KeyStore for this.  However,
I think showing 
cached knowns is a separate issue, and not related to
softstore specifically.  
Implement softstore as you would qca-pkcs11, and work within
the constraints 
of KeyStore.

> > KDE could also put this in kdelibs.
>
> As you know, we have long way for this one...
> Next attempt should be made after we complete at least
the following:
> 1. Add persistant working softstore.
> 2. Add certificate policy validation, including CTL and
OCSP.
> 3. Complete chain completion including including
intermediate, CRL
> fetching, 4. Have persistant keystore with CRL,
intermediate caching.
> 5. Look at KDE cryptography, see what is generic and
missing in QCA
> and evaluate.
> 6. A prompt provider, which will handle Asker prompts
automatically.
> If enabled applications will not required to implement
prompt at all
> (of course they will be able to override this).
> 7. A provider to store software keys in KWallet, for
SSO.
>
> Targets:
> 1. We should replace all OpenSSL code in KDE.
> 2. We should allow minimal use of QCA in applications
(Don't force to
> register askers... etc...)
> 3. We should be ready to perform all our tasks by
setting up
> persistence configuration (CTL, keystore).

Yes, this is a lot of work.  Certainly I won't be
responsible for this.

I want to make it clear that I agree with all of these
features "existing".  
Where I may not agree is which of these should go into QCA
itself.  For 
example, I personally already have plans to implement CRL
fetching, OSCP, GUI 
prompting, etc, in my own libraries above QCA.

-Justin
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com