[openssl-dev] (future) STORE vs X509_LOOKUP_METHOD by_dir

[Roumen Petrov]

Hi Richard,

Richard Levitte wrote:
> Hi,
>
> I've some ponderings that I need to bounce a bit with you all.
>
> Some have talked about replace the X509_LOOKUP_METHOD
X.509 lookup method could return certificate , revocation list or 
EVP_KEY (structure x509_object_st).

Unfortunately   functionality of EVP_KEY was never implemented.
Another point is specific names of structures - x509_lookup_method_st , 
x509_lookup_st, x509_object_st.
Third point is quite specific implementation - functions not just to 
retrieve objects( X.509 or CRL) but to fill them into "context of X509 
store".

Current lookup functionality look like "store" but implementation is 
specific to X.509 store.


> bit with the
> STORE module I'm building, and while STORE isn't ready for it yet

I hope that you store functionality will fill gap between load of keys 
and load of certificates (+crl).

Loadable module (engine) has interface to load key(private or public)  
but lack load of X.509 certificates or CRL.


> , I
> have some thoughts on how the two can approach each other.  This would
> involve one or two hooks / callbacks, that a STORE user could specify
> (details later) to pick and choose freely among the objects that the
> STORE module finds (be it on file or whatever else that can be
> represented as a URI).
I think that functionality requires three phases :
1) instantiation : at this point store is created
2) specification (optional):  set or check capability of store. For 
instance store could return only X.509 certificates or to request store 
to return only keys.
3) inquiry: fetch data based on specified criteria.

> The troublesome part would be to try to mimic by_dir...  It highly
> depends on the specified paths to really be directories, and that it
> should find what it wants by adding very specific file names (a hash
> of the subject name with a ".{n}" or ".r{n}" extension for X.509 certs
> and for X.509 CRLs).  And sure, that works, but will really only work
> with regular files.
I'm not sure what is issue.

Lets see X.509 lookup method get_by_subject.

- by_dir
2) specification : set directory(path), limit results to X.509 or CRL 
and may be to inform store that questions will be performed by subject.

For instance URI scheme could befile://path?certificate="name"

3) query : from subject calculate hash and then process "{hash}.{n}" or 
"{hash}.r{n}" depending from URI

- Ldap
It is similar, URI is described in RFCs - at point 2) set host, port, base distinguished name, attribute (for instance cACertificate), construct filter from specified name.



> What if someone would specify a LDAP URI that can return a bunch of
> objects?
>
> So...  my ponderings are going along these lines:
>
> 1. Should the directory X509_LOOKUPs be restricted to on disk
>     directories, or should "directory" be redefined as "whatever URI
>     that returns a collection of objects"?  The latter would mean that
>     all those objects get loaded and that a hook / callback would then
>     be called to check if it's an object that corresponds to what we
>     search for.
I think that replacement of "by_dir" lookup has to be restricted to file 
system operation.
Files could be located on network, memory not only on disk.


> 2. For on disk directories, should we preserve the rehash file form?
>     In other words, if we decide to load everything we can find, shall
>     we restrict the loading to files matching the regexp
>     [0-9a-f]{8}\.r?[0-9]+  ?  If not, are we about to create a new form
>     of key store for ourselves and our users?  Should we?

For hash-dir please keep current file name format.

> Quite a lot also depends on what OpenSSL version we aim for.  I would
> very much like to see the STORE module itself become part of 1.1.1,
> but a new key store to replace our current rehash links will obviously
> have to wait 'til 1.2.0.
>
> Cheers,
> Richard
>
Roumen