persisting chain of trust

[blacklion9279]

As part of the signature verification process, when the user received a signed email, MimeKit imported all certificates that were part of the trust chain of the signing certificate. That behavior suggests that having the entire chain in the database is something needed by MimeKit. Is there a reason to do so when user imports a new signing certificate? If the primary purpose is verification of trust of chain, and if that's done using some other APIs, would it still make sense to let mimekit persist that?

[jstedfast]

I don't really understand what you're trying to say/ask.

Is there a reason to do so when user imports a new signing certificate?

When you import a signing certificate, where would you expect the certificates to go if not the database?

If the primary purpose is verification of trust of chain, and if that's done using some other APIs, would it still make sense to let mimekit persist that?

To validate the cert chain, MimeKit does need the certificates to all "be in 1 place" (doesn't necessarily have to be the database, I suppose, but I don't see the harm in putting them there. They just need to be available via an IX509Selector or w/e it is that BouncyCastle uses).

[jstedfast]

Are you talking about SecureMimeContext.GetDigitalSignatures()? If so, I don't think they actually need to be imported for the cert chain to be validated.

I think they are just imported to support encryption to those certificates at a later date.

The way S/MIME works is that if you and I want to be able to encrypt emails to each other, I would first send you a signed message which would include my certificate chain. Your mail client, while verifying the signature, would import my certificate (chain). Now you can send me encrypted emails.

[blacklion9279]

To add clarification to question, yes I get the point of storing "the certificate" using which the message was signed in a database. However, not sure of the purpose for entire chain and rest of the certificates in that chain. The rest of the chain may include root ca and any intermediaries.

when you say

I think they are just imported to support encryption to those certificates at a later date.

Are we expecting to send encrypted emails to non-leaf node in a certificate?

[jstedfast]

No, we're not expecting to send an email to a non-leaf node cert, but I figure it doesn't hurt to have them (they are not marked as trusted, so it doesn't affect trust).

[blacklion9279]

So in our secureMimeContext implementation, we are not persisting non-leaf nodes in SQLite db. We just keep the leaf node. Do you think it has any side effect that we are possibly not seeing right now?

[jstedfast]

No, I think it should be fine. Perhaps even MimeKit's SecureMimeContext should be changed to do the same... I'm not entirely sure.

Validation is used given the intermediate certs included in the metadata of the signature and not from the db (other than the trusted roots), so there's no reason I can think of that the intermediate certs need to be in the db.

[jstedfast]

Does your SecureMimeContext add the CRLs (if any) in GetDigitalSignatures()?

Are you not including the intermediate certs because they grow the db unnecessarily? Or is there another reason? I'm just curious.

[blacklion9279]

no it doesn't add CRLs at this time. We may be looking to do that in future though.

Yeah mainly keeping db clean and performing better and not cluttering it with noise. We ran into few issues when adding mailbox owner's certificates for signing and encrypting and had to take out the part where it imported root and intermediate certs. Mimekit didnt seem to have any issue with that, so that got us thinking if we required it during signature verification stage.

Also, as a side note we are using a windows api to validate trust.

[jstedfast]

Okay, thanks for the update. After thinking it over for a bit, I think not importing the intermediate certs is probably a good change to make to MimeKit so I committed a patch yesterday to not do it anymore.

I wasn't as sure about what todo with CRLs, though. Those can also lead to clutter in the db, but they might be important for future verifications of signatures. I'm not sure it's actually very widely used in practice.