Discussion:
Certificate store for cross platform designs
Sid Shetye
2013-11-12 18:42:56 UTC
Permalink
Hi folks,



Although we do use BC for some crypto stuff, we haven't explored anything
beyond the standard Windows cert store for certificate storage. So at
present we use the Windows certificate store as:



var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);

store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);

var certs = store.Certificates.Find(X509FindType.FindBySubjectName,
subjectName, true);



We'd like to switch to something that's more cross platform (esp Linux
compatible). What are some good design patterns for a secure, cross platform
certificate storage? We need to store RSA and EC certificates as well as
their respective private keys (if they exist in the password protected PFX).



Regards

Sid
Jeff Stedfast
2013-11-12 19:04:30 UTC
Permalink
Hi Sid,

I asked this question just last week ;-)

What I ended up doing is to use a pkcs12 file to store private certs/keys
and a file containing unencrypted certs for everything else (like CAs and
such).

If you come up with a better way, I'd appreciate if you let me know. I'm
working on a cross-platform (Windows, Mac, Linux, iOS, and Android) MIME
library with support for S/MIME and PGP, so am really interested in a
cross-platform way of managing certificates.

You can find my current cross-platform certificate management logic here:
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/DefaultSecureMimeContext.cs#L104

and here:
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/X509CertificateStore.cs

The first link creates 2 X509CertificateStores, one for root certificates
and one for user certs (equivalent, I suppose, of StoreName.Root and
StoreName.My). I should probably also have something equivalent to
StoreName.AddressBook, but right now they are stored in the pkcs12 file
along with the user's other personal certificates.

Hope that helps,

Jeff
Post by Sid Shetye
Hi folks,
Although we do use BC for some crypto stuff, we haven’t explored anything
beyond the standard Windows cert store for certificate storage. So at
var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);
var certs = store.Certificates.Find(X509FindType.FindBySubjectName,
subjectName, true);
We’d like to switch to something that’s more cross platform (esp Linux
compatible). What are some good design patterns for a secure, cross
platform certificate storage? We need to store RSA and EC certificates as
well as their respective private keys (if they exist in the password
protected PFX).
Regards
Sid
Sid Shetye
2013-11-12 19:35:16 UTC
Permalink
Thanks Jeff.



Taking a step back before jumping into library details, did you find any
other alternatives before deciding to have your own cert store
implementation? I ask because it seems odd (to me) that you and I would be
the first ones to face the “cross platform certificate store” problem –
surely someone else might have solved this before. Especially in the Bouncy
Castle community? That’s my (perhaps naïve) thinking. So would appreciate if
you could share your learnings on this topic (and great job on the GitHub
repo!)



Regards,

Sid



From: Jeff Stedfast [mailto:jeff-***@public.gmane.org]
Sent: Tuesday, November 12, 2013 11:05 AM
To: Sid Shetye
Cc: Bouncy Castle Developer List
Subject: Re: [dev-crypto-csharp] Certificate store for cross platform
designs



Hi Sid,



I asked this question just last week ;-)



What I ended up doing is to use a pkcs12 file to store private certs/keys
and a file containing unencrypted certs for everything else (like CAs and
such).



If you come up with a better way, I'd appreciate if you let me know. I'm
working on a cross-platform (Windows, Mac, Linux, iOS, and Android) MIME
library with support for S/MIME and PGP, so am really interested in a
cross-platform way of managing certificates.



You can find my current cross-platform certificate management logic here:
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/Defaul
tSecureMimeContext.cs#L104



and here:
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/X509Ce
rtificateStore.cs



The first link creates 2 X509CertificateStores, one for root certificates
and one for user certs (equivalent, I suppose, of StoreName.Root and
StoreName.My). I should probably also have something equivalent to
StoreName.AddressBook, but right now they are stored in the pkcs12 file
along with the user's other personal certificates.



Hope that helps,



Jeff



On Tue, Nov 12, 2013 at 1:42 PM, Sid Shetye <sid314-1ViLX0X+***@public.gmane.org
<mailto:sid314-1ViLX0X+***@public.gmane.org> > wrote:

Hi folks,



Although we do use BC for some crypto stuff, we haven’t explored anything
beyond the standard Windows cert store for certificate storage. So at
present we use the Windows certificate store as:



var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);

store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);

var certs = store.Certificates.Find(X509FindType.FindBySubjectName,
subjectName, true);



We’d like to switch to something that’s more cross platform (esp Linux
compatible). What are some good design patterns for a secure, cross platform
certificate storage? We need to store RSA and EC certificates as well as
their respective private keys (if they exist in the password protected PFX).



Regards

Sid
Jaroslav Imrich
2013-11-12 21:45:40 UTC
Permalink
Hello Sid,

currently there is no "standard certificate store" available on Linux.
Almost every application (cryptographic library) uses its own solution but
there is an ongoing effort to solve this sad situation in p11-glue project
[0] that promotes PKCS#11 as a glue between crypto libraries and security
applications. I think you should take a look at its two suprojects P11-Kit
[1] and TrustModule [2]. PKCS#11 interface is nowadays supported by almost
every smartcard/HSM middleware and there are also pure software modules
available such as SoftHSM [3] or NSS Internal PKCS#11 module (used by
Mozilla products). Unmanaged PKCS#11 modules can be easily interfaced in C#
via managed wrappers such as Pkcs11Interop [4]. Full disclosure: I am the
author of Pkcs11Interop :)

