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
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
> 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 a
> 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 nu
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
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
> 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 tha
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 s
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:
>
>
> 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
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 ha
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 res
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 be
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 independen
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 fi
> 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
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
os
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 datab
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
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
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. B
> 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 mod
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 w
> 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:
>
> > 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 sig
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 pop
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 conve
> 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 liste
> 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
> 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
> 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 from internal to external f
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
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 coul
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 sto
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 t
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 repo
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 issuer+
> 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
> 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
Bear Giles wrote:
>
>
> > Trust, BTW, could rather easily be handled by attaching internal
> > attributes to certificates with extra information. Those attributes
> > are not part of the certificate itself, of course. Was that
> > approximately the way you saw this being done as well?
>
> Wha
Richard Levitte - VMS Whacker wrote:
>
> 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
>
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.
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 ind
> 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 SN
> > 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
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
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 *
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 t
> 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
> > 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 earli
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
> 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 benefit
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 f
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?
>
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-d
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.
56 matches
Mail list logo
