[Swan-dev] notes from meeting nss guys

[Matt Rogers]

On 02/26, Paul Wouters wrote:
> On Tue, 24 Feb 2015, Matt Rogers wrote:
> 
> >Yes, the re-write uses the SQL format database which is for allowing
> >simultaneous access. Now the decoding, verification, revocation checking
> >and importing of certificates is handled by a helper program that does
> >its own initialization of what will be pluto's 'runtime' nss db in the
> >SQL format. When it imports certificates, pluto is able to pick those up
> >right away, so it works well.
> 
> When you say "runtime" you mean an ephemeral store right? I think Bob
> called this the "cached nss db". That is, the "runtime" nss.db is the
> file based nss.db plus the cached nss.db. On stop the cache is lost.
> 

Sorry, I meant a 'runtime db' as in a merged SQL copy of the /etc/ipsec.d/
db in a build configured spot (default /var/lib/pluto). Both pluto and
the helper program share this copy.
The difference with their initialization is pluto is read-only, the
helper is read-write, and pluto ends up only using the permanent items
stored in the db.
There is a ephemeral cache used by the helper process during verification.
This task involves a temporary import so a chain verification can involve
permanent db certs (i.e. loaded CA) along with the temporary ones. When the
verify succeeds the temporary objects are imported permanently, and returning
to pluto, it picks up the new objects out of the DB (by searching using the
original DER blobs). 

Matt