However if you are looking for a quickest, easy to understand, easy to
implement and "truly" cross-platform solution (Android and iOS included)
you will probably end up with something very similar to Jeff's solution
with PKCS#12 file.

[0] http://p11-glue.freedesktop.org/
[1] http://p11-glue.freedesktop.org/p11-kit.html
[2] http://p11-glue.freedesktop.org/trust-module.html
[3] http://www.opendnssec.org/softhsm/
[4] http://pkcs11interop.net/
--
Kind Regards / S pozdravom

Jaroslav Imrich
http://www.jimrich.sk
Post by Sid Shetye
Thanks Jeff.
Taking a step back before jumping into library details, did you find any
other alternatives before deciding to have your own cert store
implementation? I ask because it seems odd (to me) that you and I would be
the first ones to face the “cross platform certificate store” problem –
surely someone else might have solved this before. Especially in the Bouncy
Castle community? That’s my (perhaps naïve) thinking. So would appreciate
if you could share your learnings on this topic (and great job on the
GitHub repo!)
Regards,
Sid
*Sent:* Tuesday, November 12, 2013 11:05 AM
*To:* Sid Shetye
*Cc:* Bouncy Castle Developer List
*Subject:* Re: [dev-crypto-csharp] Certificate store for cross platform
designs
Hi Sid,
I asked this question just last week ;-)
What I ended up doing is to use a pkcs12 file to store private certs/keys
and a file containing unencrypted certs for everything else (like CAs and
such).
If you come up with a better way, I'd appreciate if you let me know. I'm
working on a cross-platform (Windows, Mac, Linux, iOS, and Android) MIME
library with support for S/MIME and PGP, so am really interested in a
cross-platform way of managing certificates.
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/DefaultSecureMimeContext.cs#L104
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/X509CertificateStore.cs
The first link creates 2 X509CertificateStores, one for root certificates
and one for user certs (equivalent, I suppose, of StoreName.Root and
StoreName.My). I should probably also have something equivalent to
StoreName.AddressBook, but right now they are stored in the pkcs12 file
along with the user's other personal certificates.
Hope that helps,
Jeff
Hi folks,
Although we do use BC for some crypto stuff, we haven’t explored anything
beyond the standard Windows cert store for certificate storage. So at
var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);
var certs = store.Certificates.Find(X509FindType.FindBySubjectName,
subjectName, true);
We’d like to switch to something that’s more cross platform (esp Linux
compatible). What are some good design patterns for a secure, cross
platform certificate storage? We need to store RSA and EC certificates as
well as their respective private keys (if they exist in the password
protected PFX).
Regards
Sid
Jeff Stedfast
2013-11-23 14:44:11 UTC
Permalink
Okay... I've broken down and implemented a SQLite database for storing
certificates (along with the S/MIME Capabilities for the clients associated
with each certificate - this is needed to properly determine which
encryption algorithm to use) and the CRLs.

It was just getting to be too much of a PITA to store each of these things
in different files and manage relationships between them.

That said... I don't know a whole lot about CRLs and want to get this
correct.

Can I assume that X509Crl's with an identical IssuerDN and a newer
ThisUpdate replaces an older X509Crl with the same IssuerDN?

Or do I just need to keep collecting CRLs?

In other words: if I have an X509Crl with an IssuerDN of "XYZ" and a
ThisUpdate of "Yesterday", would an X509Crl with an issuerDN of "XYZ" and a
ThisUpdate of "Today" contain the same list of certificates (plus any new
ones) as the first CRL?

Thanks,

Jeff


