Change of list owner/moderator
Dear dev-tech-crypto readers: Today I have given up the position of list owner and moderator for the dev-tech-crypto mailing list and mozilla.dev.tech.crypto news group, a position I have held since the list was formed over 10 years ago. The new owner/moderator is Kai Engert. Please join me in sending him private congratulations and wishing him the best. /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS 3.12.5.0: Error '-8152' (SEC_ERROR_INVALID_KEY) when connecting to ssl-enabled servers
On 2012/05/21 05:21 PDT, Bernhard Thalmayr wrote: Hi Wan-Teh, Nelson, could it be that this error is also raised by the client if the client can not 'participate' in ssl client-auth? Unfortunately I only got a text-output of 'ssldump', not sure if this is would be helpful. [snip] The client is telling the server that the server's certificate is bad. Interestingly enough the community member told be that this error does not happen with NSS: 3.12.8 NSPR: 4.8.6 NSS is less forgiving of certain key size errors than it was before. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS 3.12.5.0: Error '-8152' (SEC_ERROR_INVALID_KEY) when connecting to ssl-enabled servers
On 2012/05/08 04:53 PDT, Bernhard Thalmayr wrote: Hi experts, an OpenAM community member is using OpenAM policy agent to connect to an ssl-secured server. The policy agent uses NSPR 4.8.2, NSS 3.12.5.0 optimized build for Linux (RHEL) 64bit. If the agent tries to open a connection to a specific, ssl-enabled OpenAM server, error '-8152' is raised. What might be the root-cause for this error? Could I get some additional output from an optimized build or do I really need a 'DEBUG' build to leverage NSS environment variables (https://developer.mozilla.org/en/NSS_reference/NSS_environment_variables)? Interestingly the same agent can connect to other ssl-enabled servers. Unfortunately the community member will / can not provide a network trace showing the handshake messages. TIA, Bernhard Bernhard, I think the most likely explanations are these: 1) Server certificate has a public key that is too small, too large, has a too small public exponent (if RSA), an unknown key type, or a key for an Elliptic Curve that is not supported by NSS. 2) Some other certificate in the server's cert chain has one of the above problems. 3) The server is attempting to use Server Key Exchange for forward secrecy, and the key it is offering for that purpose has one of the problems mentioned above. 4) The server is selecting a cipher suite that is incompatible with the type of key in its public key certificate. Ii suggest you use tcpdump or ssltap to get a trace of your own. Regards, /Nelson -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: The PKCS #12 operation failed for unknown reasons
On 2012/02/27 09:47 PDT, VictorMiller wrote: On Feb 24, 7:57 pm, Nelson B Bolyard nel...@bolyard.me wrote: On 2012/02/24 07:26 PDT, VictorMiller wrote: I have a new PKI certificate as a .p12 file which I want to import into firefox and thunderbird on a RedHat system. However, every time I try an import I get the above error message. If I log onto an MS Windows machine I can get IE to import it without a problem. I've tried all sorts of things, such as moving all of my .db files in .thunderbird out of the way, and letting thunderbird create new ones. I've even tried moving my whole .thunderbird directory out of the way. Nothing works. Here's a strange thing -- even if I deliberately give the wrong password for the encrypted .p12 file I still get the same stupid error message. Any suggestions as to how to debug this? My guess is that your .p12 file has no friendly name in it. The utility program pk12util can confirm or refute this. If that's it, the solution is to create a new .p12 file with the same certs/keys and a printable ASCII friendly name. Here's some more information. When I try to import the certificate using pkutil -i I get the following error message: PKCS12 decode import bags failed: Unable to find the certificate or key necessary for authentication. Sounds like your p12 file doesn't contain the necessary private key. I've checked that I have the certificates for all the right authorities (I've checked with my help desk to find out which ones), and that in FF and thunderbird I have all the boxes checked. This is really maddening. Victor -- 12345678901234567890123456789012345678901234567890123456789012345678901234567890 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: The PKCS #12 operation failed for unknown reasons
On 2012/02/24 07:26 PDT, VictorMiller wrote: I have a new PKI certificate as a .p12 file which I want to import into firefox and thunderbird on a RedHat system. However, every time I try an import I get the above error message. If I log onto an MS Windows machine I can get IE to import it without a problem. I've tried all sorts of things, such as moving all of my .db files in .thunderbird out of the way, and letting thunderbird create new ones. I've even tried moving my whole .thunderbird directory out of the way. Nothing works. Here's a strange thing -- even if I deliberately give the wrong password for the encrypted .p12 file I still get the same stupid error message. Any suggestions as to how to debug this? My guess is that your .p12 file has no friendly name in it. The utility program pk12util can confirm or refute this. If that's it, the solution is to create a new .p12 file with the same certs/keys and a printable ASCII friendly name. -- 12345678901234567890123456789012345678901234567890123456789012345678901234567890 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Explicitly distrusted certificates in certdata.txt (NSS built-in root CA certificate list)
On 2011/10/10 12:16 PDT, Wan-Teh Chang wrote: [...] The certdata.txt file in the NSS source tree (http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/builtins/certdata.txt) is the master source of the NSS built-in trusted root CA list, so people have written scripts to extract the trusted root CA certificates from this file. [...] After the two CA break-in incidents this year, certdata.txt started to contain several explicitly distrusted certificates. Scripts that extract trusted root CA certificates from certdata.txt must now check the trust objects. Here are the instructions. I'd say it's going to be difficult for the typical scripting language to do the recommended instructions. How about putting the distrusted certs and their trust objects in a separate file in the CVS repository? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Question about pathlen extension checked
On 2011/09/18 03:15 PDT, Ralph Holz (TUM) wrote: does NSS check the pathlength extension in an issuing certificate? I am particularly wondering if pathlen:0 is honoured. Yes and Yes. NSS 3.12 claims compliance with RFC 3280. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: JSS SSLSocket problems choosing Client Certificates
On 2011/09/07 09:38 PDT, praspa wrote: I'm trying to make two separate HTTPS requests to a remote host using two client sockets and two different client certificates respectively (client cert A and B). [...] From my host, I'm able to make two connections on two different sockets to the remote host. I'm able to receive a 200 OK back from the remote web server for both individual connections. My problem is that client certificate 'A' is being used for both connections 'A' and 'B'. [...] I placed a line in my implemented SSLClientCertificateSelectionCallback select() function to indicate when the call back is executed. The select() method is only ever called once during the creation of the first SSLSocket (selecting Client Cert 'A') and never on future SSLSocket instantiations when Client Cert B is specified. In fact, I have to restart my app for select() to be run again. Is there a way I can trigger the native callback code to run select() when a certificate is requested by the remote server? The callback method *IS* called every time a cert is requested by the remote server. The problem, in your case, is that the server is only requesting the certificate once. This is because each time the client establishes a connection to the server, it looks to see if it has previously negotiated a shared master secret with the server, and if so, it tells the server Let's reuse this old secret. If the server agrees, then it does not request the certificate again, because the server has kept a copy of the certificate associated with the master secret. The only solution available through JSS (IINM) is to disable the JSS client session cache. NSS (the underlying native library) also offers another method which allows multiple client session caches, and allows each socket to be associated with a particular session cache. With this method, one may have as many users (client identities) as sockets, if desired. Unfortunately, JSS offers no interface by which to use that feature. So, The only method remaining for use by JSS is to disable the client cache completely. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Protecting PRNG against malicious users / multiple independent PRNG states
On 2011-07-26 13:30 PDT, Brian Smith wrote: Mozilla would like to expose a secure PRNG (basically, a wrapper around PK11_GenerateRandom) to JavaScript content: https://bugzilla.mozilla.org/show_bug.cgi?id=440046 There is some agreement that we should maintain separate PRNG state for each origin (roughly: domain name), and that all those states should be separate from the PRNG state used internally. PK11_GenerateRandom currently shares the PRNG state across all callers. Does anybody disagree about this separation being necessary? Yes. If not, then we (Mozilla) would to change pk11wrap so that we can control these separate PRNG states. (If this is really important, then eventually this consideration for separate contexts will need to be made for all APIs that use the PRNG that we plan to expose to JavaScript, such as PK11_GenerateKeyPair.) However, I am not sure if these separate states are really necessary; I'm pretty certain they are not necessary. There might be other reasons to have multiple parallel DRBGs, such as parallel performance on multi-core CPUs. if they were, then wouldn't it be better to maintain separate states for each SSL connection in libssl too? There was also some concern raised about preventing unnecessary depletion of entropy, while still providing good randomness to the calling JavaScript code. Suggestions for this would be much appreciated. My current thought is that we should restrict the JavaScript API such that a origin can only acquire a certain (relatively small) quantity of output from the PRNG. The current NIST-approved DRBG is claimed by NIST to not require re-seeding until 2^48 (~256 trillion) requests have been fulfilled, each requesting up to 2^16 bytes. See table 2, p. 34-45 of http://csrc.nist.gov/publications/nistpubs/800-90/SP800-90revised_March2007.pdf Thanks, Brian -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: undefined reference to `PK11_CopyToSlot'
On 2011-06-10 16:43 PDT, Crypto User wrote: On May 25, 11:33 am, Crypto User cryptou...@gmail.com wrote: Hi , I am trying to use this method to move my symmetric key to the key for wrapping. when I use this method , I get undefined reference to `PK11_CopyToSlot' collect2: ld returned 1 exit status which is linker error. I am including the pk11priv.h file. I have the latest nss library after using su -c 'yum update nss' on my fedora linux. What Can I do to get rid of this error? Thanks -A Is this function not exportedin the libnss3.so files. I did nm -D libnss*.so |grep PK11_CopyToSlot , which returned nothinfg. Which version of .so files will contain this function? I see no function by that name in the NSS source files. http://mxr.mozilla.org/security/search?string=PK11_CopyToSlotcase=on shows nothing. On the other hand, there is a function named pk11_CopyToSlot (notice the difference in capitalization). As the capitalization suggests, it is a private function of pk11wrap, not exported. See http://mxr.mozilla.org/security/search?string=PK11_CopyToSlot -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME Encryption Certificate without email address
On 2011/03/22 02:23 PDT, silent...@gmail.com wrote: Well, the reasons are at least obvious to us :) - the card is supposed to be in use for least 5 years. Card owners (Health Care Providers in our case) should be able to use various email providers for exchanging medical reports. Nothing says that the certificate(s) on those cards cannot be replaced or augmented during the lifetime of the card. I think, being able to support encryption or having an option that enables or disables verification of email addresses in certificates would make sense. Nothing verifies email addresses in certificates when sending out an email. The encryption certs are stored in a database, indexed by an email address. When email is sent, Thunderbird finds the encryption cert by looking in the database for the cert whose index is the email address. AFAIK, no check is made that the cert taken from the DB has an email address in it. The issue is not what happens when the email is sent. The issue is how the email address used for the index is determined at the time the cert is added to the DB. Nothing requires that the email address used as the index must be in the certificate. It's just that Thunderbird uses the email address in the certificate as the index value when adding a received encryption cert to the DB. There are other tools, other ways of adding certs to the DB, but Thunderbird only offers one method, AFAIK. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME Encryption Certificate without email address
On 2011/03/17 02:41 PDT, silent...@gmail.com wrote: It seems that Thunderbird refuses to use X.509 certificates for S/MIME encryption when these certificates do not contain email address of the subject. We want to use S/MIME with keys stored on smart cards and certificates distributed via LDAP. For obvious reasons we cannot attach certificates to fixed email addresses. Obvious? Not at all. Why not? The RFC 3850 describing certificate handling in S/MIME 3.1 (or 2632 for version 3) states that Receiving agents MUST recognize and accept certificates that contain no email address. And indeed, Thunderbird is able to verify a signature or decrypt an email if certificates with no email addresses were used (though it gives a warning when verifying a signature). It can also use a certificate without an email address for signing emails. However, it fails when I'm trying to encrypt an email. The encryption certificates without an email address can neither be explicitly imported via Certificate Manager nor loaded from the LDAP. NSS does not claim compliance with S/MIME 3.1, but only with 3.0. Microsoft Outlook has similar issues, but after some registry tweaking it can be enabled to use such certificates (http:// support.microsoft.com/kb/276597). Is there is a way to make Thunderbird accept such certificates too? NSS's cert database is capable of storing email encryption certs that lack any email address, indexed by en email address not found in the cert itself. Thunderbird does not use that facility to enter certs into that DB. You can do it manually using NSS's (not Microsoft's) command line tool certutil. But this is probably not the answer you seek. Best regards, Sergei Evdokimov -- 12345678901234567890123456789012345678901234567890123456789012345678901234567890 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Root certificate authorities
Brian Smith wrote: Ritmo2k wrote: Anyone know if its possible to configure Firefox to implicitly trust all certificate authorities installed in the Windows Trusted Root Certification Authorities Store? Firefox does not support this yet. See: https://bugzilla.mozilla.org/show_bug.cgi?id=454036 https://bugzilla.mozilla.org/show_bug.cgi?id=390221 There's an unfinished set of code in Mozilla's CVS repository that implements a PKCS#11 module on top of MS CAPI, enabling access to certs and keys in Windows' cert and key stores. Read about it in http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/capi/ -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: problem with the certificate name in Firefox
On 2011/02/24 12:08 PDT, Datar, Raju wrote: Hi all: There are two very different issues in Firefox. If some kind person can reply with some information, that would be highly appreciated. ISSUE 1: The certificate name in the display is a hex value. We use client side certificate for authentication and the certificate is selected when SSL is setup between the server and the client. If you import a PFX file, the certificate shows up, but does not have the CN part, but a hex value. From the details, we can see what is the other information. However, if you directly download a certificate, the CN is properly shown. Sounds like the issue described in https://bugzilla.mozilla.org/show_bug.cgi?id=450559#c2 Yes? ISSUE 2: SSL setup has issues. When you do SSL connection, sometimes a message shows that says name mismatch (typical during preproduction or when a server is hit directly with an IP address so that the load balancer is bypassed). You select I understand the risk and continue. However, after that there is another page that says there is nothing wrong with the page and no exception need to be stored. However, SSL setup does not continue!! At least when you say add exception, it continues to connect with the server and you can see the page! I suggest you file a bug against PSM (bugzilla.mozilla.org product: CORE, component: Security UI) and attach screen shots to it. Regards and thanks in advance. Raju Datar Please suppress disclaimers like the following in future messages to this list. See https://lists.mozilla.org/listinfo/dev-tech-crypto for an explanation. This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system. The above disclaimer is simply inapplicable to messages sent to a public list servere. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: certutil -D corrupting NSS database...
On 2011-01-25 13:07 PDT, Michael H. Warfield wrote: [...] Instead of having a cert in the database with the name I specified in creating the .p12 file, I ended up with a cert in the database with the name of the E-Mail address in the cert. Not sure where that problem is (openssl or the pk12util import). But, I went to delete that certificate and that's when the fun begun. certutil -D -n postmas...@wittsend.com ran without error but the cert was still there. Run it again and you get this error: [root@romulus ipsec.d]# certutil -D -n postmas...@wittsend.com -d . certutil: could not find certificate named postmas...@wittsend.com: security library: bad database. That's also when I noticed I was missing at least one other cert. I was unable to reproduce any of this with the cert DB you sent me. Before I deleted the cert with that command above, the cert DB was OK, not corrupted, and after I deleted it, it was also OK. The cert I had specified, and its nickname record AND its email record were all deleted from the DB, leaving it in a consistent state. A second delete attempt produced the same error message you saw, but didn't modify the DB at all. I tried with both certutil and libs from NSS 3.11.latest and 3.12.latest and got the same results both ways. I have these thoughts about the different behaviors that you and I experienced. 1) Maybe you had another program that was also holding the DB files open at the same time you did the certutil -D command. 2) IINM, You had the private key for some certs in your key3.db by virtue of having used pk12util to import one or more, and I didn't. That might have made a difference. 3) It's possible that the original cert DB you had was in some state of corruption, and the cert DB you reconstructed for my testing was not corrupted. Unless and until I can reproduce the behavior you saw, I won't be of much help in resolving it. Sorry. :-/ -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS server keys in DNS: client policy proposal
On 2011-02-01 07:57 PDT, Zack Weinberg wrote: I've been following the mailing list for the IETF's keyassure working group, which plans to standardize a mechanism for putting application-layer server keys (or their hashes) in DNS, certified by DNSSEC. TLS/SSL is the first target, and of course also the most interesting for the Web. While the current proposal seems sound technically, the WG has been avoiding client policy -- there is a bit of policy in the current draft, but it's worded vaguely enough to be (IMO) useless. I've drafted a policy spec which I'd like to propose to the WG. However, before doing so, I thought I would run it by y'all. If you like it, perhaps we could present this as the Mozilla consensus position rather than just one guy's opinion; if you don't like it I am eager to hear why. For reference, this is the current draft proposal: http://tools.ietf.org/html/draft-ietf-dane-protocol-03 [snip] Zack, thanks for bringing this to this list/group. I think many of us were caught by surprise by it, because it is a browser policy proposal rather than a technical discussion of the protocols. Some of us have not been following the DANE work actively, and will need some time to read up on it and appreciate all its implications. Quite a few of us are (or, have been) die hard PKI advocates and some have seen DANE as an attempted threat to PKI. I think some of us have hoped it would fail and go away, but it seems to be becoming a juggernaut, and I think those who ignore it do so at their own peril. With regard to NSS, I think that if NSS ignores it, and is found to not adequately facilitate the implementation of DANE, it may become irrelevant. That said, at this time, I have a few comments that apply directly to your proposal. I may have more later. 1) I suggest you eliminate the word bogus, replacing it with a much more precise description of records that MUST NOT be trusted in the establishment of a connection. Bogus is too open to interpretation, which can only lead to future disagreement. 2) After 14 years of working on SSL/TLS for browsers, I can tell you that browsers will all ignore the paragraph that says Clients SHOULD NOT allow users to force a connection I suppose that surprises no-one. I hope others will join a discussion here. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS server keys in DNS: client policy proposal
On 2011-02-05 13:28 PDT, Zack Weinberg wrote: On 2011-02-05 1:13 PM, Nelson B Bolyard wrote: Zack, thanks for bringing this to this list/group. I think many of us were caught by surprise by it, because it is a browser policy proposal rather than a technical discussion of the protocols. Personally, I was a little surprised to be asked to discuss this here rather than a more policy-focused group. There is a list/newsgroup focused specifically on the browser policy governing the admittance of CAs to mozilla's root CA list. That probably seems like the more obvious place, but it's where all the CA representatives hang out, and some fear that any proposal that appears to be intended to displace PKI will not get a fair hearing in that venue. But feel free to brave mozilla.dev.security.policy if you wish. I have been trying to stay out of any PKI versus DANE arguments, and (as you may see from the proposal) I still see a role for traditional CAs in providing additional validation beyond the server for this DNS name should be using this public key. I think CAs still get most of their revenues from DV, and so perceive DANE as a direct threat. However, I wouldn't especially miss the current state of affairs with DV certification if DANE totally supplanted it. Sadly, I'm sure you're not alone. 1) I suggest you eliminate the word bogus, bogus in this case is a term-of-art defined by RFC 4033. # Bogus: The validating resolver has a trust anchor and a secure # delegation indicating that subsidiary data is signed, but the # response fails to validate for some reason: missing signatures, # expired signatures, signatures with unsupported algorithms, # data missing that the relevant NSEC RR says should be present, # and so forth. I think deferring to that document for definitions of DNSSEC validation outcomes is what the IETF is going to want. Yes, thanks for that info. I obviously wasn't aware of that definition. Would a parenthetical reference to it in that sentence be redundant? 2) After 14 years of working on SSL/TLS for browsers, I can tell you that browsers will all ignore the paragraph that says Clients SHOULD NOT allow users to force a connection I suppose that surprises no-one. If I have anything to say about it (and I intend to), Mozilla will *not* ignore that paragraph. ;-) There's at least a little precedent in the Strict Transport Security specs. All the browsers live in mortal fear of losing market share. Anything that causes users to TRY another browser is to be avoided at ALL COST. Historically, unbypassable security errors have been among the leading causes. The only way to get browsers to do it is to get ALL browsers to do it at the same time. I believe that is not possible. Many failed attempts by lots of people to make that happen back by belief. If you're not on this list, please join it. Customarily, replies go only to the list with no CC's to others. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: FireFox v3.0.1 of Windows uses SSLv2 Record Layer even when SSLv2 is disabled
On 2011-01-27 09:00 PDT, volkerk wrote: I am having the same problem with Firefox 3.0.15, which is suddenly unable to contact our Peoplesoft server and gets the no cypher error. After capturing the packet exchange with Wireshark, I found out the same as Suresh here - Firefox 3.0.15 (Windows) uses SSLv2 message format in the Client Hello (containing a version line of SSLv3 inside), although SSLv2 is disabled in about:config -- and it does decidedly NOT attempt TLS negotiation first, although TLS1.0 is enabled. Manipulating the enabled SSLv3 ciphers makes no difference in this behavior, which isn't surprising. There simply is no initial TLS packet. Firefox doesn't send TLS client hellos to servers that fail to complete ANY handshake with ANY version of SSL or TLS some number of times in a row when it has tried sending TLS client hellos. Once it decides the server is incompatible with TLS client hellos, it stops trying to do that and falls back on some OLD OLD behavior where it sends SSL 3.0 client hellos encapsulated in SSL 2 records. They're actually SSL3 hellos, but the point is that the server has failed too many times. If you restart the browser, the counter will start over and Firefox will try TLS hellos until the server fails too many times in succession again. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME encrypted e-mails
On 2011-01-29 06:41 PDT, Matej Kurpel wrote: Hello, as far as I know, Thunderbird sends encrypted e-mails as an attachment named smime.p7m. Can anybody let me briefly know what this file contains? Yes, it contains a message in the Cryptographic Message Syntax (CMS). CMS is NOT SIMPLE. To understand how it works, and its role in SMIME you really should read and grasp the related IETF RFC standards. They're not small, nor for the faint of heart. But if you want to grok CMS, there's no shortcut.. On second thought, there might be some textbooks... Does that mean the p7m file contains multiple copies of the same message, each copy encrypted using a different key? No. Well ... depends on how you define the same message. The email message (or other major payload) is encrypted once with one key using some symmetric cipher (e.g. AES). Then (in some sense) that one key (which is small) becomes a new message, which is separately encrypted multiple times, once for each recipient. Yes, the P7M holds all those encrypted copies of the key that encrypts the main message, and of course, the ciphertext produced with that key, And cert chains, and capabilities, and ... it's like bread from Bembleman's Bakery, it's what everyone wants. :) Also, it looks like it contains some certificates. Unfortunately, the software I am using (ASN.1 Editor) doesn't read the p7m file despite the fact that it looks as a DER-encoded file at a first glance (even after removing the zero-byte padding). Not DER. It's BER. Zero-byte padding? Indefinite length encoding! Anyone can shed some light on the contents of smime.p7m ? Thanks in advance, M. Kurpel -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME encrypted e-mails
On 2011-01-30 02:30 PDT, Matej Kurpel wrote: On 30. 1. 2011 10:57, Nelson B Bolyard wrote: Yes, the P7M holds all those encrypted copies of the key that encrypts the main message, and of course, the ciphertext produced with that key, And cert chains, and capabilities, and ... it's like bread from Bembleman's Bakery, it's what everyone wants. :) Thank you. Is the symmetric (e.g. AES) key encrypted directly with public keys of the recipients or is it encrypted using some more ephemeral symmetric keys for each recipient and those ephemeral keys are encrypted using the public keys? I thought the second was true but now it wouldn't make sense... Need to clarify it for myself :) Never the second, but there is a third choice: the bulk encryption key (of which there is only one per message) is encrypted using a symmetric algorithm with a key DERIVED from the public key of the intended recipient and the sender's private key. CMS is about giving its users choices, lots of choices, at least two (preferably 5 or 6) ways of doing each and every piece. That makes it a bunch of work to implement, but (probably) makes it future-proof. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Encoding and comparing certificates with NSS
On 2011-01-29 06:06 PDT, Ambroz Bizjak wrote: Hello. I have a problem with NSS. Here's what I'm trying to achieve: [ If I may paraphrase, system C sends a cert to systems A and B. ] [ A forwards its copy to B. B must compare the two copies. ] Here's how I encoded the certificate (on system A once handshake is done, and on B inside the SSL_AuthCertificateHook callback): [snip] Whoa! You (re)encoded the cert from its components in A and B to compare them? Don't! Do compare the original encoded copies made by the cert's issuer. Don't ever count on the ability of a decoder/encoder pair to reproduce exactly what was input. You always have a copy of the original DER encoded one intact in the CERTCertificate. cert-derCert However, now I decided that B needs to know the common name of C before C actually connects to B, for logging purposes. B is going to log about the connection from C before it happens? uh ... It could determine that by parsing the DER cerificate provided by system A. [snip] Is the connection between A and B secure? If not, then an attacker can defeat your design by MITMing that connection. Also, is this a portable way of comparing cetificates (e.g. can I be sure that another SSL library will produce the same data)? I think this means re-encoding the cert from the parts and then comparing the re-encoded certs. IMO, No. Maybe in a perfect world... I read that the DER format is specifically designed so that there is only one way to encode a given input. Yes, that was the design intent. IMO, DER failed to deliver that intent in several ways. Don't count on every issuer doing perfect DER encoding. Is there some function that provides me with the raw certificate as provided by the peer (rather than NSS deconding it and my program encoding it back)? CERTCertificate should have been opaque with accessor functions, but alas. Just reach in and grab cert-derCert. Or, should I be comparing only specific parts of the certificate (common name, public key)? Depends on what you're trying to accomplish, what question you're trying to answer. If the question is merely are these two certs identical then comparing both from stem to stern is a very good way. If you're trying to ask do these two certs identify the same subject, then you may need to do much more work. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: certutil -D corrupting NSS database...
Michael, Can you make available to me the cert8.db file and the nokey p12 files exactly as they were before you did the fateful certutil -D step? If so, I'm interested in trying to track this down. I have a test for you to try that *MAY* (or may not) prove to be a solution for you. I believe you're using cert8.db and key3.db files. Let me suggest that you start over with cert9 and key4.db files, which are sqlite3 NSS DB files. It's easy to do with NSS 3.12.x. You can simply set the environment variable NSS_DEFAULT_DB_TYPE to sql (without the quotes), or you can prefix sql: to the DB directory name argument (usually -d) EVERYWHERE it is found, in every program that uses the DB. I think you may find that the problems you had just go away when using cert9.db files ... or maybe not. You're absolutely right that the bad database errors don't necessarily, or even usually mean database is corrupt. They usually mean that a read or delete attempt failed because the record was not found, or that a write attempt failed because a matching record WAS found and doing the write would have created a duplicate. Most of the time, it just means record not found. But databases have been known to become corrupt and when they do, those not found errors happen a LOT, which is how they came to be (mis)identified as bad database errors. In your case, I think you did achieve database corruption. When you get to the state were certutil -L shows a cert with a nickname (say server) but certutil -L -n server says not found: bad database, that really is a bad database. I think the pk12util step to import the nokeys p12 file may have caused that corruption, and if so, then I'm very interested in fixing it. Just wanted to raise an issue on this list before opening a bugzilla ticket on it but I seem to have run into a circumstance under which deleting a certificate from the NSS database ends up doing the wrong thing with some real confusion resulting that looks like a corrupted or bad database (but seems to be just a poor error message). If you file the bug now, the most accurate thing you can really say is cert8 DB seems corrupt after pk12util import of p12 file with no keys. NSS requires every cert in the DB to have a nickname or email address that it can list out in certutil -L. For cert8 DB, these are actually stored in separate DB tables. Every cert's subject name should appear in exactly one table, nickname or email-address. The command certutil -A adds a record to the nickname table. Certutil -E adds a record to the email address table. Looks like you got a cert whose subject name appears in both tables. Bad news. When it was deleted, one of those two table entries (the nickname) was deleted with it, and the other (email) became an orphan. pk12util has code that will create a nickname to complete a cert import. It will do this if either (a) a cert in a p12 file has no nickname, or (b) the cert being imported has a name collision with a cert already in the DB. I can't be certain which of those applies to you without seeing the files. Another question is: where did the email table entry come from? As I recall, pk12util resolves the above issues by creating a nickname, not by creating an email record, but something created an email record. In any case, cert9 may just clear this all up, so give it a try. Sequence of things I did and the results are below my signature block with a few comments in square brackets... I figure this one is heading for bugzilla one way or the other but wanted to hear others thoughts on it first. Oh... This is on Fedora 13 with nss-util 3.12.8 as well as Fedora 14 with nss-util 3.12.9. Thanks for all the great details. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: FireFox v3.0.1 of Windows uses SSLv2 Record Layer even when SSLv2 is disabled
On 2011-01-30 11:48 PDT, Wan-Teh Chang wrote: On Sun, Jan 30, 2011 at 1:32 AM, Nelson B Bolyard nel...@bolyard.me wrote: Firefox doesn't send TLS client hellos to servers that fail to complete ANY handshake with ANY version of SSL or TLS some number of times in a row when it has tried sending TLS client hellos. Once it decides the server is incompatible with TLS client hellos, it stops trying to do that and falls back on some OLD OLD behavior where it sends SSL 3.0 client hellos encapsulated in SSL 2 records. They're actually SSL3 hellos, but the point is that the server has failed too many times. Here is the fallback code (in Firefox 3.0.x) that Nelson mentioned: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/manager/ssl/src/nsNSSIOLayer.cpprev=1.166mark=3134-3135,3145-3154#3134 I think it is fine to delete the SSL_OptionSet(fd, SSL_V2_COMPATIBLE_HELLO, PR_TRUE) call now. Agreed, we should do this for ... probably too late now ... for FF4. Maybe 4.01 ? -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Force usage of a certificate for client authentication
With my newsgroup/mailing list moderator hat on, I write: PLEASE DO NOT reply to this list by multiple addresses. Please reply to no more than one of the following addresses: mozilla-dev-tech-cry...@lists.mozilla.org dev-tech-crypto@lists.mozilla.org mozilla.dev.tech.crypto newsgroup Now, with my moderator hat off, I write: Hmm it's really weird - the code references seem to indicate that the missing (extended) key usage extension is not the reason for the certificate being filtered out. Correct. But I again checked the trust settings for the CA certificates. They're fine... The browser's trust settings have NO ROLE in the choosing of a client auth certificate when requested by a server. Setting the client's trust flag on a CA, indicating that the CLIENT trusts it for client certificates does not, by itself, make the certificates issued by that CA eligible to be sent by the client to the server in response to server requests for client auth certs. What matters most in such requests is the list of CA that the SERVER trusts to issue client certs. When the server requests that the client authenticate itself by sending a client certificate, within that request the server MUST send the list of CA names that it trusts to issue client certs. The client MUST NOT send back a cert unless that cert is directly issued by, or chains up to, one of the CAs named in the server's list of trusted client CAs. It is a violation of the protocol to do otherwise. So, you can set trust flags in the client until the cows come home, but until the SERVER sends out that CA name in its list of trusted client CAs, an RFC-compliant client will not send any certs from that CA. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox PSM locks NSS
On 2011-01-13 03:58 PDT, Irune Prado Alberdi wrote: I've tried the same test with Chromium and it worked correctly as Wan-Teh said. The database does not get locked. [snip] I had to activate the FRIENDLY flag in order Chrome to correctly obtain the smartcard's certificate. I'm new to Chrome so maybe there's another way to do this. Firefox doesn't require it and asks for the PIN. That's a big clue, I think. The friendly flag tells NSS that the module supports a read only mode wherein it is not necessary to login to read the certificates and other public objects on the device. Without that, NSS assumes that the device only supports read/write mode, and login is necessary to go any access. If your module locks the DB while in R/W mode, that would explain it. Even that is bad, but it's not as bad a user experience when you have the friendly flag set. Try it with FF. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Where to get 'modlogger.pl'
On 2011-01-12 13:18 PDT, Bernhard Thalmayr wrote: Hi Experts, where do I get the script 'modlogger.pl' mentioned in 'http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn2.html'? Sadly, it no longer exists. But IMO, you don't need it. The raw output is equally readable without it, IMO. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to get 'TRACE' build?
On 2011-01-11 13:26 PDT, Bernhard Thalmayr wrote: Hi experts, https://developer.mozilla.org/en/NSS_reference/NSS_environment_variables tells me that I have to build NSS/NSPR with 'TRACE'. Unfortunatley I have not found how to make this build work. I've already search the archive and the code but without success. Uncomment this line in your build tree: http://mxr.mozilla.org/security/source/security/nss/lib/ssl/manifest.mn#39 -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS 3.12.5: Error '-8023' ... how to track it down?
Bernhard wrote: 331569088[1bd1610]: flags = 0x4 331569088[1bd1610]: pApplication = 0331569088331569088[1bd1610]: Notify = 0x13231f31569088[1bd1610]: phSession = 0x7fffc331569088[1bd1610]: phKey = 0x36c1618 331569088[1bd1610]: CKA_CLASS = CKO_SECRET_KEY [8] Was that a copy and paste error? Or does the file really look like that? Should look like this... 331569088[1bd1610]: pApplication = 0331569088 331569088[1bd1610]: Notify = 0x13231f333 331569088[1bd1610]: phSession= 0x7fffc 331569088[1bd1610]: phKey= 0x36c1618 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to get 'TRACE' build?
On 2011-01-12 13:53 PDT, Bernhard Thalmayr wrote: Although I've only done a debug build I get an ssl-trace file starting with .. SSL: tracing set to 127 SSL: debugging set to 127 12676: SSL: grow buffer from 0 to 18432 12676: SSL: grow buffer from 0 to 18432 12676: SSL[107778448]: secure connect completed, rv == 0 12676: SSL[107778448]: SecureSend: sending 37 bytes 12676: SSL[107778448]: sending client-hello 12676: SSL: grow buffer from 0 to 18432 12676: SSL[107778448]: dump-msg: Client-Hello . Would the 'TRACE'-build show even more info? No. I seem to recall that trace is on by default in debug builds, and only needs to be turned on explicitly (if desired) in non-debug builds. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox PSM locks NSS
On 2011-01-11 04:48 PDT, Irune Prado Alberdi wrote: I'm trying to access a NSS shareable database (3.1.2 with NSS_DEFAULT_DB_TYPE=sql) while having a Firefox NSS session already initialized over the pkcs11 module of my smartcard. My test is really simple but I don't get to know why firefox locks the database. Up to this point I can properly work with my certificates in firefox but when I try to simultaneously access it via certutil I get blocked ~/.pki/nssdb$ certutil -d sql:. -K -h izenpe While if I terminate the pkcs11 session in firefox I can successfully acces the token Bob, This seems pathological. This is very bad news for programs (e.g. servers) that want to really share a sqlite3 DB. Did some member of the NSS team change NSS to hold a lock on the sql DB as long as NSS has the DB open ?? Or, did some sqlite3 change have this effect? -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 2010-12-27 01:44 PDT, Matej Kurpel wrote: If I only was able to load the source code of Thunderbird in Visual Studio, that would be great. I could debug it line-by-line as usual. You can. Download and unpack the sources from ftp://ftp.mozilla.org/pub/thunderbird/releases/latest-3.1/source/thunderbird-3.1.7.source.tar.bz2 (or substitute the release you're running, as needed). You don't need to build it yourself. Use the symbol server (You've already done this step, IIRC). Just tell your debugger where you put the sources locally. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 2010-12-27 10:39 PDT, Matej Kurpel wrote: Wow - I was able to Attach To Process... in VS2008 and then I caused the crash deliberately. Bravo. It showed me the source code and call stack, which is great. But evaluating most of the variables returned CXX0069: Error: variable needs stack frame. No idea what that means. The code at which you were looking was compiled with Frame Pointer Optimization (FPO), which causes the compiler to NOT use one of the registers for its usual purpose, acting as a pointer to the function's local variables, and instead use it as a general purpose registers. The debugger you're using is confused by that. I don't know how you can work around it. Assuming that you ARE using the symbols from Mozilla's symbols server, perhaps you need to use a newer version of the Visual Studio debugger. Perhaps you need to tell your VS Debugger to expect FPO somehow (e.g. a settable option). You might ask about this debugging issue in mozilla.dev.builds. I think if anyone would know how to work around FPO, they would. In any case, the code you're examining is not NSS code nor PSM code. The people in this group are not the experts in that code. You need help from the Thunderbird developers. I am sending you the call stack as VS displayed it to me. It crashed on a line in nsGlobalWindow.cpp saying: nsWindowSH::InvalidateGlobalScopePolluter(cx, currentInner-mJSObject); saying Uncaught exception occurred. Call stack: The stack you supplied shows a NULL value for aState being passed several levels down the stack. That's suspicious, but not necessarily a bug. I'd suggest you find the caller that first passes that NULL value, and look at the code that does that. Perhaps you will find some clues about the problem there. Anything more I could do? Yes, file a bug report in bugzilla.mozilla.org, product Thunderbird. Include all the stack info and other info you provided in the email to which I am responding. If you have Thunderbird crash IDs (look like GUIDs) that might have been previously reported by your TBird to Mozilla, include those. But don't expect a quick response. You may add my email address to the CC list on your new bug report. That won't hasten a solution, but it will satisfy my curiosity. :) Regards, -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
On 2010-12-19 00:56 PDT, Marsh Ray wrote: On 12/19/2010 02:27 AM, Nelson Bolyard wrote: Yes, Mozilla builds its own CRT, which is a modified version of the MSVC CRT, whose sources come only with the pay (not free) versions of MSVC. They do this in order to replace MSVC's normal heap code (malloc) with their own JEmalloc. Mozilla's source repository doesn't include ANY of the MSVC source code, but only includes a ed script that patches that source without including any of it. Sadly, this means that people with the free MSVC cannot build MOZCRT19, because they lack the sources to be patched. IMO, this is a flaw for an open source project, but ... :( Can you build it against the compiler's CRT if you want to? Not that I'm aware. But I've never tried. Well, I think the big question is: why does the heap allocation fail? You need to track down where the first error occurs. My first wild guess is that Matej's PKCS#11 module is doing something bad to the heap. Like if Matej's module were linked to some other CRT and an interface passed memory that way. Historically, having multiple CRTs in the same process has been a recipe for disaster on Windows. I was thinking of allocating a buffer of size N and then writing past the end of it. That's the most common problem, IMO. My second one is that NSS or PSM is trying to free to the MOZCRT17 heap something that was allocated from another heap. Or perhaps vice versa, but wouldn't that likely have thrown at the point of the bad free or delete? Not clear. The debug CRT would catch such thing at free/delete time, but not clear that any other CRT would do so. Actually, in retrospect, I think it's doubtful that this second guess is the problem, because the PKCS#11 API doesn't ever pass allocated memory from one side of the API to the other, for the receiving side to deallocate. Generally, the process using the module allocates all memory, and frees what it allocated. It asks the PKCS#11 module to take data from, or put data into, the memory it supplies, but the module should never free memory passed in to it, and never outputs the addresses of memory that it has allocated. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird crashing when C_SignInit returns other than CKR_OK
Matej,
Your message contains an obvious self-contradiction. Observe:
On 2010-12-10 09:57 PDT, Matej Kurpel wrote:
CK_RV CK_ENTRY C_SignInit(CK_SESSION_HANDLE hSession, CK_MECHANISM_PTR
pMechanism, CK_OBJECT_HANDLE hKey)
{
return CKR_FUNCTION_CANCELED;
}
89: C_SignInit
[in] hSession = 0x2
pMechanism-type=CKM_RSA_PKCS
[in] hKey = 0x2
Returned: 84 CKR_FUNCTION_NOT_SUPPORTED
Are you perhaps not testing with your own latest builds, or something?
--
/Nelson Bolyard
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: importing leaf cert into NSS db via JSS
On 2010-12-10 03:45 PDT, David Stutzman wrote: On 12/9/2010 2:29 PM, Wan-Teh Chang wrote: The (-8157) Certificate extension not found part is most likely wrong (a stale error code). Please try to track that down and fix it. I remember Nelson saying pretty much anytime that error pops out it's a bug in NSS. Right. I think Wan-Teh was suggesting you trace/step through the NSS code and find the function that returns without setting an appropriate error code in your test case. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certificate login in Firefox - how does it work?
On 2010-11-26 13:20 PDT, ryan-mozdevtechcry...@sleevi.com wrote: [snip] And to save you a bit of trouble/pain: for CryptoAPI, you cannot simply sign raw data - you can only sign previously hashed data. I understand this to mean that you cannot write a pure PKCS#11 - CryptoAPI mapper, whether .NET or at the raw Win32 level, because the CryptoAPI specifically forbids signing raw data of arbitrary length, while PKCS#11 permits it [7]. Your best bet, and a common approach for the specific case of TLS client authentication, is to combine CryptCreateHash/CryptSetHashParam(HP_HASHVAL)/CryptSignHash. [snip] [7] http://msdn.microsoft.com/en-us/library/aa380280(VS.85).aspx Ryan, Thanks for your comprehensive answer to Matej's question. I suspect that not many readers of this list are very familiar with the crypto capabilities of .NET. Speaking of CryptSetHashParam(HP_HASHVAL), http://msdn.microsoft.com/en-us/library/aa380270(VS.85).aspx says: HP_HASHVAL. A byte array that contains a hash value to place directly into the hash object. [snip] Some cryptographic service providers (CSPs) do not support this capability. Do you know which, if any, of Microsoft's CSPs do not support it? -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS ss-sec.uncache is NULL
On 2010-11-24 11:17 PDT, passfree wrote: Speaking of firefox, I know it is not meant to be used as a server but it does provide server sockets through nsIServerSocket interface. I'd say it's a BUG in PSM if it offers a way for XPCom users to use NSS server sockets, but doesn't offer any way for them to initialize the server caches. That bug should be fixed. That's the right solution. IMO, the solution is not to run without any server cache. It is to run with at cache that is at least a small one. When the nsIServerSocket interface is called to create a server socket, that code should check to ensure that the server cache is initialized, and initialize it (atomically) if not. A PSM patch to do that would probably be welcome. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CMSUTIL Problem
On 2010-11-10 05:41 PDT, stephen.mocca...@gdc4s.com wrote:
I am on a Linux system and I am trying to send a signed email message
using cmsutil and the smime toolkit but it fails with the following
error:
cmsutil: the corresponding cert for key (null) does not exist:
Certificate key usage inadequate for attempted operation.
Hi Stephen,
There's so much to say here.
I see at least three different issues there.
- 1) the report cert for key does not exist.
- 2) the string (null). That's annoying, but I think it's a red
herring. We should deal with it, but I think it's a symptom, not the
cause, of other problems here.
- 3) the error inadequate key usage.
I suspect that only at most one of those is a real problem, and the others
are simply side effects of the real problem. I'm going to suggest a
number of parallel paths for you to explore.
1. The inadequate key usage problem. I think it's possible that the
cert IS being found (despite all the apparent evidence to the contrary,
but the cert simply has some extension that makes it ineligible to be
used as an email cert. Fortunately, we have a way to determine that.
We know that the pk12util program is able to read your Email.p12 file
so use pk12util's -l (dash ell) option to list the content of the file.
It will pretty print out the details of all the certs in that file.
It won't print out any details of the private key, except to say if it
found a private key there or not. If you can show us the pretty printed
output for that email cert, as shown by pk12util, we can tell by
inspection if the cert really has a key usage problem. If it does, that's
the real problem, and the solution is for you to get another cert from
your CA.
2. The (null) problem, which suggests that the nickname you've given
isn't making it successfully through the smime perl script into the
cmsutil program. I doubt that the length is an issue. I've seen much
longer nicknames than that. But I think the apostrophe (') in the middle
might be an issue. The smime script tries to remove and add back
quotation, and it may do a poor job. You might try inserting some number
of back-slashes {\) immediately before the apostrophe. Try 1, then if
that doesn't work, try 2 ... then 3, ... up to about 5. Hey, they're
cheap. :) You might also try collecting the file of data that smime
feeds to cmsutil, and then try invoking cmsutil directly yourself rather
than through the smime script.
3. In any case, if it IS a nickname problem, you don't need a new
certificate. You need a new nickname. The nickname is not part of the
certificate itself. It is a string carried along with the certificate in
the PKCS#12 file. It's possible to change the nickname without changing
the certificate. There are numerous ways to do this. Let me suggest
some. (Put your beverage down now, lest you have an accident.)
a) Use OpenSSL to explode the PKCS12 file into a bunch of PEM files, one
for each of the certs and private keys in the original PKCS#12 file,
then use OpenSSL again to make a new PKCS#12 file with a new nickname
from those PEM files. I'm told this works, but I've never done it.
Be sure to clean up the exploded files after that.
b) Use MS Windows Cert import and export wizard. Import your PKCS#12 file
into a personal cert store in Windows, where the nickname will become a
friendly name. Then, use Windows' cert manager snap in to
edit the friendly name of the certificate. This is actually a rather
nice GUI for doing that. Then invoke the export wizard from the cert
manager to export the cert with the modified friendly name into a new
PKCS#12 file. This is equivalent to to the OpenSSL approach above,
except that it leaves a copy of your cert and private key in Windows'
personal cert store. Reformat your your hard disk after that. :)
c) Back up your original PKCS#12 file, then examine it with some program
that lets you inspect the contents of binary files, to see if the
nickname in it has been encrypted or not. If so, you won't see the
nickname in there anywhere. If not, you'll see it. Then, use a binary
file editor to edit the file and change the nickname. Change that
apostrophe to something benign, like a space or dot. Then start over with
a fresh cert and key DB and attempt to import that edited file. Can't
promise this will work. If you have the tools, the experiment
will take very little time. You might get lucky.
d) Back up your cert8.db file, and use a binary editor to find the
nickname and edit it. It definitely will not be encrypted. Change the
apostrophe to a space or a dot. Be SURE the file is not in use by ANY NSS
program when you do that! This is what I'd try first, but then,
I'm something of a masochist when it comes to NSS. :)
I have a pkcs12 file I loaded into the nss database with the following
command:
pk12util -i Email.p12 -d ./database
I have also loaded the root CA certs using:
certutil -A -d ./database -n gdca-root -t CT,C,, -i
Moderator note: Happy Day - newsgroup moderation has begun (I think)
This morning, in the moderation queue for this list, I found a message that was different from others I'd seen before. It appeared to have originated as a newsgroup posting at google. I'm still not 100% sure if this was a moderated newsgroup posting, or if the poster merely sent it both as a newsgroup posting AND as an email to the list. But I'm optimistic that this is the start of a new era of reduced spam for both the list and the newsgroup. The historic first message of its kind (if that's what it was) bore these headers: Subject: Re: Issues with ActiveClient Smart Card Middleware with Firefox/Thunderbird Windows 7 From: Ridley (a gmail address) Congratulations, Ridley, on being the first. You're now white listed. No more moderation delays for you. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On 2010/10/29 01:44 PDT, Nelson B Bolyard wrote: No, passwords simply have NO PLACE in protecting the average user from phishing. And it doesn't matter whether the password is used to derive a session encryption key, or just as an authentication token. The user is just as vulnerable either way. Illustrative case history: http://imgur.com/cNorB -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On 2010/10/28 03:12 PDT, Jean-Marc Desperrier wrote: Nelson B Bolyard wrote: [...] It because none of them: J-PAKE, SPEKE, SRP, or for that matter, good old CRAM-MD5 address the NUMBER ONE problem with passwords. PHISHING. They are a very significant progress with regard to that actually. What do JPAKE, SPEKE and SRP claim to give you that CRAM-MD5 does not? ZERO-KNOWLEDGE That's resistance to something other than phishing. That's dealing with an untrustworthy peer, with whom you WANT to trust, to the point that you do give that party an authenticator of some sort. That's NOT the big problem. The server can not attack by brute-force the content of the exchange to deduce what you password is. Right, so the attacker just asks you for it, very convincingly. Now, that's not it : What they truly bring is that if you are misled into making an handshake with a phishing site, you don't give to that site any information about what your password might be. Sorry, untrue. The attacker puts up a password dialog. You type your password into it. You give away your password. Maybe YOU (JMD) don't, but then, you (JMD) aren't the typical phishing victim. You have a good idea what to look out for. The phishing victim does not, and so enters his password anywhere that asks, because he cannot (or will not) distinguish between the places where he should and those where he shouldn't. If you are tricked into making the handshake with the wrong site, there's no bad consequence. Right. That attack is not to get you to HANDSHAKE with the wrong site. It's to get you to connect to the wrong site that ASKS YOU TO ENTER YOUR PASSWORD. So the risk is to be tricked into entering your password inside a field that doesn't do a handshake, but instead just sends copy of it to the pirate. Right. Therefore password exchange solution that relies on you entering the password inside a standard web page are still strongly vulnerable to the phishing problem, and there's no progress over older password schemes. Right. But if the password is entered inside an element that is unambiguously the GUI of your browser, web site can not do a phishing attack against it any more, and the solution is actually quite good. ... ASSUMING that the user is bright enough to understand the difference between chrome and non-chrome, and which one is trustworthy ... but years of experience have shown us that most users are not. For years, and to this very day, web sites put lock icons in the pages to try to convince the users that the page is secure. My own bank does it! MOST users still have no clue about trust of chrome vs trust of web page content. Not a clue. I had a bank account executive sit in front of a browser once, and instruct me in how to use the browser to do on-line banking. I sat through his presentation (despite having been a user of online banking for over a decade by then) to see how well HE understood it. He informed me that he was specially trained by his bank to train customers in how to lower their risk of being swindled. The FIRST THING he told me was to look for the lock icon in the web page content to be sure I was looking at a secure page, before typing in my bank password. I asked him what was the difference between that lock icon and the one down in the corner of the window, against the background that matched the window border (he was using MSIE). He had never noticed that lower icon before, and had no idea what it meant. So much for his special training. No, passwords simply have NO PLACE in protecting the average user from phishing. And it doesn't matter whether the password is used to derive a session encryption key, or just as an authentication token. The user is just as vulnerable either way. A password user's best protection against attack is simply appearing to be a low-value target. There are so many of them waiting to be attacked that the trick is to appear to be less worth attacking than one of the millions of others. Therefore the actual gap in security between the two is : - A : An attaquer that find a way to create a windows that tricks users to believe it's the genuine Firefox GUI for the password, without having to use chrome privilege. No need to convince the user that it's genuine Firefox GUI because the user has no idea what the significance of that is. Any ordinary web page with a password field in the page content will suffice. - B : An attaquer that uses the usual weaknesses of passwords to get access without phishing the user. Those usual weaknesses being that passwords are frequently very weak, but the worst I believe is that users frequently reuse them. So the attacker could obtain the value of the password of the user at another site, and use it to guess accurately what he's using at the protected site. Yup. That's another reason why you don't want
Re: Invalide certificate encoding crashing certutil [Re: Thunderbird: Could not verify this certificate for unknown reasons]
On 2010/10/28 02:14 PDT, Jean-Marc Desperrier wrote: Nelson B Bolyard wrote: Please don't file a bug without a stack trace showing the crash is in NSS. [...] If the back trace shows the crash is not in NSS, but in some other library, please direct the bug report accordingly. The report is that the crashs is inside NSS's certutil, Nelson. Perhaps I have confused this Matej with another. I understood that Matej is developing his own PKCS#11 module, and his report is that NSS's certutil crashes when run with his non-NSS PKCS#11 module. The crash may well be in that module. Matej, If I'm confused, feel free to set me straight. As Thunderbird with the same data doesn't crash, it doesn't seem to actually be in the library, but even just in a NSS tool, a crash is serious. Show me that the crash occurred in NSS code, and not in the code of some PKCS#11 module, and I'll be more convinced. A bug report that says nothing more than I ran this program with this other PKCS#11 module and it crashed won't yield any desirable results, unless someone happens to say Oh I saw that too and fixed it by -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Invalide certificate encoding crashing certutil [Re: Thunderbird: Could not verify this certificate for unknown reasons]
On 2010-10-26 05:07 PDT, Jean-Marc Desperrier wrote: Matej Kurpel wrote: However, how does a printable string differ from utf8string (and other strings, particularly ia5string) when there are no non-ascii characters? Do you think it's a bug in NSS...? printable string basically allows only the alphabet and numeric characters. ia5string allows all of 7-bit ASCII. For both, any character with the eighth bit set will be invalid. A crash when meeting invalid data is always a bug, especially for a security tool. Even if here it seem to only be a bug inside the certutil tool, not inside the NSS library component themselves. Please don't file a bug without a stack trace showing the crash is in NSS. When your program crashes, it should create a file named core or core (where X is a number that varies). You run the gdb debugger pointing it to the executable and the core file, and give it the command bt (Back Trace), and it does the rest. If the back trace shows the crash is not in NSS, but in some other library, please direct the bug report accordingly. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird: Could not verify this certificate for unknown reasons
On 2010-10-24 02:12 PDT, Matej Kurpel wrote: [snip] You can clearly see both my CA and user certificates. Certutil has used my PKCS#11 module to obtain my user certificate. Then I launched the second commany you were suggesting: certutil -d . -L -n HTC Touch HD T8282:Matej Kurpel Now it popped up a message that certutil.exe has stopped working. From my PKCS11-spy logs it's apparent that it searched for the certificate, found it, got some of its atttributes, and then searched for a private key belonging to this certificate (and found it): FindObjectsInit - FindObjects - FindObjectsFinal. That's all it did and then crashed. Looks like something is wrong with my certificate but how can I check it when certutil is crashing? Maybe something is wrong with your PKCS#11 module, or maybe something is wrong with certutil. What does the stack backtrace from the crash show you? -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird: Could not verify this certificate for unknown reasons
On 2010-10-21 13:31 PDT, Matej Kurpel wrote: This looks like Thunderbird cannot find the user certificate in its database. Well, it shouldn't anyway, since it resides on the token provided by a PKCS#11 module I am developing. Right. It's not necessary for the cert to be in the database. It's only necessary that NSS can find it in one of the attached tokens. However, in its properties it says it couldn't verify the certificate for unknown reasons. And the CA certificate is added into the authorities correctly. Any more ideas, please? For purposes of your command line testing, you should add your PKCS#11 module to the secmod.db configuration file, using the modutil program. Thereafter, you should be able to get the command line utilities to see and attempt to verity the certificate in your token. I'd tell you how to do that, but you seem to be doing VERY VERY well at figuring it out on your own! Here are some hints: certutil -d . -L -h all certutil -d . -L -n my token name:my cert name -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: JSS4.DLL and JSS.jar for Windows 64 bits
On 2010-10-22 07:39 PDT, stephen.mocca...@gdc4s.com wrote: Thanks. I'll try it. Stephen Moccaldi General Dynamics C4 Systems, Inc. stephen.mocca...@gdc4s.com 781-455-5466 This message and/or attachments may include information subject to GDC4S O.M. 1.8.6 and GD Corporate Policy 07-105 and are intended to be accessed only by authorized recipients. Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties. Recipients should refer to the policies or contract to determine proper handling. Unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender and destroy all copies of the original message. Stephen, (and other readers of this list): I'm the moderator of this list. Please remove legalese like the above from any messages to this list. This list goes to public servers where it can be read by anyone in the world. When you send a message to this list, you are authorizing everyone on the world to read it. Consequently, those silly dire and legally unenforceable warnings to unauthorized readers have no place in messages to this list. This is explained on the sign-up page for this list, which everyone presumably reads and agrees with before subscribing: https://lists.mozilla.org/listinfo/dev-tech-crypto If the moderation software that Mozilla uses was capable of it, I would filter messages to this list to catch legalese like that, and bounce those messages back to their senders, but alas it does not. So, until it does, I can only ask you all to please comply. Thanks. /Nelson B, moderator dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PARAMORE MP3
Gerv, On 2010-10-22 01:25 PDT, Jan Huynh wrote: Click Here to Enter: http://better-web-365.com/12/paramore-mp3 . . Paramore Mp3 Paramore Franklin Free Mp3 [Hundreds of lines beginning with the word Paramore deleted] This is clearly a failure of the new newsgroup moderation, and of the news-mail gateway's filter ... unless those things are not yet in place. I thought they were going to be in place starting earlier this week, with the result that there would be propagation problems from news-mail. Sadly, there appears to be no propagation problem for spam from news-mail. :( What's up with that? -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
This is a resend. Don't know why my previous copy went only to Marsh. I intended it to go to the list as well. On 2010-10-21 16:50 PDT, Marsh Ray wrote: On 10/21/2010 05:53 PM, Nelson B Bolyard wrote: - Letting mozilla products become a playground for home-baked crypto protocols. That's a gate you'll find difficult to close once it is allowed to be opened. Since when have Mozilla products not been a playground? It IS a playground, in the sense that people can develop add-ons to do whatever their hearts desire, and Mozilla actively encourages that. I'm referring to the functionality in the base product, and particularly to the security functionality in the base product. Users expect that Mozilla product security, out of the box (so to speak), with no add-ons present, is going to be very good. And once added, features are seldom removed. Look at how long it is still taking to get browsers to be secure with respect to renegotiation out-of-the-box. It's because users have become dependent on that bad old stuff and won't let go, even if it's bad for them. Who put up a gate in the first place anyway? Would you really have app developers go elsewhere for bignums? I'm talking about putting JBAKE (or whatever it is) into the base product. That's the motive behind this request. It's not for add-on developers. It's because someone wants to put Do you really think it would inhibit anyone from baking with crypto? I don't care about what people do with add-ons. They're not even at issue here. I do care about what Mozilla offers to its users in the products that bear its name, under the pretense of security. Security isn't about a pile of cool-sounding features. It's about assurances. There are people within Mozilla who want to add to the feature list, want to have more bragging rights, want to claim to be the first with some new buzzword. That's utterly harmless when the new buzzword is some new UI feature that changes pixels on a screen, but in the security space, more care is needed to maintain the assurances. I want my playground and Easy Bake crypto oven. Or, more precisely, it bugs me that an open project like Mozilla would restrict tools on the too dangerous for mere mortals principle. Marsh, Most users have no idea, draw no distinction, among the various security protocols, mechanisms, schemes used within a product like their browser. They have no idea where the responsibilities of a protocol end and the responsibilities of the program's UI begin. When their security is violated, they just lump it all together. That's why SSL/TLS keep getting smeared for faults that are purely UI faults. We read, monthly if not weekly, pronouncements in the press saying that SSL has failed because users clicked past security warnings, or because the browser was fooled by some clever web page content (e.g. JavaScript) into displaying the wrong information to identify the source of that content, or because badly-designed browser security UI, which is utterly indistinguishable from web page content, is subverted to fool users into taking actions that harm their own security, or simply because users continue to fall for emails bearing dire warnings that appear to come from their banks, that make them SO upset that they fail to notice the web page into which they typed their bank password was NOT their bank's page. None of these problems is in any way a fault of the SSL/TLS protocols, but even readers of this group have tried to argue that they are. So, when it comes to user security, Mozilla needs to take care about who it lets into its bed. One foul piece of security in the base product will besmirch ALL the product's security features. cheap_shot So if Mozilla's got such high standards on authentication and such, they can put up even one add-on that doesn't say (Author not verified) in my browser: https://addons.mozilla.org/en-US/firefox/addon/15003/ https://addons.mozilla.org/en-US/firefox/addon/11950/ /cheap_shot I don't think it's a cheap shot. I'm not wild about that, either. I think it does show, however, a difference in degree of care between things that are offered as products of Mozilla versus addons by whomever. That's appropriate, to some degree, in my opinion. I'm just trying to ensure that the newest comer to Mozilla's security development community is aware of some of these issues. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On 2010-10-22 11:35 PDT, Wan-Teh Chang wrote: On Thu, Oct 21, 2010 at 3:53 PM, Nelson B Bolyard nel...@bolyard.me wrote: I'd say the interfaces to those functions (more precisely, their signatures) are quite frozen. The mp_int bignum package API is so frozen as to have become something of a standard of its own. There are now at least 3 different implementations known to me that are all API compatible, differing only in the content of the (opaque) mp_int structure itself. Speaking only for myself, I have no objection to offering the mp_int bignum API as a public API out of freebl3. They're not presently exported from the freebl shared lib at all, but IMO, they could be. We merely wanted to minimize the exported API. We also need to undo some processor-version-specific type definitions. An example is the mp_digit type for 64-bit Solaris SPARC. mp_digit is defined differently for different versions of the SPARC v9a processors: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/Makefilerev=1.115mark=420-432#420 Hmm. The mp_int struct itself should be opaque in a public definition. So there shuold be no need to change the machine-dependent definitions of the contents of that struct (including the array to which it points). But I know that mp_digit is also used for types in the function signatures, and that IS an issue... I think this says that the task is feasible but requires more time to think about all its implications. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On 2010-10-20 17:13 PDT, Brian Smith wrote: See https://bugzilla.mozilla.org/show_bug.cgi?id=601645. The following internal functions and data structures in FreeBL that would be used Firefox 4.0 Sync's J-PAKE implementation through JSCtypes (a mechanism for calling native code through Javascript). I personally would like to find a way to avoid calling these internal functions from within Firefox--especially since there's no way to detect incompatibilities at compile-time and because the interface to these functions isn't frozen. To what functions are you referring when you say the interface to these functions isn't frozen. ?? The functions you listed below (which I haven't copied here)? I'd say the interfaces to those functions (more precisely, their signatures) are quite frozen. The mp_int bignum package API is so frozen as to have become something of a standard of its own. There are now at least 3 different implementations known to me that are all API compatible, differing only in the content of the (opaque) mp_int structure itself. Speaking only for myself, I have no objection to offering the mp_int bignum API as a public API out of freebl3. They're not presently exported from the freebl shared lib at all, but IMO, they could be. We merely wanted to minimize the exported API. But cryptography isn't the only user of bignums, and IMO, it doesn't make sense to for Mozilla to have yet another bignum library when NSS's is suitable for most purposes. The hash functions you mentioned ARE already exported and there's even a public API for them (albeit slightly different, as Bob has explained). IMO, apart from the mundane technical issue of making hash and bignum functions public, there are some bigger questions, such as: - the wisdom of making Mozilla products even MORE dependent on shared secrets and passwords than they already are, when, for at least a decade, shared secrets in general and passwords in particular have been regarded by security experts as more part of the problem than part of the solution. - Letting mozilla products become a playground for home-baked crypto protocols. That's a gate you'll find difficult to close once it is allowed to be opened. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Discussion forums anti-spam: configuration change
On 2010-10-19 01:23 PDT, Gervase Markham wrote: At 11pm Pacific Time on Tuesday night (6am UTC on Wednesday morning) we are implementing[0] the new discussion forums anti-spam plan[1] on the following guinea pig groups: mozilla.community.philippines mozilla.governance.mpl-update mozilla.dev.tech.crypto mozilla.tools This has been agreed with those responsible for those groups. I think I'm responsible for (moderate) this group, and I only just learned about this from this posting of yours. Nonetheless, I'm quite happy for this group to be among your guinea pigs. Thanks. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird: Could not verify this certificate for unknown reasons
On 2010-10-20 09:54 PDT, Matej Kurpel wrote: Hello, I have set up my own CA and issued one certificate signed by this CA. However, I cannot use this certificate to send signed e-mail from Thunderbird. It says Could not verify this certificate for unknown reasons. PSM's infamous for an unknown reason error message, the bane of my existence for about a decade now. See https://bugzilla.mozilla.org/show_bug.cgi?id=desired When any NSS function fails, NSS always provides a reason code. But years ago, the manager of the group responsible for implementing the GUI for Mozilla's crypto security decided that error details were unimportant, and so, to save schedule time, he allowed his employee to do a very incomplete job of producing error message strings for the various error codes, and simply present a default string in all other cases that says for an unknown reason. We've been plagued with that ever since. In all the years since then, it has never been important to Mozilla UI folks to fix this. It seems to be an entrance requirement to get into GUI design school. They ask you is security UI design important?, and if you say yes, or even hesitate to say NO!, you're out. (HELL NO! is the preferred answer.) So, here's what you do. Use one of NSS's command line tools to verify your certificate chain for the email certificate usage, and see what it says. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11: C_Sign provides invalid signature
On 2010-10-16 06:25 PDT, Matej Kurpel wrote: Hello, I am developing a PKCS#11 module to be used with Thunderbird. However, I have trouble providing a valid signature for e-mails. The mechanism used is CKM_RSA_PKCS and I have a 1024bit private key along with the certificate, stored on the token. The signature is generated in a C# .NET CF program running on the device, using this piece of code: RSACryptoServiceProvider rsa = PKCS11Library.TryLoadPK(Encoding.ASCII.GetString(keyPath, 0, keyPath.Length), out keyRawData); // this returns a valid RSACryptoServiceProvider instance signature = rsa.SignData(data, new SHA1CryptoServiceProvider()); //signs the data we need I am not sure about the second parameter of the rsa.SignData method - the documentation says it is of type object and it's the mechanism to be used to sign the data. I cannot think of any more appropriate object to be passed there than SHA1CryptoServiceProvider. This isn't really the place to come for advice about C# crypto ... but ... the SignData method provides the wrong level of functionality for CKM_RSA_PKCS. The entire RSA signature creation process usually includes these steps: 1) Choose a hash algorithm (e.g. SHA-something or MD5), get the OID string (number) value that identifies that algorithm, and use that algorithm to hash all the data to be signed. 2) Construct an ASN.1 DER formatted buffer called a DigestInfo using that OID string and that hash value. 3) Construct a PKCS#1 formatted buffer (either v 1.5 or v2.0) from that DER formatted buffer. 4) Perform an RSA private key operation on that PKCS#1 formatted buffer. In some applications, steps 2 and/or 3 are modified, and custom buffer formats are used instead of the pure DigestInfo and/or PKCS#1 formats. The CKM_RSA_PKCS mechanism you're attempting to implement does only the last two of those steps. It treats the input it is given as a DigestInfo. It then does the PKCS#1 formatting according to PKCS#1 version 1.5. This gives its user the flexibility to implement the normal DigestInfo buffer format, or any other custom format. PKCS#1 Version 2.0 formatting is incompatible with CKM_RSA_PKCS. PKCS#1 Version 2.0 formatting is done by another PKCS#11 mechanism, namely CKM_RSA_PKCS_OAEP. The SignData method you're trying to use does all the above steps. It wants the input to step 1. Since you're implementing CKM_RSA_PKCS, the data you're given is the input to step 3, the output from step 2. You can deconstruct it and obtain from it the output from step 1, but you cannot go back to having the input to step 1, because the hash is irreversible. So, I think you cannot use SignData to implement CKM_RSA_PKCS. C#'s RSACryptoServiceProvider class also features a SignHash method that does the last three of those steps. It expects to receive, as input, the hash value and the OID string. It constructs the DigestInfo and the PKCS#1 buffer and does the RSA private key operation. Whether it formats the PKCS#1 buffer according PKCS#1 version 1.5 or version 2.0 is unknown to me. I couldn't find any reference to PKCS in MSDN's C# documentation. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11: C_Sign provides invalid signature
On 2010-10-16 11:39 PDT, Matej Kurpel wrote: On 16. 10. 2010 18:33, Nelson B Bolyard wrote: The SignData method you're trying to use does all the above steps. It wants the input to step 1. Since you're implementing CKM_RSA_PKCS, the data you're given is the input to step 3, the output from step 2. You can deconstruct it and obtain from it the output from step 1, [...] Thank you, Nelson, it works now. I used the SignHash method instead, with the OID string 1.3.14.3.2.26, which means SHA1. And I took just the last 20 bytes of the provided data to sign - which is the hash. You should not assume that the DigestInfo you're given will always contain a SHA1 hash. It may contain other hashes from other algorithms, of other lengths. It will always contain the proper OID string for the hash it has used. So, you should parse the DigestInfo you're given as input. Take it apart. Pull out the OID string and the hash string using the explicit lengths encoded in the DigestInfo, then pass those to SignHash. Parsing the DigestInfo is very straightforward. I'm sure you can figure it out. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: how to modify the absolute profile path in secmod.db
On 2010-10-08 10:58 PDT, al...@yahoo.com wrote: I noticed when moving a profile that secmod.db retains the old absolute profile path (configdir='...') Is the path used for anything? Does it need to be updated? How? Can secmod.db be deleted and regenerated? What are the consequences? The answer to this question can be found on Mozilla web sites, if I'm not mistaken. Yes, you may delete this file, and your Mozilla program will create a new one. If you use any third party crypto software or hardware, your mozilla program will no longer know about that and will no longer use it. You will need to reconfigure your mozilla program to know about it. But if you don't have any such third party stuff, then Mozilla's automatic file re-creation is all you need. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS and PKCS#11 Certificate+Private key
On 2010-10-10 07:45 PDT, Matej Kurpel wrote: Never mind, solved it myself. What turned out to be the problem, was that the CK_BBOOL values were 4-bytes and not 1 byte in size. Glad you figured it out. I think we could not have helped you without a LOT of work and looking at your code. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: ssl stream pipe
On 2010-10-02 09:11 PDT, passfree wrote:
The problem is within the write method of the component which fails
for some unknown reasons. Here is the code I am using for testing:
char b[] = { 12345 };
int result = PR_Write(sfd, b, 5);
if (result = 0) {
printf(%d\n, PR_GetError());
return NS_ERROR_FAILURE;
}
You say unknown reasons, yet your code sample appears to print out
the error code. What error code does it print out?
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Can a ssl3.ca_list be configured on a model file descriptor?
On 2010-09-16 00:54 PDT, Wolter Eldering wrote: Hi, I have configured a model file descriptor using SSL_SetTrustAnchors(PRFileDesc *fd, CERTCertList *list) The ssl3.ca_list information set in the model is not copied into the new file descriptor when calling PRFileDesc *SSL_ImportFD(PRFileDesc *model, PRFileDesc *fd); Thank you for filing the bug report in bugzilla. Could it be that the SSL_SetTrustAnchors() should be called every time on the PRFileDesc returned by SSL_ImportFD()? That's not the intent, but it probably works as a work-around. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Enforcing Definite Encoding on Constructed CMS Objects
On 2010-09-09 03:37 PDT, Vincent Agriesti wrote: How do I get the CMS encoder in mozilla's NSS 3.12.7 to use definite encodings on constructed types as well as data [?] [snip] Researching into the code, I've found (in secasn1e.c) /* The !isString test below is apparently intended to ensure that all ** constructed types receive indefinite length encoding. [snip] which leads me to believe there is no way to do this easily. If know one knows of an easy way to handle this, I'll probably submit bug/patch, just thought this was suppose to be a std feature of CMS encoders? Thanks for any help! Vinnie Agriesti NSS has two encoders and two decoders for PKCS7. The older one, whose functions use the SEC_PKCS7_ prefix, implements an older version of the standard, but IINM, allows for either DER or BER encoding. The newer one, which uses the NSS_CMS prefixes, was designed exclusively for use in an SMIME email package, where it was believed that BER encoding was always allowed. If the new encoder can be made to do DER encoding without a huge restructuring, we'd appreciate a patch to enable that. But if not, you may want to switch to the other encoder. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)
On 2010-09-07 06:20 PDT, Konstantin Andreev wrote: On 08/31/10 05:01, Nelson B Bolyard wrote: On 2010/08/30 17:32 PDT, Wan-Teh Chang wrote: I propose that we remove SSL 2.0 support from the NSS trunk (NSS 3.13). [... skip ...] It's something I wanted to do for YEARS, but for as long as I was employed to work on NSS, I was told that continued support for SSL2 was an ongoing business requirement. I am sad that the opportunity to make those simplifications did not come along until it was too late for me. Hello, Nelson. Do I understand right, - the current product (NSS) owner (Mozilla Foundation ?) has no certain opinion regarding SSLv2 support ? For years, NSS has been a collaboratively owned project, without any one collaborator being viewed at the exclusive, or even primary, owner. Today, the companies that continue to make significant contribution to NSS, either with development staff, or with IT support (servers of various kinds), or both, include Google, Red Hat, Oracle (formerly Sun), and Mozilla. The people whom I regard as the present NSS module owners are Bob and Wan-Teh, from Red Hat and Google, respectively. Regarding the companies who have sponsored the project in various ways: - Apparently Google (as represented by Wan-Teh) favors removing SSL2 support. - I do not know what position Red Hat has on this. (Bob?) - I believe Mozilla would not object at all, since they have disabled SSL2 support in their clients, but they provide only IT support. - When I worked at Sun (now Oracle), they believed they had ongoing obligations to support SSL2 for some of their customers. I imagine they will attempt to support those customers with a LNG lived NSS 3.12 branch, and hence may not object to removing SSL2 from 3.13. But that's pure speculation on my part. (I hope Oracle's remaining NSS developer will speak to this here.) -- /Nelson Bolyard(speaking only for myself) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: signature verification. VFY_CreateContextWithAlgorithmID help
On 2010-09-06 08:17 PDT, Xavier Toth wrote: I'm trying to verify the signature of a file I've signed but I don't understand where to get the sigAlgorithm and hash to pass to VFY_CreateContextWithAlgorithmID. I presume you've read the description of these parameters in http://mxr.mozilla.org/security/source/security/nss/lib/cryptohi/cryptohi.h#227 In particular, note that the description tells us that the hash argument is optional (meaning that you can pass NULL as the argument value for this parameter) and that when present, it is the address into which the function returns (outputs) the type of hash that it found within the signature itself. Not all types of signatures embed that information, and for them, the hash info must be input, using one of the other variants of this function. I've googled looking for some sample code using the VFY_ apis to verify signatures but I haven't found anything that I could build off of. http://mxr.mozilla.org/security/search?string=VFY_CreateContext reveals that there are 3 variants of VFY_CreateContext, including VFY_CreateContextDirect and VFY_CreateContextWithAlgorithmID. It also reveals that, within the Mozilla code that uses NSS, there are NO callers of VFY_CreateContextDirect, and only one caller of VFY_CreateContextWithAlgorithmID. All the rest use the original VFY_CreateContext function. Still, I think that one example ought to suffice. Shouldn't I be able to get these from the public key and/or signature itself? Some public keys support multiple types of signature algorithms. You must tell the VFY function which of the signature algorithms to use. Many (most?) of the standard signature formats record that information explicitly in the form of an OID, but some do not. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using a 'secret' SSL client certificate from Mozilla
On 2010-08-30 11:04 PDT, Michael Smith wrote: On Aug 28, 10:08 am, Nelson Bolyard nonelsons...@nobolyardspam.me wrote: What is the real underlying objective of this? Is it to authenticate the individual user of the product to the servers? Is it to ensure that the client applications of the network service are genuinely those made by your partner, and not some other client that has been made by some third party who reverse engineered your protocol? (e.g. as AOL used to try to ensure that only genuine AOL clients accessed the AOL Instant Messenger servers?) Yes, the intent is to ensure that the client application is a legitimate application, and to prevent others (even if the _user_ is appropriately authenticated with username/password) from accessing the servers. [snip] Any advice you can give would be greatly appreciated! The attack against which you're trying to guard is that someone reverse engineers your protocols and creates a substitute client that talks to your servers. Presumably, someone does that by reverse engineering your client. Anyone who can do that can find the private key and the client certificate, which will be embedded in your client binary somewhere, and aren't very big, and use them in their substitute client, also. So, embedding a key and cert in your binary really doesn't offer much protection, IMO. In some sense, the problem is that the info that the attacker must replicate is too small and too easily replicated, if it is merely a key and cert, or for that matter, if it is merely the static content of an executable program file. I know of a company (:-) whose products had a protocol whereby the server asked the client give me the contents of your memory starting at this address for this many bytes, which was an address in the code portion of the program, as a means of authenticating the client program. The idea was that this made the entire program file the data that must be kept, no tiny subset of it was enough to fool the server. The attackers simply shipped a copy of the original program along with their replacement, and their replacement program answered those requests by reading the original program file to find the answers. If you assume that the attacker has full access to every bit of data that the server shares with the client, then trying to distinguish between a legitimate client and a replacement becomes a game of testing the limits to which the attacker is willing to go to emulate the original. But you can go quite far in that direction, producing results that require quite a bit of emulation to replicate. It requires demanding results that depend on quite a bit of dynamic data, and not merely depending on static data that can be gotten from the original program file. And it can all be overcome with enough reverse engineering. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)
On 2010/08/30 17:32 PDT, Wan-Teh Chang wrote: On Mon, Aug 30, 2010 at 8:12 AM, Brian Smith br...@briansmith.org wrote: Wan-Teh Chang wrote: I propose that we remove SSL 2.0 support from the NSS trunk (NSS 3.13). The entire gather logic, by which incoming records are received, could be simplified enormously, and made much more efficient, once SSL 2.0 support is removed. The existing gather logic seems to have been written by someone who feared that he might ever read a byte out of a socket that he could not immediately use, and that he would then need to buffer for some time, as if that was some sort of onerous burden. This led to code that does lots and lots of tiny little reads into a buffer. I would rewrite it to allocate a buffer large enough to hold a maximum posisble size SSL3.x record, and then would always attempt to read in enough data to fill that buffer in a single read. It's something I wanted to do for YEARS, but for as long as I was employed to work on NSS, I was told that continued support for SSL2 was an ongoing business requirement. I am sad that the opportunity to make those simplifications did not come along until it was too late for me. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: how to send encrypted mail to email list address ?
On 2010/08/26 01:02 PDT, fishjohn wrote: Hi. Hope this forum is ok for such question. Yes. We have simple lists implemented through /etc/aliases . basically I want to send encrypted mail to l...@example.com ( which is alias for person1, person2, ...) A common desire. Is there way to go with ldap addressbook , so that outlook/ I can't answer any questions about outlook. I don't use it. thunderbird would read recepients for l...@example.com and therefore use every persons key to encrypt message? I'm not aware of one. If there is, the answer to that question would come from the Thunderbird experts, who don't participate in this crypto list. Thunderbird will let you (and each person create a mailing list in your address book. If you send an email to a list in your address book, then it will actually send the message to all the email addresses in that list, all of which are actually in your address book. This works quite well with SMIME. Of course, every user has his own copy of the list that way, and it becomes difficult to centrally administer the list. Another alternative is to send the email to all the recipients explicitly, and have everyone use reply-all. But that also has its limitations. Other solution would be to purchase cert for l...@example.com and have every person installed this cert in their thunderbird/outlook. I have already tested that solution and for some reason one person can read mail sent by other. I assume you mean ... can NOT read mail Did you have all the persons who will share that certificate also install the private key that goes with it? Thanks for help/direction. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Why does Softoken refuse to create keys with C_CreateObject in FIPS mode?
On 2010-08-22 20:46 PDT, Nelson B Bolyard wrote: On 2010-08-22 16:44 PDT, Brian Smith wrote: When NSS Softoken is in FIPS mode, it refuses to create keys with C_CreateObject. What means that it refuses to import secret or private key material Sorry, that should have read: Which means that ... that is being kept in the clear outside of the security module boundary into the security module, and treat it as if it had always been securely kept inside that boundary. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Assertion when using SEC_ASN1EncodeItem with subtemplate
On 2010-07-30 20:53 PDT, Wan-Teh Chang wrote:
On Fri, Jul 30, 2010 at 11:29 AM, Nelson B Bolyard nel...@bolyard.me wrote:
I think you're right. I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=583308
with a patch to fix at least one problem.
I ran Hanno's test program in a debugger.
Why didn't I think of that? :-/
I saw the problem that Hanno reported, that the ASN.1 encoder calls
SEC_ASN1GetSubTemplate one time too many.
The first SEC_ASN1GetSubTemplate call is caused by the SEC_ASN1_OPTIONAL
flag.
The second SEC_ASN1GetSubTemplate call, which causes the assertion
failure, is caused by the SEC_ASN1_EXPLICIT flag.
Using this MXR query for SEC_ASN1_POINTER, you can see that no ASN.1
templates use SEC_ASN1_POINTER with SEC_ASN1_EXPLICIT:
http://mxr.mozilla.org/security/search?string=SEC_ASN1_POINTER
So it's not surprising the ASN.1 encoder may have problems with the
SEC_ASN1_POINTER | SEC_ASN1_EXPLICIT combination.
So one solution is to not use a pointer field in the structure. But I
understand you want the field to be a pointer because it is optional.
Then I found that NSS deals with such an optional field with an explicit
tag by using a PointerTo template.
So THAT'S WHY NSS has those PointerTo templates.
Thank you, Wan-Teh, for solving an old old mystery!
So, I conclude from this that we should make one of two changes, either:
a) change both the ASN.1 encoders and decoders to ASSERT that no template
contains both OPTIONAL and EXPLICIT, or else
b) change the ASN.1 encoder to make that combination work (it already works
in the decoder, I believe).
I will update bug 583308 with this info.
Here is an example in mozilla/security/nss/lib/certhigh/ocsp.c:
http://mxr.mozilla.org/security/source/security/nss/lib/certhigh/ocsp.c#1188
Here is Hanno's code modified to use a PointerTo template:
SEC_ASN1_MKSUB(SECOID_AlgorithmIDTemplate)
const SEC_ASN1Template MY_PointerToAlgorithmIDTemplate[] = {
{ SEC_ASN1_POINTER, 0, SEC_ASN1_SUB(SECOID_AlgorithmIDTemplate) }
};
const SEC_ASN1Template MY_RSAPSSParamsTemplate[] =
{
{ SEC_ASN1_SEQUENCE, 0, NULL, sizeof(SECKEYRSAPSSParams) },
{ SEC_ASN1_OPTIONAL | SEC_ASN1_CONSTRUCTED | SEC_ASN1_EXPLICIT |
SEC_ASN1_XTRN | SEC_ASN1_CONTEXT_SPECIFIC | 0,
offsetof(SECKEYRSAPSSParams, hashAlg),
MY_PointerToAlgorithmIDTemplate },
{ 0 }
};
SECStatus
PSSU_EncodeDER(SECItem *dest, CK_RSA_PKCS_PSS_PARAMS *in)
{
SECKEYRSAPSSParams *pss_params;
PRArenaPool *arena;
SECItem *ret;
unsigned int i;
arena = PORT_NewArena(DER_DEFAULT_CHUNKSIZE);
pss_params = PORT_ZAlloc(sizeof(*pss_params));
pss_params-hashAlg = PORT_ZAlloc(sizeof(SECAlgorithmID));
SECOID_SetAlgorithmID(arena, pss_params-hashAlg, SEC_OID_SHA256, NULL);
ret = SEC_ASN1EncodeItem(arena, NULL, pss_params,MY_RSAPSSParamsTemplate);
PORT_FreeArena(arena, PR_FALSE);
return SECSuccess;
}
Wan-Teh
--
/Nelson Bolyard bnbsp;/b
12345678901234567890123456789012345678901234567890123456789012345678901234567890
0112233445566778
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Assertion when using SEC_ASN1EncodeItem with subtemplate
On 2010-07-30 20:53 PDT, Wan-Teh Chang wrote:
Here is Hanno's code modified to use a PointerTo template:
SEC_ASN1_MKSUB(SECOID_AlgorithmIDTemplate)
const SEC_ASN1Template MY_PointerToAlgorithmIDTemplate[] = {
{ SEC_ASN1_POINTER, 0, SEC_ASN1_SUB(SECOID_AlgorithmIDTemplate) }
};
const SEC_ASN1Template MY_RSAPSSParamsTemplate[] =
{
{ SEC_ASN1_SEQUENCE, 0, NULL, sizeof(SECKEYRSAPSSParams) },
{ SEC_ASN1_OPTIONAL | SEC_ASN1_CONSTRUCTED | SEC_ASN1_EXPLICIT |
SEC_ASN1_XTRN | SEC_ASN1_CONTEXT_SPECIFIC | 0,
offsetof(SECKEYRSAPSSParams, hashAlg),
MY_PointerToAlgorithmIDTemplate },
{ 0 }
};
This doesn't work (crashes) on windows. It probably does on Unix.
The XTRN flag is wrong there. On WIndows, it tells the en/decoder that
the template pointer is actually a pointer to a chooser function,
but the chooser function got moved up to the PointerTo template.
So, I moved the XTRN flag up to the PointerTo template, and that
didn't crash, but it failed. I'm debugging it now.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Assertion when using SEC_ASN1EncodeItem with subtemplate
On 2010-07-31 14:23 PDT, Nelson B Bolyard wrote: So, I moved the XTRN flag up to the PointerTo template, and that didn't crash, but it failed. I'm debugging it now. My mistake. It succeeded. I interpreted the returned pointer to the output buffer as a non-zero result code indicating failure. I will attach the corrected test program with the final corrected template to bug 583308. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Assertion when using SEC_ASN1EncodeItem with subtemplate
On 2010-07-29 15:14 PDT, Hanno Böck wrote: After digging down deeper into the code, it seems it fails somewhere here: http://mxr.mozilla.org/security/source/security/nss/lib/util/secasn1e.c#897 It gives state-theTemplate to the SEC_ASN1GetSubTemplate-function, while state-theTemplate points to SECOID_AlgorithmIDTemplate, which is already the subtemplate. I fail to really understand the asn1 decoding code at the moment, but I find it likely it's a bug in there. I think you're right. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=583308 with a patch to fix at least one problem. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Assertion when using SEC_ASN1EncodeItem with subtemplate
On 2010-07-26 06:07 PDT, Hanno Böck wrote:
Hi,
Just recently, the templates for decoding the RSA-PSS ASN1 parameters got
added to cvs head (in cryptohi/seckey.c).
Currently I'm working on implementing the creation of PSS signatures, so I
need them also to encode. My naive thought was that SEC_ASN1EncodeItem is
used
pretty much the same as QuickDERDecodeItem, just the other way round.
For testing, I tested with a stripped-down version of the template containing
only the first entry. Though what I get is:
Assertion failure: theTemplate-sub != NULL, at secasn1u.c:93
From the error, I assume it has something to do with the subtemplate. If that
helps, by some try and error I found out that when removing
SEC_ASN1_EXPLICIT,
no assertion appears (thouhg it'll obviously produce a wrong DER struct).
Is there something special I need to care about when doing encoding vs.
decoding ASN1?
The code looks like this:
SEC_ASN1_MKSUB(SECOID_AlgorithmIDTemplate)
const SEC_ASN1Template MY_RSAPSSParamsTemplate[] =
{
{ SEC_ASN1_SEQUENCE, 0, NULL, sizeof(SECKEYRSAPSSParams) },
{ SEC_ASN1_OPTIONAL | SEC_ASN1_CONSTRUCTED | SEC_ASN1_EXPLICIT |
SEC_ASN1_XTRN | SEC_ASN1_POINTER | SEC_ASN1_CONTEXT_SPECIFIC | 0,
offsetof(SECKEYRSAPSSParams, hashAlg),
SEC_ASN1_SUB(SECOID_AlgorithmIDTemplate) },
{ 0 }
};
SECStatus
PSSU_EncodeDER(SECItem *dest, CK_RSA_PKCS_PSS_PARAMS *in)
{
SECKEYRSAPSSParams *pss_params;
PRArenaPool *arena;
SECItem *ret;
unsigned int i;
arena = PORT_NewArena(DER_DEFAULT_CHUNKSIZE);
pss_params = PORT_ZAlloc(sizeof(pss_params));
That should be
pss_params = PORT_ZAlloc(sizeof(*pss_params));
or, even better
pss_params = PORT_ArenaZAlloc(arena, sizeof(*pss_params));
or, perhaps even better still
pss_params = PORT_ArenaZNew(arena, SECKEYRSAPSSParams);
pss_params-hashAlg = PORT_ZAlloc(sizeof(SECAlgorithmID));
SECOID_SetAlgorithmID(arena, pss_params-hashAlg, SEC_OID_SHA256, NULL);
ret = SEC_ASN1EncodeItem(arena, NULL, pss_params,
MY_RSAPSSParamsTemplate);
PORT_FreeArena(arena, PR_FALSE);
return SECSuccess;
}
--
/Nelson Bolyard
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Fwd: Hi, I have three questions about embed bank CA cert in Firefox
On 2010-07-21 18:26 PDT, Amax Guan wrote: Thank you very much, this really help alot:) We won't let end-users use that tool, instead, we put it in a installer, and let the installer do the dirty work. btw, Since this certutil.exe is downloaded from microsoft.com I'm a little worried about whether this certutil.exe is the same certutil.exe in NSS? Microsoft's certutil is definitely NOT the same as NSS's. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Netscape Enterprise Server 3.63 2048 bit ssl cert
On 2010-07-23 13:48 PDT, Robert Relyea wrote: You may be stuck. I believe NES 3.63 ran using an older version of NSS that is available in the open source world (or even available as shared ^ NOT! libraries, for that matter). I'm not sure if anyone has access to that old source library. Bob, I think you left an important word out of the above sentence. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: JSS in Firefox - loading applets over mutual SSL stopped working since the v. 3.6.x
On 2010-07-20 02:21 PDT, Waldek wrote: Hi again, is there anybody who's been able to get such a setup working after upgrading to FF 3.6.x ?? Is it a FF 3.6.x bug ?? Could someone from Mozilla guys state anything in this case ?? I've no other ideas so far but recommending my customers switching to IE, which is not my favorite. Please help. Sadly, there are no longer any developers who are paid to support JSS, and the one developer who was supporting JSS on his own time no longer seems to have time to do so. Perhaps other JSS users here can help you. You probably need a newer build of JSS than the one you're using. But having said that, I cannot tell you where or how to get one. Alas. Sorry. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Fwd: Hi, I have three questions about embed bank CA cert in Firefox
On 2010-07-21 10:50 PDT, Ryan Sleevi wrote, quoting Gervase Markham: On 21/07/10 07:26, Amax Guan wrote: But if you generate a user Certificate that's issued by a untrusted CA, there will be an alert popup. Can some NSS or PSM hacker explain why this is? Gerv While neither an NSS nor PSM hacker, Considering the excellent job you did with the research below, I do hereby pronounce you to be an official PSM hacker! the implementation details (in moz-central) are at [1] If any certs beyond the user cert are supplied, then ImportValidCACerts() is called. The certificates are all imported as temporary certificates, then each certificate is tested to see if a chain can be built [2]. The simple way to work around this would be to only supply the user's certificate in the application/x-x509-user-cert (since the user's cert is not placed through this verification logic) OR, first supply (and have the user install) the CA certificate of the issuing authority using the previously recommended application/x-x509-ca-cert. Exactly the advice I was going to give. This is as intended. The user's own cert may be imported without any restriction. It is not required to chain to any known authority. But authority certs, in general, and certs for other than the user's own, are required to chain to known authorities, lest they be used for attacks. The Chinese Bank should be able to merely download just the user's cert to the browser, and then when requesting client auth, request it using the name of the issuer of the client's cert. The browser will then send just the client's cert, which the bank will be able to validate by supplying the rest of the chain itself. This is all S.O.P. As for a good answer why, I can only speculate, but I suspect some code paths would be affected by blindly importing certificates without first vetting their chain. eg, a malicious party could supply a certificate that appeared to be the same as a valid intermediate CA certificate (except that the signature was wrong, naturally). If that certificate ended up being selected during chain building/locating by subject/etc (pre-libpkix/STAN), then it would cause connections using that intermediate to fail (a DoS). Actually, a little CVS blame digging, and it turns out this is the case. See [3] [1] http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSS CertificateDB.cpp#885 [2] http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSS CertificateDB.cpp#772 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=249004 -- /Nelson Bolyard bnbsp;/b 12345678901234567890123456789012345678901234567890123456789012345678901234567890 0112233445566778 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Passing random numbers between tokens - what FIPS thinks ?
I wrote: FIPS 140 will not allow *any* hardware pure noise source to be used by itself as a random number/bit source. Instead, such a source MUST be fed into a DRBG from which any internal random data is taken. To clarify, by pure noise source, I meant such as a forward biased silicon PN junction amplified, or a continuous current measurement through a lava lamp (:-), or an RF tuner tuned to some frequency not occupied by any known transmitter. All these things produce random noise, but their output cannot be used directly. Instead it may be used as input to a PRNG. This is sometimes (not always) called a seed, or additional input to the PRNG. You can feed any noise from any source you want into a FIPS 140 token as additional input into its PRNG. PKCS#11 has a function with the word seed in the name, which is actually additional input as that term is defined in NIST SP 800-90. Nothing at all prevents you from feeding RNG output from one token into that function for another PKCS#11 token. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Passing random numbers between tokens - what FIPS thinks ?
On 2010-07-19 03:18 PDT, Konstantin Andreev wrote: Let assume, I have high-quality, conformant to all relevant standards (e.g. FIPS 140-1), hardware, true random numbers source - token B. Token vendor intimately cares about standard API to the token, and provides PKCS#11 library. Indeed, there are very good commercial true RNG, and the only API to them we can rely is PKCS#11. Right. You can use their output as additional input to the internal PRNG in another token. It is obvious, that hardware RNG is more secure than softoken's builtin one. Is it achievable to make softoken use hardware RNG all the time, being or not being FIPS-compatible ? You would have to modify softoken in a way that would make it no longer FIPS compliant. Simpler would be to frequently take random output from one and feed it as additional input to the other through the PKCS#11 function C_SeedRandom. Maybe chaining two FIPS-compliant devices will result in FIPS-compliant aggregate device ? Application --(sign_req)-- Mozilla softoken --(C_GenerateRandom)-- hardware RNG If softoken were to use an external hardware RNG as its ONLY RNG (as opposed to considering it as a source of additional input to softoken's own RNG), then the only way that softoken could claim FIPS compliance would be if softoken was FIPS certified together with that hardware RNG. That hardware RNG would be considered inside of the softoken's perimeter. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: JSS/NSS library dependencies on Windows XP
On 2010-07-19 10:56 PDT, Caden.smith Smith wrote: Just for your information, here is the tree: JSS4.DLL NSPR4.DLL ADVAPI32.DLL The factors under the control of the way in which JSS and NSPR are built end here. Anything below this point has NOTHING to do with them. Everything below this point is interdependecies of system libraries. If you have a system library, 9 levels down, whose presence is TOTALLY UNKNOWN to JSS and NSPR, and it depends on a missing DLL, that is no fault of JSS or NSPR, or of the way they were built. SECUR32.DLL NETAPI32.DLL DNSAPI.DLL MPRAPI.DLL SETUPAPI.DLL SHELL32.DLL SHDOCVW.DLL MSHTML.DLL IEFRAME.DLL that finally requires IESHIMS.DLL and WER.DLL My guess is that you've installed some package on your XP system that was intended for a Vista system, and it installed some Vista DLLs on your XP system (e.g. it installed a vista IEFRAME.DLL). That DLL now wants another vista DLL that is not on your system. But this has nothing to do with JSS or NSPR. I'll add that we've seen this dependency walker tool lead developers on some wild goose chases before, telling them about dependencies that didn't exist (were not, in fact, real dependencies). The one windows tool that I believe for dependency information is the program dumpbin. Run it as dumpbin /dependents some.dll and it will tell you the other DLLs upon which that named DLL depends. It will give you the entire list. Anything not on that list is not a direct dependency of that named DLL. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to refresh Firefox keystore
On 2010-07-01 18:10 PDT, james07 wrote: I'm importing the key pair into the browser's soft token. I can see that the cert8.db and key3.db files in the profile directory are updated and I can also see the new certificate using certutil.exe -L. However when attempting to connect to a website that requires client SSL authentication in the same browser session (immediately following the import of the keypair), the browser does not seem to detect the new certificate. It is only after restarting Firefox that I can establish the mutual SSL session (and the imported certificate appears in Certificate Manager Your Certificates) Is it possible to refresh the PSM cache while the browser is running? I suspect that there may be another explanation for this behavior. It *may* (or may not) be that FF is establishing a TLS session with the server that is not client authenticated, and thereafter the server is merely content to use that same session over and over, and it never attempts to force the client to renegotiate a new SSL/TLS session. A tool like ssltap would tell you if that is the explanation. There's another way to tell as a diagnostic step. There is a way to get the browser to completely flush its TLS/SSL session cache. If you would establish the TLS session without a client cert, then import your client cert, and then flush all your TLS sessions, that would force the next TLS connection to start a new TLS session. You could do that test, manually flushing your TLS session cache. If that caused the client cert to be used in a client authentication, then you would know that the server is not continuing to demand client auth after the first time it negotiates a TLS session with only server auth. In the event that this test positively shows that continued reuse of old TLS sessions that were established without client authentication explains the behavior you see, I do NOT mean to suggest that additional flushing of the client's TLS session cache is the solution. It is only a diagnostic step. If we know the cause of the problem, then we can discuss the NUMEROUS different possible solutions. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: 6 year old bug forcing my office to outlook
On 2010-06-22 06:24 PDT, Logan Jones wrote: Whenever someone receives an email with a .p7m extension as an attachment, Thunderbird eats it. I suppose you mean /attachment/ rather than /extension/. Normally it would be saved to the desktop and decrypted with the standalone entrust application, but we can't even get that far. I would say that normally Thunderbird would just process the p7m itself. It's quite capable of doing so. It does so for me many times every day. It handles p7m's generated by many other email clients, including outlook, Entourage (Outlook for Mac), and others. So the question on my mind is: what's different about these messages you're getting that causes them not to be recognized and handled in the normal fashion? My guess is that it's a problem with MIME headers such as Content-Type, or disposition. The only way to be sure is to look at the actual source of a message. Maybe you can make an example message that contains no sensitive content for that purpose. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: C_EncryptUpdate( inlen != N * blksize ) for CBC, ECB cipher modes.
On 2010-06-22 07:06 PDT, Konstantin Andreev wrote: At the moment, NSS softoken still return CKR_DATA_LEN_RANGE when CBC/ECB ciphers are updated with odd length. I wonder, are any chances for this aspect of NSS softoken to be more PKCS#11 compliant in the near future ? Yes. Step 1. File a bug in b.m.o. Step 2. Develop a patch... -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PK11_CipherOp with RC4 and invalid memory access
On 2010-06-21 17:57 PDT, Brian Smith wrote: From arcfour.c: http://mxr.mozilla.org/mozilla/source/security/nss/lib/freebl/arcfour.c#390 My guess is that valgrind is considering malloc(5) to allocate 5 bytes, when really it allocates 8 bytes at least (because of alignment). See the explanation given in https://bugzilla.mozilla.org/show_bug.cgi?id=451754#c4 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using NSS to export PKCS#12 pfx files
On 2010-06-15 14:17 PDT, John Scott wrote: I'm doing the following to create a signed Firefox plugin http://oyoy.eu/huh/firefox-extension-code-signed-with-spc-pvk/ However, I'm trying to automate the process, and the first step would be removing the need for pvkimprt. .NET code can export a PKCS#12 key with the private key from a PKCS#7 key, but it doesn't have the full chain of CAs, so is invalid for signing the plugin. What are you trying to automate? Are you trying to make it so that YOU can sign multiple plugins, or multiple versions of a plugin under development, easily (say with a batch file)? Are you trying to make it so that ANYONE can sign a plugin easily? Is there any reason the PKCS#12 file needs to be created more than once per user? Must the creation of the PKCS#12 file be automated? Microsoft's own certificate manager is quite capable of generating a PKCS#12 file with the whole cert chain and the requisite friendly name. It's a fairly nice GUI program, so I wouldn't try to automate its use, which is why I ask if the automation needs to include that step. Would using the NSS API be a practical approach? to do what? to create a PKCS#12 file from the certs and keys in MS proprietary format? It seems that Firefox can export keys and it uses NSS to do that? Yes. Have there been any attempts to do something like this in the past? Not sure what like this is yet. Once you've gotten the necessary keys and certs imported into an NSS DB pair, the rest of the signing process is easily automated because there's a command line program to do it. Seems like the challenge you're facing is to get the private key (which I gather is in a proprietary MS .pvk file) into some usable form. NSS doesn't handle pvk files. MS itself deprecated them over a decade ago. I'm not sure why they're still in use. Maybe there's some other tool on the internet that can create a PKCS12 file from a pvk file and some certs. Or maybe you can/should import the pvk file into your Windows system's key store, and then use Windows cert mgr to create a pkcs12 file. Good luck. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Question for CA representatives about PKCS#10 CSRs you accept
I have a question for CAs that accept PKCS#10 CSRs. Background: PKCS#10 certificate requests may contain an optional set of ATTRIBUTEs. One type of ATTRIBUTE, the only type mentioned in PKCS#10, is the PKCS#9 certificate Extension Request. But PKCS#10 suggests that other types could be defined, such as challenge-response attributes (presumably for some sort of challenge response protocol for authenticating the requester to the issuer). I'm not aware of any other ATTRIBUTE types that have ever been defined and published in RFCs for inclusion in CSRs. The questions for CA representatives are: What are all the types of ATTRIBUTES that you accept in PKCS#10 CSRs? and For any attribute type other than PKCS#9 certificate extension requests, where (in what standard or other document) is that attribute defined? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How pkcs#11 modules read the CONFIG_STRING from modutil -string command
On 2010-06-17 13:45 PDT, Klaus Heinrich Kiwi wrote: If I'm coding a PKCS#11 module, how exactly the -string parameter from modutil gets passed down to the library? i.e., $ modutil -add mylib -libfile /lib/mylib.so -string my conf string I though C_Initialize, OpenSession or even InitToken at first, but looking at the spec I couldn't immediately identify where I could pass arbitrary data to configure the token. See the explanation at http://mxr.mozilla.org/security/source/security/nss/lib/util/pkcs11t.h#1208 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
System NSS DB Directory selection challenges
In https://bugzilla.mozilla.org/show_bug.cgi?id=490238#c37 David Woodhouse asks how well-behaved applications, which may or may not be running on a system with System NSS, are supposed to determine the value of the directory name string they pass to NSS_Init. He observes that the value may differ based on such details as: - the presence or absence of the file pkcs11.txt in the NSS_SYSTEM_DB directory - the presence or absence of a line in that file that names the libnsssysinit.so library among those to be loaded. (As an aside, I'd guess that the relative position of that line is relevant, too, and of course that name is likely to change from Linux distro to distro.) - the presence or absence of a HOME environment variable He provides his own suggested sample code for handling all that, and he opines that NSS should relieve the application of needing to do all that. I don't have much (if any) operational experience with System NSS and libnsssysinit.so, so it may be that there is something being overlooked here that obviates this issue. But if not, then I'm inclined to agree with David Woodhouse that NSS should not effectively require every well-behaved application to do all that work itself. Bob, What say you? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: (nss-3.12.6) unable to engage FIPS mode: security library: invalid arguments.
On 2010/06/13 01:33 PDT, Robin H. Johnson wrote: LOOK at the links I provided, there are ZERO changes to the actual source code. Robin, The point is that the upstream NSS team simply doesn't have time or resources to look at every downstream distribution. There's no point in asking us to do so. We just cannot. But in this case, there was not need for us to do so,, thankfully. My email message attempted to cover a wide variety of possibilities without getting into any specifics of any distribution. It is quite common for distros to omit the .chk files altogether, or fail to update them when the NSS shared libs are updated or modified in any way. So I mentioned it as a general case, and you benefited. The root of the problem is that the shared libraries can change POST-install, as needed for ELF signing, split-debug and prelinking. The ELF signing is a catch-22. Either I have to run shlibsign afterwards, or I have to not sign those files, and leave them open to potential compromise. Rerun shlibsign. It's fast and easy. Running shlibsign does remedy the problem. However, this entire matter could be remedied if some more useful error had been returned instead of 'Invalid Arguments'. Something to indicate that the library checksums no longer matched. It's open source. Patches are invited. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: (nss-3.12.6) unable to engage FIPS mode: security library: invalid arguments.
On 2010-06-13 13:02 PDT, Robin H. Johnson wrote: On Sun, Jun 13, 2010 at 02:02:39AM -0700, Nelson B Bolyard wrote: The root of the problem is that the shared libraries can change POST-install, as needed for ELF signing, split-debug and prelinking. The ELF signing is a catch-22. Either I have to run shlibsign afterwards, or I have to not sign those files, and leave them open to potential compromise. Rerun shlibsign. It's fast and easy. As an intermediate related question, is there a standalone verification tool for the CHK files shlibsign -V -i seems to just sign again, not verify. Yes. modutil is that test tool. You already know how to use it. Just drop the -force argument. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: (nss-3.12.6) unable to engage FIPS mode: security library: invalid arguments.
On 2010-06-13 17:24 PDT, Robin H. Johnson wrote: On Sun, Jun 13, 2010 at 03:08:07PM -0700, Nelson B Bolyard wrote: On 2010-06-13 13:02 PDT, Robin H. Johnson wrote: As an intermediate related question, is there a standalone verification tool for the CHK files shlibsign -V -i seems to just sign again, not verify. Yes. modutil is that test tool. You already know how to use it. Just drop the -force argument. I should have clarified, that I want to verify without any disk writes, nor assuming a pre-setup database. The without any disk writes part is easy. But without a setup database, it's not easy. # modutil -chkfips true modutil: function failed: security library: bad database. Just exactly that the chk files are valid, and nothing else. No. If you wanted to add an option to shlibsign for that purpose, I believe we'd consider it. Perhaps the easiest thing to do is rerun shlibsign and compare the old and new files. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: (nss-3.12.6) unable to engage FIPS mode: security library: invalid arguments.
On 2010-06-13 17:56 PDT, I wrote: Perhaps the easiest thing to do is rerun shlibsign and compare the old and new files. Please forget that I wrote that. That won't work. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME interop issue with Outlook 2010 beta
On 2010-06-12 00:50 PDT, Kaspar Brand wrote: Sigh. I just came across this: http://support.microsoft.com/kb/2142236 Non-Outlook email clients unable to decrypt email sent from Outlook 2010 which states under Cause: Outlook 2010 now more fully implements the Cryptographic Message Syntax (CMS) as documented in RFC3852. Outlook 2010 now uses subjectKeyIdentifier as the SignerIdentifier, whereas earlier versions used issuerAndSerialNumber. It seems that some clients may not yet support using subjectKeyIdentifier as the SignerIdentifier, as defined per the RFC. This results in it being unable to decrypt the message. That's a quote directly from http://social.technet.microsoft.com/Forums/en-US/officeappcompat/thread/3a19bbc7-9c6b-40ec-823d-16fd88e8de38 or vice versa. The statement about the SignerIdentifier is definitely incorrect. It seems that Microsoft does not yet fully understand the issue - does anyone here have straight contact to the Outlook dev team, or know people who have? I'd be happy to help (i.e., explain the problem with all the gory details), but would prefer to speak to someone who is also able to fix the code, afterwards. I followed up on this with several posts in the forum page cited above. The moderator of that forum expressed interest in personally following up on the issue, but required that someone open a Microsoft support case which costs USD $99 (minimum) unless one subscribes to their support service. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: (nss-3.12.6) unable to engage FIPS mode: security library: invalid arguments.
On 2010-06-10 22:59 PDT, Robin H. Johnson wrote: On Thu, Jun 10, 2010 at 10:45:03PM +, Robin H. Johnson wrote: Testcase 2: (see attached minimal C code, based on posts to the list and used in the modutils source AND Mozilla). Bah, forgot the actual file. The testcase has been run on Arch and Fedora now, and both of those cases it works fine. Does that mean this problem is resolved? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: (nss-3.12.6) unable to engage FIPS mode: security library: invalid arguments.
On 2010-06-12 12:49 PDT, Robin H. Johnson wrote: On Sat, Jun 12, 2010 at 12:15:07PM -0700, Matt McCutchen wrote: On Jun 12, 2:25 pm, Nelson B Bolyard nel...@bolyard.me wrote: On 2010-06-10 22:59 PDT, Robin H. Johnson wrote: The testcase has been run on Arch and Fedora now, and both of those cases it works fine. Does that mean this problem is resolved? As I read, it is not; it was reported on Gentoo Linux. No, it still exists on Gentoo, and I haven't been able to reproduce it anywhere else. OK, thanks for that clarification. You have a problem with a distribution of NSS that is not identical to the NSS as built from the upstream NSS source repository. Mozilla's NSS team supports NSS as it comes from the builds from the upstream NSS source repository. Mozilla's NSS team does not attempt to keep track of all the changes made to NSS by every downstream Linux distro. If the upstream NSS works, but some downstream distribution does not, then the differences are due to changes outside of the control of Mozilla's NSS team, and primary support for those problems (that are unique to a downstream distribution) must come from the suppliers of that downstream distribution. It is true that virtually every Linux distribution modifies NSS sources significantly and distributes a downstream flavor of NSS that differs from the upstream version in a number of ways. For some distros, the differences are so minor that you can simply download the upstream NSS sources, build them yourself, and use the resultant binaries as a replacement for the binaries that came with the distribution, and it all works fine. For other distros, they've made changes on such a large scale, such as renaming the functions, renaming the shared libraries and splitting up the shared libraries so that they no longer all live in the same directory, that a vanilla build of NSS from upstream sources simply will not work with programs that were built to work with that distro's NSS libraries. If your distro is one of those, then you'll have no choice but to get help from the maintainers of that distro. It may be that, in your case, the problem is as simple as this: the distro did not include the .chk files that are generated during the NSS build process, or it put them in the wrong directory or gave them the wrong file names, so that NSS cannot find them. Or they may have changed the shared libraries, but not regenerated the .chk files. If that is the case, and the distro HAS distributed NSS's shlibsign program, then you may be able to remedy this yourself by generating replacements for the missing (or old) .chk files using shlibsign. Instructions on how to use shlibsign may be found at http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn6.html If you don't have the shlibsign executable in your distro, then you have an incomplete distro, and you need to get a complete distro, either by building it yourself, or getting your distro supplier to supply a complete and functional distro. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird problem with the search for certificates in the S-TRUST trust list service
On 2010-06-10 07:49 PDT, Jean-Marc Desperrier wrote: Nelson B Bolyard wrote: Fame and Glory await.:-) Which means a mention in http://www.mozilla.org/credits/ or about:credits : We would like to thank our contributors, whose efforts make this software what it is. [...] Any such contributors who wish to be added to the list should send mail to cred...@mozilla.org with your name and a sentence (citation) summarizing your contribution Yes, it also means a chance to put your name and email address into any files that you change, and have it be listed among the likes of names like those shown at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/ecl/ecp_aff.crev=1.3mark=23-28#17 In my view, THAT's the fame that counts. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME interop issue with Outlook 2010 beta
On 2010-06-03 21:52 PDT, Kaspar Brand wrote: On 03.06.2010 22:57, PDF3 SecureEmail wrote: I suspect that NSS is not supporting sender key ID yet/properly. If you replace sender key ID by RecipientIdentifier, then that statement is true, yes. (Note, however that the MSFT moderator mixes up SignerIdentifier and RecipientIdentifier in his posts at social.technet.microsoft.com, and also misrepresents facts about Outlook's behavior when it comes to encoding the SignerIdentifier - it always uses the old format for the *Signer*Identifier, Kaspar, would you care to clarify what you mean by old format there? It appears to me that it always uses the KeyID format for the SignerIdentifier. I'd call the KeyID format the new format. Maybe you mean old as in the Outlook 2010 default format used before a registry entry has been added in an attempt to change it. yes? and the registry setting will only have an effect for the encoding of the *Recipient*Identifier.) I think Thunderbird needs this fixed... Yes, this is actually what https://bugzilla.mozilla.org/show_bug.cgi?id=559243 is about. Once that patch lands, NSS (and somewhen in the future also Thunderbird) will be able to successfully decrypt messages which reference the recipient's cert by their key ID, *as long as* the respective cert really has a subjectKeyIdentifier extension. To successfully decrypt, yes. And to successfully identify the signer's cert *as long as* the signer's cert really has a subjectKeyID extension. Otherwise, it will not be able to find the signer's cert, and hence will not store it in the cert store. This may make it difficult (or impossible) to send an encrypted reply to the mail. Kaspar Regards, /Nelson -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Generation of key pair and CSR
On 2010-06-06 20:38 PDT, james07 wrote: I would like to create a plug-in for Firefox that, when invoked, generates a new key in the Firefox key/certificate store. Is it possible to generate a new keypair in using NSS from the plug-in, or do I need to somehow call crypto.generateCRMF() via javascript from the plug-in? Your plugin can call any public NSS API function. It's best if you use PSM functions where they exist because PSM will handle NSS initialization and shutdown for you. But you aren't required to use PSM for every function call. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Permanently store this exception selected by default
On 2010-06-04 19:21 PDT, TEO Tse Chin wrote: I encountered an expired cert for an IMAP (STARTTLS) server from an ISP. While I've followed up with the ISP about the expired cert, there was something about Thunderbird's behavior that caught my attention. In the Add Security Exception dialog box, the checkbox for Permanently store this exception was checked by default. Given users' tendency to click-through security warnings, would it not perhaps be better for that box to be UNchecked by default? No. This was deliberate. Users' tendency to click through without reading the warning/error first is a direct function of the frequency with which the user experiences the error. It's that frequency that is the enemy. The idea is that the way to get users to pay attention to errors is to make them infrequent. Showing the user the SAME error over and over is the worst thing to do in terms of conditioning him to ignore all similar errors. So, we did what we could to minimize the frequency. That way they'll get a warning each time, and more likely to go bug their service provider to keep their certs up to date. Actually, they're more likely to ignore it. Tse Chin -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Permanently store this exception selected by default
On 2010-06-06 11:22 PDT, aerow...@gmail.com wrote: File a bug. No, don't. It would be a duplicate. Find the bug already on file. It's probably already resolved WONTFIX. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: S/MIME interop issue with Outlook 2010 beta
On 2010/06/03 13:57 PDT, PDF3 SecureEmail wrote: According to the link at http://social.technet.microsoft.com/Forums/en-US/officeappcompat/thread/3a19bbc7-9c6b-40ec-823d-16fd88e8de38 Outlook 2010 is OL2010 is using “sender key ID” instead of “issuer name and serial number” – as per an SMIME standard, but can be reverted to an older style using a registry key. I suspect that NSS is not supporting sender key ID yet/properly. I think Thunderbird needs this fixed... I suggest you read the relevant SMIME standards. The current version allows SMIME clients to use either of the two formats. Older versions of the standard only allowed the issuer name and serial number form. The newer versions allow either one to be used. However, the KeyID form identifies a certificate by a KeyID attribute which is an optional extension in the certificate itself. It is appropriate to use this form ONLY when the certificate thus identified actually has that extension present. When that extension is not present, the proper way to identify it is by its issuer name and serial number, since all certificates have that, and only some have the optional keyID. TB can identify certificates by their keyID *WHEN THEY HAVE A KEYID*. But when OL2010 says the desired cert has this KeyID, and in fact the desired cert has NO KeyID at all, TB is correct to say no cert with that KeyID can be identified. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS - signing with MAC
On 2010/06/01 07:04 PDT, Sebastian Mayer wrote: Solved - and this was again a FIPS issue. The AES_MAC is not in the list of support mechanism in the fips-related security policy. That's strange. I'm not sure if that's intentional or a bug. Bob, Glen, Do you know? Is there a reason for this to be excluded from FIPS mode? I should read the policy more carefully ... -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Restricting SSL cert issuance within specified domain
On 2010/06/01 11:38 PDT, Kathleen Wilson wrote: Is there support in NSS to restrict an intermediate CA to only be able to issue SSL certificates within a specified domain? Yes, the issuer of the intermediate CA cert can constrain the names that may appear in certificates issued by that subordinate intermediate CA. If yes, does this support apply to both SANs and CNs? In current releases, it does not apply to CNs, because the standard does not define that constraint as applying to CNs. However, in the next forthcoming release, it will apply to CNs. Whether it's standard or not, the constraint is pretty useless if it does not apply to CNs, so we've changed it. There seems to be agreement among a subset of browser vendors that this is the right thing to do. Can you point me to documentation on how to use this? http://www.rfc-editor.org/rfc/rfc5280.txt Section 4.2.1.10. Name Constraints The reason that I’m asking is because there has been recent discussions in m.d.s.policy about subordinate CAs that chain up to root certificates that are included in NSS. The discussions have prompted a significant update to the following wiki page: https://wiki.mozilla.org/CA:SubordinateCA_checklist My questions above are in regards to the “Third-party private (or enterprise) subordinate CAs” defined in this wiki page. It would be reasonable, IMO, for Mozilla policy to require CAs to constrain the subordinate intermediate CA certificates that they issue. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
