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
On 24/11/13 01:44, Jeff Stedfast wrote:
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
<[email protected] <mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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:[email protected]
<mailto:[email protected]>]
*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/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
On Tue, Nov 12, 2013 at 1:42 PM, Sid Shetye
<[email protected] <mailto:[email protected]>> 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:
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