On Tue, Nov 12, 2013 at 4:45 PM, Jaroslav Imrich
Post by Jaroslav Imrich
Hello Sid,
currently there is no "standard certificate store" available on Linux.
Almost every application (cryptographic library) uses its own solution but
there is an ongoing effort to solve this sad situation in p11-glue project
[0] that promotes PKCS#11 as a glue between crypto libraries and security
applications. I think you should take a look at its two suprojects P11-Kit
[1] and TrustModule [2]. PKCS#11 interface is nowadays supported by almost
every smartcard/HSM middleware and there are also pure software modules
available such as SoftHSM [3] or NSS Internal PKCS#11 module (used by
Mozilla products). Unmanaged PKCS#11 modules can be easily interfaced in C#
via managed wrappers such as Pkcs11Interop [4]. Full disclosure: I am the
author of Pkcs11Interop :)
However if you are looking for a quickest, easy to understand, easy to
implement and "truly" cross-platform solution (Android and iOS included)
you will probably end up with something very similar to Jeff's solution
with PKCS#12 file.
[0] http://p11-glue.freedesktop.org/
[1] http://p11-glue.freedesktop.org/p11-kit.html
[2] http://p11-glue.freedesktop.org/trust-module.html
[3] http://www.opendnssec.org/softhsm/
[4] http://pkcs11interop.net/
--
Kind Regards / S pozdravom
Jaroslav Imrich
http://www.jimrich.sk
Post by Sid Shetye
Thanks Jeff.
Taking a step back before jumping into library details, did you find any
other alternatives before deciding to have your own cert store
implementation? I ask because it seems odd (to me) that you and I would be
the first ones to face the “cross platform certificate store” problem –
surely someone else might have solved this before. Especially in the Bouncy
Castle community? That’s my (perhaps naïve) thinking. So would appreciate
if you could share your learnings on this topic (and great job on the
GitHub repo!)
Regards,
Sid
*Sent:* Tuesday, November 12, 2013 11:05 AM
*To:* Sid Shetye
*Cc:* Bouncy Castle Developer List
*Subject:* Re: [dev-crypto-csharp] Certificate store for cross platform
designs
Hi Sid,
I asked this question just last week ;-)
What I ended up doing is to use a pkcs12 file to store private certs/keys
and a file containing unencrypted certs for everything else (like CAs and
such).
If you come up with a better way, I'd appreciate if you let me know. I'm
working on a cross-platform (Windows, Mac, Linux, iOS, and Android) MIME
library with support for S/MIME and PGP, so am really interested in a
cross-platform way of managing certificates.
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/DefaultSecureMimeContext.cs#L104
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/X509CertificateStore.cs
The first link creates 2 X509CertificateStores, one for root certificates
and one for user certs (equivalent, I suppose, of StoreName.Root and
StoreName.My). I should probably also have something equivalent to
StoreName.AddressBook, but right now they are stored in the pkcs12 file
along with the user's other personal certificates.
Hope that helps,
Jeff
Hi folks,
Although we do use BC for some crypto stuff, we haven’t explored anything
beyond the standard Windows cert store for certificate storage. So at
var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);
var certs = store.Certificates.Find(X509FindType.FindBySubjectName,
subjectName, true);
We’d like to switch to something that’s more cross platform (esp Linux
compatible). What are some good design patterns for a secure, cross
platform certificate storage? We need to store RSA and EC certificates as
well as their respective private keys (if they exist in the password
protected PFX).
Regards
Sid
David Hook
2013-11-23 23:01:06 UTC
Permalink
It's a bit of both, some CRLs constitute full updates, others are
referred to as "delta CRLs", and represent a set of changes, so in the
situation where you have a delta CRL your actual set of revocations is
("update CRL" + "delta CRL 1" + "delta CRL 2"...).

A delta CRL is indicated by the Delta CRL Indicator - an extension
defined in section 5.2.4 of RFC 5280

One other thing that might help, if you're not doing it already, are you
using any of the CertPath support in BC C#? Validating a certificate
properly involves a lot more than checking a signature and a CRL. The
CertPath code is an attempt to deal with the now 151 pages of RFC 5280.

Regards,

David
Post by Jeff Stedfast
Okay... I've broken down and implemented a SQLite database for storing
certificates (along with the S/MIME Capabilities for the clients
associated with each certificate - this is needed to properly
determine which encryption algorithm to use) and the CRLs.
It was just getting to be too much of a PITA to store each of these
things in different files and manage relationships between them.
That said... I don't know a whole lot about CRLs and want to get this
correct.
Can I assume that X509Crl's with an identical IssuerDN and a newer
ThisUpdate replaces an older X509Crl with the same IssuerDN?
Or do I just need to keep collecting CRLs?
In other words: if I have an X509Crl with an IssuerDN of "XYZ" and a
ThisUpdate of "Yesterday", would an X509Crl with an issuerDN of "XYZ"
and a ThisUpdate of "Today" contain the same list of certificates
(plus any new ones) as the first CRL?
Thanks,
Jeff
On Tue, Nov 12, 2013 at 4:45 PM, Jaroslav Imrich
Hello Sid,
currently there is no "standard certificate store" available on
Linux. Almost every application (cryptographic library) uses its
own solution but there is an ongoing effort to solve this sad
situation in p11-glue project [0] that promotes PKCS#11 as a glue
between crypto libraries and security applications. I think you
should take a look at its two suprojects P11-Kit [1] and
TrustModule [2]. PKCS#11 interface is nowadays supported by almost
every smartcard/HSM middleware and there are also pure software
modules available such as SoftHSM [3] or NSS Internal PKCS#11
module (used by Mozilla products). Unmanaged PKCS#11 modules can
be easily interfaced in C# via managed wrappers such as
Pkcs11Interop [4]. Full disclosure: I am the author of
Pkcs11Interop :)
However if you are looking for a quickest, easy to understand,
easy to implement and "truly" cross-platform solution (Android and
iOS included) you will probably end up with something very similar
to Jeff's solution with PKCS#12 file.
[0] http://p11-glue.freedesktop.org/
[1] http://p11-glue.freedesktop.org/p11-kit.html
[2] http://p11-glue.freedesktop.org/trust-module.html
[3] http://www.opendnssec.org/softhsm/
[4] http://pkcs11interop.net/
--
Kind Regards / S pozdravom
Jaroslav Imrich
http://www.jimrich.sk <http://www.jimrich.sk/>
Thanks Jeff.
Taking a step back before jumping into library details, did
you find any other alternatives before deciding to have your
own cert store implementation? I ask because it seems odd (to
me) that you and I would be the first ones to face the “cross
platform certificate store” problem – surely someone else
might have solved this before. Especially in the Bouncy Castle
community? That’s my (perhaps naïve) thinking. So would
appreciate if you could share your learnings on this topic
(and great job on the GitHub repo!)
Regards,
Sid
*Sent:* Tuesday, November 12, 2013 11:05 AM
*To:* Sid Shetye
*Cc:* Bouncy Castle Developer List
*Subject:* Re: [dev-crypto-csharp] Certificate store for cross
platform designs
Hi Sid,
I asked this question just last week ;-)
What I ended up doing is to use a pkcs12 file to store private
certs/keys and a file containing unencrypted certs for
everything else (like CAs and such).
If you come up with a better way, I'd appreciate if you let me
know. I'm working on a cross-platform (Windows, Mac, Linux,
iOS, and Android) MIME library with support for S/MIME and
PGP, so am really interested in a cross-platform way of
managing certificates.
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/DefaultSecureMimeContext.cs#L104
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/X509CertificateStore.cs
The first link creates 2 X509CertificateStores, one for root
certificates and one for user certs (equivalent, I suppose, of
StoreName.Root and StoreName.My). I should probably also have
something equivalent to StoreName.AddressBook, but right now
they are stored in the pkcs12 file along with the user's other
personal certificates.
Hope that helps,
Jeff
On Tue, Nov 12, 2013 at 1:42 PM, Sid Shetye
Hi folks,
Although we do use BC for some crypto stuff, we haven’t
explored anything beyond the standard Windows cert store
for certificate storage. So at present we use the Windows
varstore = new X509Store(StoreName.My,
StoreLocation.LocalMachine);
store.Open(OpenFlags.OpenExistingOnly |
OpenFlags.ReadOnly);
var certs =
store.Certificates.Find(X509FindType.FindBySubjectName,
subjectName, true);
We’d like to switch to something that’s more cross
platform (esp Linux compatible). What are some good design
patterns for a secure, cross platform certificate storage?
We need to store RSA and EC certificates as well as their
respective private keys (if they exist in the password
protected PFX).
Regards
Sid
Jeff Stedfast
2013-11-24 00:18:59 UTC
Permalink
Hi David,

