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

[Edward Ned Harvey (mono)]

> From: mono-list-bounces at lists.ximian.com [mailto:mono-list-
> bounces at lists.ximian.com] 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.