Possible bug in MimeKit [or weird behavior? or I am stupid, and don't get it?]

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible bug in MimeKit [or weird behavior? or I am stupid, and don't get it?]

Thomas Hansen
First of all, thx for a brilliant piece of work Jeffrey, MimeKit and MailKit simply rules!! :D

Anyway, there are some weird behavior in WindowsSecureMimeContext.cs in MimeKit which either I am too stupid to understand, or seems to be a bug ...?

Inside the "GetCmsRecipientCertificate" method, you check for the DataEncipherment bit, and if found, MimeKit doesn't allow usage of certificate and/or key.

I have a certificate from Comodo, which apparently seem to have this bit set, which means MimeKit doesn't allow me to use this certificate/key to do its magic. I actually forked your "WindowsSecureMimeContext" class just to remove this check, which allowed me to use that certificate and key

Could someone explain to me please why this check is there ...?

ps, Comodo seems to be one of the biggest certificate issuers out there, and if they issue their "default email certificates" with the DataEncipherment bit set, I imagine a lot of certificates are "lost" this way ...

Another thing on the sideline, it took me actually a whole day figuring out I could use the Windows Certificate/Key Storage instead of Sqlite. Maybe you should update your website at https://github.com/jstedfast/MimeKit to at the very least inform users of that there exists a Windows Certificate/Key database wrapper in MimeKit ...

When I found it, I had spent literally a whole day trying to make my own ... :P

Anyway, thanx again for a brilliant piece of work :D
I've looked at all the smtp and s/mime libraries out there, and MimeKit simply rules ... :D

pps, could anyone point me in the direction for the changelog for version 0.94 of both MimeKit and MailKit ...?

ppps, if this is the wrong mailing list, I am sorry for being off topic, and I would appreciate someone pointing me in the right direction :)


Have a nice day :)

Thomas

_______________________________________________
Mono-list maillist  -  [hidden email]
http://lists.ximian.com/mailman/listinfo/mono-list
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug in MimeKit [or weird behavior? or I am stupid, and don't get it?]

Edward Ned Harvey (mono)
> From: [hidden email] [mailto:mono-list-
> [hidden email]] On Behalf Of Thomas Hansen
>
> First of all, thx for a brilliant piece of work Jeffrey, MimeKit and MailKit simply
> rules!! :D

+1

I don't think Jeff is on this mailing list, so I added him to BCC, so he's both included in this message I'm sending, and I'm not giving away his email address (just in case he cares.  Although I don't think he does.)


> Inside the "GetCmsRecipientCertificate" method, you check for
> the DataEncipherment bit, and if found, MimeKit doesn't allow usage of
> certificate and/or key.
>
> I have a certificate from Comodo, which apparently seem to have this bit set,
> which means MimeKit doesn't allow me to use this certificate/key to do its
> magic. I actually forked your "WindowsSecureMimeContext" class just to
> remove this check, which allowed me to use that certificate and key

This question really has touched on several independent subjects.

#1  When you get a cert, the cert issuer sets bits on the cert, indicating how it's intended to be used.  They can issue signing-only certs, signing & encrypting certs, etc.  So what is the DataEncipherment bit?  See http://tools.ietf.org/html/rfc5280#section-4.2.1.3  It's exactly what you think it is.  If the bit is set, then the issuer intends this cert to be usable for encryption.

#2  You said, if the bit is set, MimeKit disallows usage of the cert.  You have a cert with that bit set, and it won't work.  This seems to be reverse logic - seems to suggest a bug in MimeKit - but maybe it's in fact correct (I don't want to jump to conclusions.)  To me it seems like the logic clause is probably accidentally negated.  Sounds like a bug to me.

#3  Suppose the logic is correct.  Suppose the bit is *supposed* to prevent you from using this cert this way.  Then is it ok to simply reverse the logic in the application and use it anyway?  No, not really.  It might work, and it might even be secure, but the purpose of setting those bits is to ensure proper usage, and anything used incorrectly in cryptography is prone to weakness.  For example, what's the difference between an ECDSA key and an ECDH key?  None.  They're exactly the same.  In fact, either EC key can work in either situation, but the best practices for key storage are different, and if the same key is used for both DSA and DH, the interactions of these two protocols have not been rigorously studied and vetted by the community, so there could possibly exist bad interactions that break security, if only somebody bothers to put in the effort and study it.
_______________________________________________
Mono-list maillist  -  [hidden email]
http://lists.ximian.com/mailman/listinfo/mono-list