Dr S N Henson wrote:
Ben Laurie wrote:
Dr S N Henson wrote:
The self signed cert was only an example. There are other cases which
could apply as well. An example would be explicit trust of an EE
certificate. That isn't supported in OpenSSL yet but it will be at some
Ben Laurie wrote:
Dr S N Henson wrote:
The self signed cert was only an example. There are other cases which
could apply as well. An example would be explicit trust of an EE
certificate. That isn't supported in OpenSSL yet but it will be at some
point. It would however have a
In the full-blown PKI, you will also have things
like fetch me the cert corresponding to this name and fetch me the
key (or a handle to the key) with this fingerprint.
Remember that there are actually two independent pieces of code here -
a tab A independent shared library and a slot B
Richard Levitte - VMS Whacker wrote:
Actually, wouldn't the availability of functionality be somewhat up to
the plug-in as well? In the full-blown PKI, you will also have things
like fetch me the cert corresponding to this name and fetch me the
key (or a handle to the key) with this
Bear Giles wrote:
Remember that there are actually two independent pieces of code here -
a tab A independent shared library and a slot B library that loads
it. The latter can provide convenience wrappers to functions in the
former, avoiding the need to duplicate code in the independent part.
Dr S N Henson wrote:
I'd be reluctant to have multiple APIs handling each case. What we could
have is flags or profiles saying what a certain kind of database should
support.
OpenSSL currently has separate APIs, as opposed to flags or profiles,
for handling EVP_PKEYs, X509s and X509_CRLs
From: Oscar Jacobsson [EMAIL PROTECTED]
oscar OpenSSL currently has separate APIs, as opposed to flags or profiles,
oscar for handling EVP_PKEYs, X509s and X509_CRLs because they are
oscar fundamentally different types supporting fundamentally different
oscar operations. The stores they reside
Richard Levitte - VMS Whacker wrote:
I assume this must be a bit confusing, because we all seem to have
different ideas on what the different layers are supposed to do.
My idea is that we have three layers:
0. The application
1. The DB framework (which may or may not be part of the
Oscar Jacobsson wrote:
Dr S N Henson wrote:
I'd be reluctant to have multiple APIs handling each case. What we could
have is flags or profiles saying what a certain kind of database should
support.
OpenSSL currently has separate APIs, as opposed to flags or profiles,
for handling
From: Dr S N Henson [EMAIL PROTECTED]
stephen.henson Richard Levitte - VMS Whacker wrote:
stephen.henson
[...]
stephen.henson The plugin doen't really know what the hell we're storing. All it
has
stephen.henson is some simple schema that could fulfill most of our needs (and
that's
Richard Levitte - VMS Whacker wrote:
The only thing that troubles me then is that the plug-in (dynamically
loadable, right?) would have to share certain structures with OpenSSL,
which means that we'd better define those structures in a way that
they won't need change after they are set in
That, or have the plug-ins keep a very sharp eye on the version of the
loading OpenSSL to avoid version clashes (something we do with engines
today, sadly).
Other way around - the framework has to pay close attention to the
version of the plugin. I think the only dynamic library system that
From: Bear Giles [EMAIL PROTECTED]
bear That, or have the plug-ins keep a very sharp eye on the version of the
bear loading OpenSSL to avoid version clashes (something we do with engines
bear today, sadly).
bear
bear Other way around - the framework has to pay close attention to the
bear
From: Bear Giles [EMAIL PROTECTED]
bear This requires the API to stay
bear the same except for added functions, and for types and structures to
bear never change (except for adding new types and new structures).
bear
bear But the flip side, which is what I was referring to, is when the
bear
bear In contrast, with a plug-in the framework itself acts as the loader,
bear and it must detect mising symbols in older shared libraries. Depending
bear on the way it's hooked, it either has to resolve each symbol individually
bear or a single structure and then check the version number.
On Unix as well as on VMS and others, it's
often possible to upgrade a shareable library to a newer version
without breaking the programs using it.
Of course.
This requires the API to stay
the same except for added functions, and for types and structures to
never change (except for adding
So how would protection against such bad data be done at the database
level?
If you know it's a CA cert repository, you can require that the issuer
already be in the database.
If this a deferrable constraint, you can still add root certs (e.g., to
populate the database.) But if you remove
Bear Giles wrote:
And from a pragmatic perspective, whole-cert hashes make a lot of sense.
NB: I've only ever messed about with relational databases for a brief
spell a few years back, so please excuse my struggling with the
terminology.
As primary keys go, I'm certain that whole-cert hashes
As primary keys go, I'm certain that whole-cert hashes would come in
quite handy.
It's a mindset thing. A key should lead you to more information.
Give me your name, I'll tell you your phone number and home address.
Read off the tag on the back of the car and I'll tell you the make
and
Dr S N Henson wrote:
Bear Giles wrote:
If it only did an I+SN match then an attacker could readily generate a
self-signed certificate using its own key with matching I+SN.
But a self-signed cert is easily identified and could be flagged
for special handling. By removing them
Bear Giles wrote:
But a plug-in that transparently updated a smart card would be extremely
handy. :-) That's what makes the design so hard - it needs to be able
to handle everything from 8k smart cards holding a single veiled key and
cert to RDBMS databases with 50,000+ entries.
I think the
It's easy for me to say, since I'm not doing the work, but I think
Oscar's correct.
/r$
--
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com
__
OpenSSL Project
Oscar Jacobsson wrote:
Bear Giles wrote:
But a plug-in that transparently updated a smart card would be extremely
handy. :-) That's what makes the design so hard - it needs to be able
to handle everything from 8k smart cards holding a single veiled key and
cert to RDBMS databases with
From: Oscar Jacobsson [EMAIL PROTECTED]
oscar I think the design would be made needlessly complex by mandating this
oscar scalability.
oscar
oscar The use cases needed for your smart card API would be, say: encrypt
oscar this, decrypt this, sign this, verify this. This is what Cryptoki
oscar
Bear Giles wrote:
Of course, this opens the whole can-o-worms of what constitutes
a duplicate cert? Is it an exact match, or matching I+SN, or
some other criteria?
There are some cases where only an exact match is acceptable. An example
is how OpenSSL performs a verify operation on
Bear Giles wrote:
To avoid duplication of code I'd say such concerns should be addressed
either at the application level or on top of whatever OpenSSL plugin API
is adopted.
I think that would be a serious mistake. I'm specifically thinking
of something like the CA cert
Richard Levitte - VMS Whacker wrote:
From: Bear Giles [EMAIL PROTECTED]
bear Of course, this opens the whole can-o-worms of what constitutes
bear a duplicate cert? Is it an exact match, or matching I+SN, or
bear some other criteria?
Depending on who you listen to, one could say
Bear Giles wrote:
If it only did an I+SN match then an attacker could readily generate a
self-signed certificate using its own key with matching I+SN.
But a self-signed cert is easily identified and could be flagged
for special handling. By removing them from the standard population
Bear Giles wrote:
Nothing. The trust settings aren't part of the certificate encoding. The
current trust handling stores these after the main encoding only if the
*TRUST() functions are used.
As an aside my postgresql stuff currently uses the standard X509 routines
when converting
Bear Giles wrote:
What would you classify as bad data in this case?
A fake root cert and HTTPS certs. Then you do a DNS attack, the victims
get the blackhat HTTPS site but when they check the public cert respository
it comes back with a full cert chain.
Ditto bad object signing
To avoid duplication of code I'd say such concerns should be addressed
either at the application level or on top of whatever OpenSSL plugin API
is adopted.
I think that would be a serious mistake. I'm specifically thinking
of something like the CA cert repository/JSP code in my postgresql
I can imagine that one might get the same certificate
from several source, but I'm pretty sure it could be resolved but
applying a little bit of automagic intelligence and tossing all
duplicates except for the copy that has the highest trust attached to
it.
I was assuming this would be done
From: Bear Giles [EMAIL PROTECTED]
bear Of course, this opens the whole can-o-worms of what constitutes
bear a duplicate cert? Is it an exact match, or matching I+SN, or
bear some other criteria?
Depending on who you listen to, one could say it's the subject, others
will say it's
Bear Giles wrote:
To avoid duplication of code I'd say such concerns should be addressed
either at the application level or on top of whatever OpenSSL plugin API
is adopted.
I think that would be a serious mistake. I'm specifically thinking
of something like the CA cert
From: Dr S N Henson [EMAIL PROTECTED]
stephen.henson Is there some specific reason why the API should
stephen.henson return a key at all and not just the certificate (or
stephen.henson whatever) it corresponds to?
You might want to store keys alone for different reasons. Let's
remember that
Richard Levitte - VMS Whacker wrote:
From: Dr S N Henson [EMAIL PROTECTED]
stephen.henson Is there some specific reason why the API should
stephen.henson return a key at all and not just the certificate (or
stephen.henson whatever) it corresponds to?
You might want to store keys alone
Richard Levitte - VMS Whacker wrote:
From: Bear Giles [EMAIL PROTECTED]
bear Of course, this opens the whole can-o-worms of what constitutes
bear a duplicate cert? Is it an exact match, or matching I+SN, or
bear some other criteria?
Depending on who you listen to, one could say it's the
Bear Giles wrote:
Of course, this opens the whole can-o-worms of what constitutes
a duplicate cert? Is it an exact match, or matching I+SN, or
some other criteria?
There are some cases where only an exact match is acceptable. An example
is how OpenSSL performs a verify operation on a
Dr S N Henson wrote:
[...]
saying it doesn't understand the method. This maps well to the ASN1
CHOICE type which is represented as:
struct {
int type;
union {
TYPE1 *a;
TYPE2 *b;
TYPE3 *c;
/* etc */
From: Massimiliano Pala [EMAIL PROTECTED]
madwolf I have not followed the discussion from the beginning, but have you
madwolf considered supporting BerkeleyDB ? We have, for our project, two
madwolf different modules one supporting SQL DBMS and the other using
madwolf BerkeleyDB as backend (one
Not true. I've searched on the hash of the certificate when we are
producing certificates that must maintain privacy and therefore have
garbage in the Issuer and Subject fields.
Maybe I'm just dense, but I don't get this. If you simply mask the
issuer and subject fields, e.g., using a
Issuer and subject number should also be unique, and it's a common
search pattern. I don't think anyone searches on the hash of the
entire certificate.
It should be unique but it might not be, either by accident or malicious
intent.
This indirectly raises a question we've been
Bear Giles wrote:
Issuer and subject number should also be unique, and it's a common
search pattern. I don't think anyone searches on the hash of the
entire certificate.
It should be unique but it might not be, either by accident or malicious
intent.
This indirectly raises a
From: Dr S N Henson [EMAIL PROTECTED]
stephen.henson My point was that in some applications certificates
stephen.henson may be added from an untrusted source. An example
stephen.henson would be an S/MIME application which adds certificates
stephen.henson for later use from S/MIME messages. It
One classic approach is to have all lookup functions return a
list of unique keys. The caller then requests each object individually
via a lookup that guarantees uniqueness. Uniqueness is easy to guarantee
on any hashed or relational store - make it the primary key!
An earlier
Issuer and subject number should also be unique, and it's a common
search pattern. I don't think anyone searches on the hash of the
entire certificate.
Not true. I've searched on the hash of the certificate when we are
producing certificates that must maintain privacy and therefore have
Bear Giles wrote:
One classic approach is to have all lookup functions return a
list of unique keys. The caller then requests each object individually
via a lookup that guarantees uniqueness. Uniqueness is easy to guarantee
on any hashed or relational store - make it the primary
Bear Giles wrote:
I'll dig out the code. It was largely based around the PKCS#11
functionality but with an OpenSSL flavour. That is you have a load of
objects each of which is a set of attributes. You can then lookup based
on exact matches of each attribute.
This is query by example.
Discussion moved from openssl-users...
Bear Giles wrote:
I can think of multiple
common storage formats: text files, DBM files, LDAP, RDBMS.
why not use an existing database abstraction layer such as libdbi or ODBC?
Too abstract - queries are done with SQL statements. That's not
From: Dr S N Henson [EMAIL PROTECTED]
stephen.henson I've done some work on this but its only partly
stephen.henson complete and sitting in a dark corner of my hard
stephen.henson drive...
I'm curious to see what you've come up with so far.
stephen.henson BTW can we move this to openssl-dev?
H, this doesn't seem to have made it to the list. No doubt there
will be two copies now :-)
Bear Giles wrote:
I can think of multiple
common storage formats: text files, DBM files, LDAP, RDBMS.
why not use an existing database abstraction layer such as libdbi or ODBC?
Too
Richard Levitte - VMS Whacker wrote:
From: Dr S N Henson [EMAIL PROTECTED]
stephen.henson I've done some work on this but its only partly
stephen.henson complete and sitting in a dark corner of my hard
stephen.henson drive...
I'm curious to see what you've come up with so far.
I'll
I'll dig out the code. It was largely based around the PKCS#11
functionality but with an OpenSSL flavour. That is you have a load of
objects each of which is a set of attributes. You can then lookup based
on exact matches of each attribute.
This is query by example. It has some benefits,
53 matches
Mail list logo
