Re: Thunderbird S/MIME: Interoperability problem with gpgsm (KMail / Claws Mail)
Nelson Bolyard wrote:
> I will send an encrypted reply to the email I received. We'll see if
> my correspondent can decrypt it.
I remembered that mozilla doesn't "import" (save) an encryption cert
from an email unless it can validate that cert. That means the cert
has to have been issued by a trusted issuer. So, I set the email trust
bit on the CACert root CA, and then read the message, and THEN mozilla
imported his cert and it appeared in Cert Manager.
Then I replied to the message with a signed and encrypted reply.
After sending it, I looked at the message I had just sent, and saw this:
SEQUENCE {
OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) (PKCS #7)
SEQUENCE {
OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
SEQUENCE {
INTEGER 160
OCTET STRING 3B EE E9 74 FF FE 87 90
}
}
Which tells me that mozilla sent an rc2 encrypted reply. :(
So, indeed, something seems wrong with mozilla's SMIME code here
(in NSS or PSM). Given that the KMail message offered to receive
either 3DES or AES, and mozilla supports 3DES, mozilla should have
sent a 3DES reply.
--
Nelson B
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird S/MIME: Interoperability problem with gpgsm (KMail / Claws Mail)
Nelson B wrote: Hi Nelson and others... > Nelson Bolyard wrote: > >> I will send an encrypted reply to the email I received. We'll see if >> my correspondent can decrypt it. Just to reduce confusion about my mail: I am Martin Hoefling (using KMail/Kontact), and Wurstsemmel is using Thunderbird. We encountered the problems, while testing communication via S/Mime certificates. As far as we understood, this is a thunderbird issue. Who should file a bugreport? Shall we do it? We can test, the patch, if a communication partner with KMail is needed. Cheers Martin ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Amending Mozilla's Root CA cert policy with key size requirements
Paul Hoffman wrote: > At 2:12 PM -0700 4/30/07, Robert Relyea wrote: >> I don't see a way around the legacy 1024 bit certs, but I would >> definately want to see wording that will discourage the issuance of >> new root certs that are less than 2048. > > From a cryptographic standpoint, such a policy would not make sense. You are correct in the strict sense. However IMO getting rid of 1024-bit certs will not be a one-time event where we remove all such certs, instead we have to plan for a transitional period as CAs phase out the use of old root CA certs and start issuing certs under new root CA certs. During that transition period it makes policy sense (if not cryptographic sense) to discourage inclusion of new 1024-bit root CA certs while allowing old ones to remain for a little while longer. So if we do change our CA policy to reflect current thinking on modulus length I think we should do two things: 1. Stop accepting new 1024-bit CA certs immediately (or at least very soon). 2. Set a target date (or dates) for removal of legacy 1024-bit CA certs. (This can also encompass looking at intermediate CA certs and related issues, of course.) Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Dumping RC2/40
Thunderbird already has a bug which could be interpreted as a request to disable RC2/40 - "S/MIME should not support weak crypto" (https://bugzilla.mozilla.org/show_bug.cgi?id=84213) Also, here's a thread in which author of gpgsm Werner Koch explains why he doesn't support RC2 and what he thinks about Thunderbird implementation. http://www.nabble.com/gpgsm-1.9.22-supports-no-RC2-Algorithm---tf3581426.html Also, I am using KMail with gpgsm and Thunderbird when I can't decrypt using KMail. So, if anyone needs testing, I can help. Thanks. Paul Hoffman wrote: > At 5:38 PM -0700 4/27/07, Nelson Bolyard wrote: >>Paul Hoffman wrote: >> >>> Proposal: >>> a) Completely turn off the ability to encrypt with RC2/40 unless there >>> is no strong algorithm. >>> b) Every time you are about to encrypt with RC2/40, warn the user, >>> including an explanation of how Tb got to this point in the logic >>> chain. >> >>Patches cheerfully received. :) > > Thought there should be some conversation first... -- Nick ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Amending Mozilla's Root CA cert policy with key size requirements
At 2:12 PM -0700 4/30/07, Robert Relyea wrote: >I don't see a way around the legacy 1024 bit certs, but I would >definately want to see wording that will discourage the issuance of >new root certs that are less than 2048. From a cryptographic standpoint, such a policy would not make sense. All root certs are treated equivalently by Mozilla for validating domain names. Therefore, as long as there is even one root cert with a 1024-bit key, Mallory would attack that one cert and, if successful, issue bogus certificates with the compromised key. If we make a rule about signature strength, it has to apply equally to every root certificate in the set; otherwise, the rule will have no effect on the security of the system. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird S/MIME: Interoperability problem with gpgsm (KMail / Claws Mail)
Martin Hoefling wrote: Nelson B wrote: Hi Nelson and others... Nelson Bolyard wrote: I will send an encrypted reply to the email I received. We'll see if my correspondent can decrypt it. Just to reduce confusion about my mail: I am Martin Hoefling (using KMail/Kontact), and Wurstsemmel is using Thunderbird. We encountered the problems, while testing communication via S/Mime certificates. As far as we understood, this is a thunderbird issue. Who should file a bugreport? Shall we do it? file the bug at bugzilla.mozilla.org New->Other Products->NSS We don't know if it's PSM or NSS, but at this point I think NSS picks the cipher, so start there. Nelson's experiment clearly exonerates KMail. bob We can test, the patch, if a communication partner with KMail is needed. Cheers Martin ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Amending Mozilla's Root CA cert policy with key size requirements
At 11:54 AM -0400 5/1/07, Frank Hecker wrote: >Paul Hoffman wrote: >> At 2:12 PM -0700 4/30/07, Robert Relyea wrote: >>> I don't see a way around the legacy 1024 bit certs, but I would >>> definately want to see wording that will discourage the issuance of >>> new root certs that are less than 2048. >> >> From a cryptographic standpoint, such a policy would not make sense. > >You are correct in the strict sense. ' Thank you. :-) >However IMO getting rid of 1024-bit >certs will not be a one-time event where we remove all such certs, >instead we have to plan for a transitional period as CAs phase out the >use of old root CA certs and start issuing certs under new root CA >certs. Yep. The tricky part will be getting them to agree to phase out their old certs in under five years. OTOH, Firefox is gaining enough traction where if we say "after 2013 all 1024-bit root certs will be banished from the root store", it might get them moving. >During that transition period it makes policy sense (if not >cryptographic sense) to discourage inclusion of new 1024-bit root CA >certs while allowing old ones to remain for a little while longer. > >So if we do change our CA policy to reflect current thinking on modulus >length I think we should do two things: > >1. Stop accepting new 1024-bit CA certs immediately (or at least very soon). Fully agree. > >2. Set a target date (or dates) for removal of legacy 1024-bit CA certs. Fully agree. What about 1536-bit CA certs? This is a serious question. We need to understand whether or not the CAs we care about want this intermediate size for any reason, or if we make the required size after the cutoff to be 2048 bits. Again, while we are at it, how about mandating SHA-246? We can safely assume complete deployment of it within five years. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