Thanks for the info!

Yes, I'm already using the PkixCertPathBuiler to get a certificate chain
and storing that on my "SecureMimeDigitalSignature" class that consumers of
my library can access and validate.

If you are interested, I would appreciate hearing your (or anyone else's on
this list) thoughts on my S/MIME implementation so far at
https://github.com/jstedfast/MimeKit

The S/MIME stuff is all in MimeKit/Cryptography/*

SecureMimeContext is the base class that does all of the
encryption/decryption/signing/verifying/etc and has abstract methods for
subclasses to implement for things like certificate, crl and private key
lookups and other management of those things.

The code I'm working on now is DefaultSecureMimeContext (it used to use
.p12 files and a flat file of crls, but I had no way of storing S/MIME
capabilities so gave up and am now re-implementing it using the
X509CertificateDatabase class to store everything I need).

Thanks to your answer to my question, my next step will be to get the CRL
storage correct.

Jeff
It's a bit of both, some CRLs constitute full updates, others are referred
to as "delta CRLs", and represent a set of changes, so in the situation
where you have a delta CRL your actual set of revocations is ("update CRL"
+ "delta CRL 1" + "delta CRL 2"...).
A delta CRL is indicated by the Delta CRL Indicator - an extension defined
in section 5.2.4 of RFC 5280
One other thing that might help, if you're not doing it already, are you
using any of the CertPath support in BC C#? Validating a certificate
properly involves a lot more than checking a signature and a CRL. The
CertPath code is an attempt to deal with the now 151 pages of RFC 5280.
Regards,
David
Okay... I've broken down and implemented a SQLite database for storing
certificates (along with the S/MIME Capabilities for the clients associated
with each certificate - this is needed to properly determine which
encryption algorithm to use) and the CRLs.
It was just getting to be too much of a PITA to store each of these
things in different files and manage relationships between them.
That said... I don't know a whole lot about CRLs and want to get this
correct.
Can I assume that X509Crl's with an identical IssuerDN and a newer
ThisUpdate replaces an older X509Crl with the same IssuerDN?
Or do I just need to keep collecting CRLs?
In other words: if I have an X509Crl with an IssuerDN of "XYZ" and a
ThisUpdate of "Yesterday", would an X509Crl with an issuerDN of "XYZ" and a
ThisUpdate of "Today" contain the same list of certificates (plus any new
ones) as the first CRL?
Thanks,
Jeff
On Tue, Nov 12, 2013 at 4:45 PM, Jaroslav Imrich <
Post by Jaroslav Imrich
Hello Sid,
currently there is no "standard certificate store" available on Linux.
Almost every application (cryptographic library) uses its own solution but
there is an ongoing effort to solve this sad situation in p11-glue project
[0] that promotes PKCS#11 as a glue between crypto libraries and security
applications. I think you should take a look at its two suprojects P11-Kit
[1] and TrustModule [2]. PKCS#11 interface is nowadays supported by almost
every smartcard/HSM middleware and there are also pure software modules
available such as SoftHSM [3] or NSS Internal PKCS#11 module (used by
Mozilla products). Unmanaged PKCS#11 modules can be easily interfaced in C#
via managed wrappers such as Pkcs11Interop [4]. Full disclosure: I am the
author of Pkcs11Interop :)
However if you are looking for a quickest, easy to understand, easy to
implement and "truly" cross-platform solution (Android and iOS included)
you will probably end up with something very similar to Jeff's solution
with PKCS#12 file.
[0] http://p11-glue.freedesktop.org/
[1] http://p11-glue.freedesktop.org/p11-kit.html
[2] http://p11-glue.freedesktop.org/trust-module.html
[3] http://www.opendnssec.org/softhsm/
[4] http://pkcs11interop.net/
--
Kind Regards / S pozdravom
Jaroslav Imrich
http://www.jimrich.sk
Post by Sid Shetye
Thanks Jeff.
Taking a step back before jumping into library details, did you find any
other alternatives before deciding to have your own cert store
implementation? I ask because it seems odd (to me) that you and I would be
the first ones to face the “cross platform certificate store” problem –
surely someone else might have solved this before. Especially in the Bouncy
Castle community? That’s my (perhaps naïve) thinking. So would appreciate
if you could share your learnings on this topic (and great job on the
GitHub repo!)
Regards,
Sid
*Sent:* Tuesday, November 12, 2013 11:05 AM
*To:* Sid Shetye
*Cc:* Bouncy Castle Developer List
*Subject:* Re: [dev-crypto-csharp] Certificate store for cross platform
designs
Hi Sid,
I asked this question just last week ;-)
What I ended up doing is to use a pkcs12 file to store private
certs/keys and a file containing unencrypted certs for everything else
(like CAs and such).
If you come up with a better way, I'd appreciate if you let me know. I'm
working on a cross-platform (Windows, Mac, Linux, iOS, and Android) MIME
library with support for S/MIME and PGP, so am really interested in a
cross-platform way of managing certificates.
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/DefaultSecureMimeContext.cs#L104
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/X509CertificateStore.cs
The first link creates 2 X509CertificateStores, one for root
certificates and one for user certs (equivalent, I suppose, of
StoreName.Root and StoreName.My). I should probably also have something
equivalent to StoreName.AddressBook, but right now they are stored in the
pkcs12 file along with the user's other personal certificates.
Hope that helps,
Jeff
Hi folks,
Although we do use BC for some crypto stuff, we haven’t explored
anything beyond the standard Windows cert store for certificate storage. So
var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);
var certs = store.Certificates.Find(X509FindType.FindBySubjectName,
subjectName, true);
We’d like to switch to something that’s more cross platform (esp Linux
compatible). What are some good design patterns for a secure, cross
platform certificate storage? We need to store RSA and EC certificates as
well as their respective private keys (if they exist in the password
protected PFX).
Regards
Sid
Jeff Stedfast
2013-11-24 12:18:41 UTC
Permalink
Just to update people (such as Sid) who might also be interested in a
cross-platform solution, I've implemented CRL support in my
X509CertificateDatabase that should properly handle delta CRLs,
certificates and encrypted private keys.

There will no doubt be further tweaking (adding additional columns to aid
in faster lookups and/or a cache?), but it's functional at this point.

Code can be found here:
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/X509CertificateDatabase.cs

It's under the MIT license, so feel free to simply take it and use it
wherever you want. It implements the IX509Store interface for certificate
lookups and I've tried to map what I can to database columns to filter out
rows that won't pass the Match() test there by improving performance,
although there's still a lot of performance improvements that could no
doubt be done.

Jeff
Post by Jeff Stedfast
Hi David,
Thanks for the info!
Yes, I'm already using the PkixCertPathBuiler to get a certificate chain
and storing that on my "SecureMimeDigitalSignature" class that consumers of
my library can access and validate.
If you are interested, I would appreciate hearing your (or anyone else's
on this list) thoughts on my S/MIME implementation so far at
https://github.com/jstedfast/MimeKit
The S/MIME stuff is all in MimeKit/Cryptography/*
SecureMimeContext is the base class that does all of the
encryption/decryption/signing/verifying/etc and has abstract methods for
subclasses to implement for things like certificate, crl and private key
lookups and other management of those things.
The code I'm working on now is DefaultSecureMimeContext (it used to use
.p12 files and a flat file of crls, but I had no way of storing S/MIME
capabilities so gave up and am now re-implementing it using the
X509CertificateDatabase class to store everything I need).
Thanks to your answer to my question, my next step will be to get the CRL
storage correct.
Jeff
Post by David Hook
It's a bit of both, some CRLs constitute full updates, others are
referred to as "delta CRLs", and represent a set of changes, so in the
situation where you have a delta CRL your actual set of revocations is
("update CRL" + "delta CRL 1" + "delta CRL 2"...).
A delta CRL is indicated by the Delta CRL Indicator - an extension
defined in section 5.2.4 of RFC 5280
One other thing that might help, if you're not doing it already, are you
using any of the CertPath support in BC C#? Validating a certificate
properly involves a lot more than checking a signature and a CRL. The
CertPath code is an attempt to deal with the now 151 pages of RFC 5280.
Regards,
David
Okay... I've broken down and implemented a SQLite database for storing
certificates (along with the S/MIME Capabilities for the clients associated
with each certificate - this is needed to properly determine which
encryption algorithm to use) and the CRLs.
It was just getting to be too much of a PITA to store each of these
things in different files and manage relationships between them.
That said... I don't know a whole lot about CRLs and want to get this
correct.
Can I assume that X509Crl's with an identical IssuerDN and a newer
ThisUpdate replaces an older X509Crl with the same IssuerDN?
Or do I just need to keep collecting CRLs?
In other words: if I have an X509Crl with an IssuerDN of "XYZ" and a
ThisUpdate of "Yesterday", would an X509Crl with an issuerDN of "XYZ" and a
ThisUpdate of "Today" contain the same list of certificates (plus any new
ones) as the first CRL?
Thanks,
Jeff
On Tue, Nov 12, 2013 at 4:45 PM, Jaroslav Imrich <
Post by Jaroslav Imrich
Hello Sid,
currently there is no "standard certificate store" available on Linux.
Almost every application (cryptographic library) uses its own solution but
there is an ongoing effort to solve this sad situation in p11-glue project
[0] that promotes PKCS#11 as a glue between crypto libraries and security
applications. I think you should take a look at its two suprojects P11-Kit
[1] and TrustModule [2]. PKCS#11 interface is nowadays supported by almost
every smartcard/HSM middleware and there are also pure software modules
available such as SoftHSM [3] or NSS Internal PKCS#11 module (used by
Mozilla products). Unmanaged PKCS#11 modules can be easily interfaced in C#
via managed wrappers such as Pkcs11Interop [4]. Full disclosure: I am the
author of Pkcs11Interop :)
However if you are looking for a quickest, easy to understand, easy to
implement and "truly" cross-platform solution (Android and iOS included)
you will probably end up with something very similar to Jeff's solution
with PKCS#12 file.
[0] http://p11-glue.freedesktop.org/
[1] http://p11-glue.freedesktop.org/p11-kit.html
[2] http://p11-glue.freedesktop.org/trust-module.html
[3] http://www.opendnssec.org/softhsm/
[4] http://pkcs11interop.net/
--
Kind Regards / S pozdravom
Jaroslav Imrich
http://www.jimrich.sk
Post by Sid Shetye
Thanks Jeff.
Taking a step back before jumping into library details, did you find
any other alternatives before deciding to have your own cert store
implementation? I ask because it seems odd (to me) that you and I would be
the first ones to face the “cross platform certificate store” problem –
surely someone else might have solved this before. Especially in the Bouncy
Castle community? That’s my (perhaps naïve) thinking. So would appreciate
if you could share your learnings on this topic (and great job on the
GitHub repo!)
Regards,
Sid
*Sent:* Tuesday, November 12, 2013 11:05 AM
*To:* Sid Shetye
*Cc:* Bouncy Castle Developer List
*Subject:* Re: [dev-crypto-csharp] Certificate store for cross
platform designs
Hi Sid,
I asked this question just last week ;-)
What I ended up doing is to use a pkcs12 file to store private
certs/keys and a file containing unencrypted certs for everything else
(like CAs and such).
If you come up with a better way, I'd appreciate if you let me know.
I'm working on a cross-platform (Windows, Mac, Linux, iOS, and Android)
MIME library with support for S/MIME and PGP, so am really interested in a
cross-platform way of managing certificates.
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/DefaultSecureMimeContext.cs#L104
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/X509CertificateStore.cs
The first link creates 2 X509CertificateStores, one for root
certificates and one for user certs (equivalent, I suppose, of
StoreName.Root and StoreName.My). I should probably also have something
equivalent to StoreName.AddressBook, but right now they are stored in the
pkcs12 file along with the user's other personal certificates.
Hope that helps,
Jeff
Hi folks,
Although we do use BC for some crypto stuff, we haven’t explored
anything beyond the standard Windows cert store for certificate storage. So
var store = new X509Store(StoreName.My, StoreLocation
.LocalMachine);
store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);
var certs = store.Certificates.Find(X509FindType.FindBySubjectName,
subjectName, true);
We’d like to switch to something that’s more cross platform (esp Linux
compatible). What are some good design patterns for a secure, cross
platform certificate storage? We need to store RSA and EC certificates as
well as their respective private keys (if they exist in the password
protected PFX).
Regards
Sid
Sid Shetye
2013-11-25 22:25:18 UTC
Permalink
Absolutely understand the SQLite approach – we were also looking at it too.
One concern: Are you thinking of an external lib (.dll) for the SQLite layer
or are you integrating it at source code level by licensing it from a
compatible license?



Cheers

Sid



From: Jeff Stedfast [mailto:jeff-***@public.gmane.org]
Sent: Saturday, November 23, 2013 6:44 AM
To: Jaroslav Imrich
Cc: Sid Shetye; Bouncy Castle Developer List
Subject: Re: [dev-crypto-csharp] Certificate store for cross platform
designs



Okay... I've broken down and implemented a SQLite database for storing
certificates (along with the S/MIME Capabilities for the clients associated
with each certificate - this is needed to properly determine which
encryption algorithm to use) and the CRLs.



It was just getting to be too much of a PITA to store each of these things
in different files and manage relationships between them.



That said... I don't know a whole lot about CRLs and want to get this
correct.



Can I assume that X509Crl's with an identical IssuerDN and a newer
ThisUpdate replaces an older X509Crl with the same IssuerDN?



Or do I just need to keep collecting CRLs?



In other words: if I have an X509Crl with an IssuerDN of "XYZ" and a
ThisUpdate of "Yesterday", would an X509Crl with an issuerDN of "XYZ" and a
ThisUpdate of "Today" contain the same list of certificates (plus any new
ones) as the first CRL?



Thanks,



Jeff



On Tue, Nov 12, 2013 at 4:45 PM, Jaroslav Imrich <jaroslav.imrich-***@public.gmane.org
<mailto:jaroslav.imrich-***@public.gmane.org> > wrote:

Hello Sid,



currently there is no "standard certificate store" available on Linux.
Almost every application (cryptographic library) uses its own solution but
there is an ongoing effort to solve this sad situation in p11-glue project
[0] that promotes PKCS#11 as a glue between crypto libraries and security
applications. I think you should take a look at its two suprojects P11-Kit
[1] and TrustModule [2]. PKCS#11 interface is nowadays supported by almost
every smartcard/HSM middleware and there are also pure software modules
available such as SoftHSM [3] or NSS Internal PKCS#11 module (used by
Mozilla products). Unmanaged PKCS#11 modules can be easily interfaced in C#
via managed wrappers such as Pkcs11Interop [4]. Full disclosure: I am the
author of Pkcs11Interop :)



However if you are looking for a quickest, easy to understand, easy to
implement and "truly" cross-platform solution (Android and iOS included) you
will probably end up with something very similar to Jeff's solution with
PKCS#12 file.



[0] http://p11-glue.freedesktop.org/

[1] http://p11-glue.freedesktop.org/p11-kit.html

[2] http://p11-glue.freedesktop.org/trust-module.html

[3] http://www.opendnssec.org/softhsm/

[4] http://pkcs11interop.net/
--
Kind Regards / S pozdravom

Jaroslav Imrich
http://www.jimrich.sk <http://www.jimrich.sk/>



On Tue, Nov 12, 2013 at 8:35 PM, Sid Shetye <sid314-1ViLX0X+***@public.gmane.org
<mailto:sid314-1ViLX0X+***@public.gmane.org> > wrote:

Thanks Jeff.



Taking a step back before jumping into library details, did you find any
other alternatives before deciding to have your own cert store
implementation? I ask because it seems odd (to me) that you and I would be
the first ones to face the “cross platform certificate store” problem –
surely someone else might have solved this before. Especially in the Bouncy
Castle community? That’s my (perhaps naïve) thinking. So would appreciate if
you could share your learnings on this topic (and great job on the GitHub
repo!)



Regards,

Sid



From: Jeff Stedfast [mailto:jeff-***@public.gmane.org <mailto:jeff-***@public.gmane.org> ]
Sent: Tuesday, November 12, 2013 11:05 AM
To: Sid Shetye
Cc: Bouncy Castle Developer List
Subject: Re: [dev-crypto-csharp] Certificate store for cross platform
designs



Hi Sid,



I asked this question just last week ;-)



What I ended up doing is to use a pkcs12 file to store private certs/keys
and a file containing unencrypted certs for everything else (like CAs and
such).



If you come up with a better way, I'd appreciate if you let me know. I'm
working on a cross-platform (Windows, Mac, Linux, iOS, and Android) MIME
library with support for S/MIME and PGP, so am really interested in a
cross-platform way of managing certificates.



You can find my current cross-platform certificate management logic here:
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/Defaul
tSecureMimeContext.cs#L104



and here:
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/X509Ce
rtificateStore.cs



The first link creates 2 X509CertificateStores, one for root certificates
and one for user certs (equivalent, I suppose, of StoreName.Root and
StoreName.My). I should probably also have something equivalent to
StoreName.AddressBook, but right now they are stored in the pkcs12 file
along with the user's other personal certificates.



Hope that helps,



Jeff



On Tue, Nov 12, 2013 at 1:42 PM, Sid Shetye <sid314-1ViLX0X+***@public.gmane.org
<mailto:sid314-1ViLX0X+***@public.gmane.org> > wrote:

Hi folks,



Although we do use BC for some crypto stuff, we haven’t explored anything
beyond the standard Windows cert store for certificate storage. So at
present we use the Windows certificate store as:



var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);

store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);

var certs = store.Certificates.Find(X509FindType.FindBySubjectName,
subjectName, true);



We’d like to switch to something that’s more cross platform (esp Linux
compatible). What are some good design patterns for a secure, cross platform
certificate storage? We need to store RSA and EC certificates as well as
their respective private keys (if they exist in the password protected PFX).



Regards

Sid
Jeff Stedfast
2013-11-26 02:32:06 UTC
Permalink
Hi Sid,

I'm just using an external library. I've included Mono.Data.Sqlite which
P/Invokes into the system installed sqlite3.so (.dylib on Mac). On Windows,
consumers of my library will have to bundle the sqlite3.dll that I've added
to the git repo for my library for convenience, but can also be downloaded
from their website.

I guess you are asking because your business cannot use something that is
in the public domain?

Jeff
Post by Sid Shetye
Absolutely understand the SQLite approach – we were also looking at it
too. One concern: Are you thinking of an external lib (.dll) for the SQLite
layer or are you integrating it at source code level by licensing it from a
compatible license?
Cheers
Sid
*Sent:* Saturday, November 23, 2013 6:44 AM
*To:* Jaroslav Imrich
*Cc:* Sid Shetye; Bouncy Castle Developer List
*Subject:* Re: [dev-crypto-csharp] Certificate store for cross platform
designs
Okay... I've broken down and implemented a SQLite database for storing
certificates (along with the S/MIME Capabilities for the clients associated
with each certificate - this is needed to properly determine which
encryption algorithm to use) and the CRLs.
It was just getting to be too much of a PITA to store each of these things
in different files and manage relationships between them.
That said... I don't know a whole lot about CRLs and want to get this
correct.
Can I assume that X509Crl's with an identical IssuerDN and a newer
ThisUpdate replaces an older X509Crl with the same IssuerDN?
Or do I just need to keep collecting CRLs?
In other words: if I have an X509Crl with an IssuerDN of "XYZ" and a
ThisUpdate of "Yesterday", would an X509Crl with an issuerDN of "XYZ" and a
ThisUpdate of "Today" contain the same list of certificates (plus any new
ones) as the first CRL?
Thanks,
Jeff
On Tue, Nov 12, 2013 at 4:45 PM, Jaroslav Imrich <
Hello Sid,
currently there is no "standard certificate store" available on Linux.
Almost every application (cryptographic library) uses its own solution but
there is an ongoing effort to solve this sad situation in p11-glue project
[0] that promotes PKCS#11 as a glue between crypto libraries and security
applications. I think you should take a look at its two suprojects P11-Kit
[1] and TrustModule [2]. PKCS#11 interface is nowadays supported by almost
every smartcard/HSM middleware and there are also pure software modules
available such as SoftHSM [3] or NSS Internal PKCS#11 module (used by
Mozilla products). Unmanaged PKCS#11 modules can be easily interfaced in C#
via managed wrappers such as Pkcs11Interop [4]. Full disclosure: I am the
author of Pkcs11Interop :)
However if you are looking for a quickest, easy to understand, easy to
implement and "truly" cross-platform solution (Android and iOS included)
you will probably end up with something very similar to Jeff's solution
with PKCS#12 file.
[0] http://p11-glue.freedesktop.org/
[1] http://p11-glue.freedesktop.org/p11-kit.html
[2] http://p11-glue.freedesktop.org/trust-module.html
[3] http://www.opendnssec.org/softhsm/
[4] http://pkcs11interop.net/
--
Kind Regards / S pozdravom
Jaroslav Imrich
http://www.jimrich.sk
Thanks Jeff.
Taking a step back before jumping into library details, did you find any
other alternatives before deciding to have your own cert store
implementation? I ask because it seems odd (to me) that you and I would be
the first ones to face the “cross platform certificate store” problem –
surely someone else might have solved this before. Especially in the Bouncy
Castle community? That’s my (perhaps naïve) thinking. So would appreciate
if you could share your learnings on this topic (and great job on the
GitHub repo!)
Regards,
Sid
*Sent:* Tuesday, November 12, 2013 11:05 AM
*To:* Sid Shetye
*Cc:* Bouncy Castle Developer List
*Subject:* Re: [dev-crypto-csharp] Certificate store for cross platform
designs
Hi Sid,
I asked this question just last week ;-)
What I ended up doing is to use a pkcs12 file to store private certs/keys
and a file containing unencrypted certs for everything else (like CAs and
such).
If you come up with a better way, I'd appreciate if you let me know. I'm
working on a cross-platform (Windows, Mac, Linux, iOS, and Android) MIME
library with support for S/MIME and PGP, so am really interested in a
cross-platform way of managing certificates.
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/DefaultSecureMimeContext.cs#L104
https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Cryptography/X509CertificateStore.cs
The first link creates 2 X509CertificateStores, one for root certificates
and one for user certs (equivalent, I suppose, of StoreName.Root and
StoreName.My). I should probably also have something equivalent to
StoreName.AddressBook, but right now they are stored in the pkcs12 file
along with the user's other personal certificates.
Hope that helps,
Jeff
Hi folks,
Although we do use BC for some crypto stuff, we haven’t explored anything
beyond the standard Windows cert store for certificate storage. So at
var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);
var certs = store.Certificates.Find(X509FindType.FindBySubjectName,
subjectName, true);
We’d like to switch to something that’s more cross platform (esp Linux
compatible). What are some good design patterns for a secure, cross
platform certificate storage? We need to store RSA and EC certificates as
well as their respective private keys (if they exist in the password
protected PFX).
Regards
Sid
Moschny, Torsten
2013-12-09 18:16:54 UTC
Permalink
Hi Jeff,
Post by Jeff Stedfast
Can I assume that X509Crl's with an identical IssuerDN and a newer
ThisUpdate replaces an older X509Crl with the same IssuerDN?
you need to check the "Delta CRL Indicator" of a CRL to see whether you
have a delta CRL or a complete CRL. RFC 5280
(http://www.ietf.org/rfc/rfc5280.txt), section 5.2.4., gives you more
information on this.

Regards,
Torsten
Jeff Stedfast
2013-12-09 21:05:33 UTC
Permalink
Hi Torsten,

Yep, thanks, I think David mentioned this a while back and I've already
implemented it.

Now I'm just debating whether my library should provide support for
fetching CRLs from the web or leave that to the app.

Jeff
Post by Moschny, Torsten
Hi Jeff,
Can I assume that X509Crl's with an identical IssuerDN and a newer
Post by Jeff Stedfast
ThisUpdate replaces an older X509Crl with the same IssuerDN?
you need to check the "Delta CRL Indicator" of a CRL to see whether you
have a delta CRL or a complete CRL. RFC 5280 (http://www.ietf.org/rfc/
rfc5280.txt), section 5.2.4., gives you more information on this.
Regards,
Torsten
Loading...