Re: signtool.exe
John Smith wrote: When I execute signtool.exe I got this error: using certificate directory: C:\Documents and Settings\myusername\Application Data\Mozilla\Firefox\Profiles\vsw8mp7m.default That's your firefox profile. You're not running signtool while FireFox is running, right? signtool: function failed: An I/O error occurred during security authorization. security authorization means getting your password. That's what this error code was originally about. Unfortunately, in more recent NSS releases, that error code has become overloaded with another meaning, the failure of a PKCS#11 module to perform any operation. IMO, NSS really needs a new separate error code, something like PKCS#11 module failed, to disambiguate this in the future. Bob, do you concur? I belived my keystore was corrupted, so I deleted key3.db, secmod.db and cert8.db and when I restarted my FF 2.0 it recreated them. Then I reimported my certs (my code signing cert its issuer) and tried signing again. reimported from a pkcs12 file? (or pfx file) ? or from some other kind of file? Only a PKCS12 file (.p12 or .pfx) can restore your private key. Still the same error message. :( What should I do? Does your key3.db file now contain the private key for your cert? Is your cert an object signing cert? Or merely code signing? -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Forcing the SSL handshake
Rob Crittenden wrote: Nelson B wrote: Rob Crittenden wrote: In an SSL client I want to force the SSL handshake to take place instead of passively waiting for it to happen during the first write. Here are a few (?) questions and comments: 1. Is this a blocking socket, or non-blocking? non-blocking, not my choice. 2. If non-blocking, are you certain that the connection has completed? That is, are you certain that the TCP's three phase connect is completely done? This is tricky for non-blocking sockets, and trivial for blocking sockets. I'm not sure it has completed, hence the simplistic loop and my plea for assistance. Despite empirical evidence that it worked in my 3 test cases this code is obviously bogus. 3. Is this the first handshake on the socket after the connect? or Is it a subsequent (e.g. second) handshake on the socket? First connection only. 4. Is this a server speaks first application protocol? or is this a client speaks first protocol? Client speaks first, HTTPS. OK, well, I would not have (and obviously did not) guess that from the code you initially presented. That changes my answer, and makes me glad I asked all those questions. You're trying to do fairly typical non-blocking client behavior, with the added wrinkle that you want to do the handshake before doing the first write, for some reason I can't yet fathom. Since the socket is non-blocking, the client already must know how to handle PR_WOULD_BLOCK_ERROR. As long as the client does that correctly, it shouldn't need to force the handshake before the first write. The initial write attempts will simply return PR_WOULD_BLOCK_ERROR until the handshake is completed. Still, that's all very easy to do. There are 3 steps that need to be done, in order, each step completed before the next one is begun. They are a) initiate and complete the TCP connection b) do the handshake c) write the initial http request Notice that there's no need to do ANY recv calls in there, anywhere. The receive calls are completely unnecessary and actually complicate matters because of the timeouts. Just don't do 'em. NSS's test client program, tstclnt, already does everything you want to do except forcing the handshake before the first write. I'm going to point you to tstclnt and let you follow that example. It will show you how to initiate a non-blocking connection, and wait for it to complete and KNOW when it is completed. Look at lines 751-797 of http://landfill.mozilla.org/mxr-test/security/source/security/nss/cmd/tstclnt/tstclnt.c#751 The only additional piece you need to know is how to force the handshake, AFTER the TCP connection is completely established. I guess at least the loop should be: do ret = PR_Recv (ssl, handshake, 1, PR_MSG_PEEK, 100); err = PR_GetError(); while (ret 0 err == PR_IO_TIMEOUT_ERROR handshake_done == 0); On slow connections I've seen the loop fire as many as 20 times. I can increase the timeout, that is purely a goof. But again, I don't want a noticable pause. On connections to a local machine even with an interval of 1 sometimes the handshake completes in one run through the loop (and who said SSL is slow?) 7. Why are you using such a short timeout on PR_Recv? So it doesn't cause a noticable pause in the connection. There will never be any data to peek at so I am guaranteed to wait a certain number of PRIntervals until PR_Recv returns. A larger value will almost certainly negate the need for the icky loop but even if the handshake is done, it'll hang around waiting for the timeout to end. Now I understand that you're using PR_Recv as a substitute for PR_Poll. Use PR_Poll instead. As far as noticeable pause, you have to wait for the handshake to complete, however long that takes. You don't want to introduce any extra wait time, so don't use PR_Recv. Use PR_Poll. What trick are you trying to do? Force a handshake to complete on a non-blocking socket without doing I/O with PR_Send/Write or PR_Read/Recv (in non-peek). To do that, you need SSL_ForceHandshake and PR_Poll. PR_Recv is actually the problem in this code. Given that you're the client doing the first handshake on a client-speaks- first application protocol, you don't need to worry about receiving any application data from the server before the handshake completes. That simplifies things a lot, AFTER you're sure the connection is completed (that is, fully established), you can simply do a loop, calling SSL_ForceHandshake, and if it returns PR_WOULD_BLOCK_ERROR, then calling PR_Poll on the socket until it is readable again. Repeat this until you get any other error or the handshake is completed, or too much time has elapsed. Don't make timeouts occur. You have to wait until the handshake is done anyway. You should only use timeout to detect that too much total time has elapsed. Set the socket's timeout to the upper bound of that time limit
Re: Forcing the SSL handshake
Kyle Hamilton wrote: On 11/2/06, Rob Crittenden [EMAIL PROTECTED] wrote: It would be a whole lot simpler if I didn't want to force the handshake. Indeed, that is how I initially wrote it, but then I changed my mind and wrenched the code until it worked the way I wanted. The problem being, at a baser level, that there doesn't appear to be a way to send a client_hello message without receiving a server_hello first? I'm sure that's not the problem, since the SSL protocol doesn't allow the server to send the server hello until after it has received the client hello. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Forcing the SSL handshake
Rob Crittenden wrote:
In an SSL client I want to force the SSL handshake to take place instead
of passively waiting for it to happen during the first write.
Right after I connect to the server I'm currently doing this:
SSL_ResetHandshake(ssl, /* asServer */ PR_FALSE);
do {
SSL_ForceHandshake(ssl);
PR_Recv (ssl, handshake, 1, PR_MSG_PEEK, 100);
err = PR_GetError();
} while (err != PR_END_OF_FILE_ERROR handshake_done == 0);
This code may also run into bug 273861.
https://bugzilla.mozilla.org/show_bug.cgi?id=273861
Be sure there's no unread data on the sslsocket before calling ForceHandshake.
--
Nelson B
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: html include syntax for signed scripts
Frank wrote: Hi, I find the whole jar pathing quite unwieldy. I am in my current url for TagInfo.html: jar:http://localhost:9080/AMS/test.jar!/jsp/TagInfo.html; Frank, these are really browser questions, not crypto questions. I don't think the crypto folks can answer them. Let me suggest you ask in mozilla.dev.general. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Getting SSL server cert from within a plugin
Chris Masone wrote: Ok, I've explored further. It's not so much a null problem. It seems that, when I get the SSL cert using the code below, for the FIRST REQUEST AND RESPONSE I get the cert from the previous site. If there was no cert, I get nothing. This leads me to believe that this is _not_ the right way to be getting the ssl cert for the server to which the browser is connecting. It likely works for most cases, but there HAS to be a better way. Any help? Chris, you're asking questions about the JavaScript interface to NSS. Unfortunately, this news group is not regularly read by the folks familiar with the JavaScript code you're using. You might try another of the mozilla.dev.tech newsgroups, but I don't know which one (if any) will give you better results. Sorry. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Help on building NSPR, NSS on Windows
Frank Lee wrote: Found Cl to be from Microsoft Visual Studio 8 Right. It's Microsoft's version of cc, the c compiler. cl -Fonow.obj -c -W3 -nologo -GF -Gy -MD -O2 -UDEBUG -U_DEBUG -UWINNT -DNDEBUG=1 -DXP_PC=1 -DWIN32=1 -DWIN95=1 -D_PR_GLOBAL_THREADS_ONLY=1 -D_X86_=1 -DFORCE_PR_LOG /cygdrive/c/Frank_Lee/Eclipse/Academy_workspace/NSS_SignTools/mozilla/nsprpub/config/now.c make[2]: *** [now.obj] Error 53 is this a problem with the cl.exe file? No, it's a problem with your cygwin installation, and/or environment. Microsoft's cl program doesn't know about cygwin's expletive /cygdrive hack. You need to configure cygwin to NOT use /cygdrive but instead use windows compatible path names. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Import PKCS#12 cert into FF
John Smith wrote: How can I set password, so FF (and its plugins) would ask me for permission (password) each time FF or some plugin uses my cert's private key? Is that possible? See http://www.brainonfire.net/blog/solutions/?p=19 Look for the section entitled: Firefox master password options -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox https return error code -8101
Alex wrote: Hi all. I configurated an Apache server using mod_ssl. Everything is ok when I use IE access my website by HTTPS. But using firfox,I got an 'certificate invalid or corrupt' message with an error code of -8101. I have imported the ca certificate file to firefox and checked all three boxes when importing my ca certificate,but still can't connect. Why? According to http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html SEC_ERROR_INADEQUATE_CERT_TYPE -8101 Certificate type not approved for application. Most likely, your certificate has one or more extensions that specifically disallow its use for SSL server authentication or for key encryption. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: ports and ipv6 brackets in certificate subjects
Rich Megginson wrote: Nelson B wrote: Below, you seem to be asking how they are stored in certificates. I'll answer the questions about what appear in certs. 1) Are appended ports actually allowed in the subjectAltName or CN? No. How about the return value from SSL_RevealURL( fd ) ? Will that contain anything except a hostname? SSL_RevealURL and SSL_SetURL are a pair. SSL_SetURL makes a copy of the string it is passed and stores that copy in the SSL socket. SSL_RevealURL makes yet another copy of that string in the SSL socket and returns it to the caller. The string can contain anything, a host name, a URL, a favorite recipe. NSS's SSL library uses the string in the SSL socket in just one place. When the SSL protocol engine receives a certificate chain from the peer system, it calls an application-supplied callback function to process that received cert (chain). The application may supply its own function for that purpose, or it may choose to use libSSL's own built-in function SSL_AuthCertificate as that callback function. If the application does not supply its own function, libSSL will call SSL_AuthCertificate by default for that purpose. So the use of SSL_AuthCertificate is optional. The application that uses libSSL is free to provide its own function for the purpose of validating the received cert chain, and if it does so, it is free to interpret the SSL socket's url string any way it chooses, and/or not use that string at all. SSL_AuthCertificate uses the url string stored in the SSL socket as the source of the host name (or IP address string) that it compares to the contents of the cert. It passes that string to CERT_VerifyCertName. In CERT_VerifyCertName, if a SAN is present, the SAN contents are compared to the string as described below. Otherwise, the string is used to compare to the Subject Common Name (if any). While comparing the string to the SubjectAltName, the string is passed to PR_StringToNetAddr which attempts to see if it is an IPv4 or IPv6 address (NOT a DNS name) and if so, attempts to convert it to a binary IP address. Then, if the SAN contains dNSNAmes, they are compared to the string, and if the SAN contains iPAddresses, they are compared to the IP address returned by PR_StringToNetAddr. AFAIK, PR_StringToNetAddr does not ever expect an IPv6 IP address to contain brackets. 2) When an IPv6 literal address is in the CN or the subjectAltName, and if the answer to question 1 is that ports are not allowed, then are the square brackets that may surround IPv6 addresses still allowed? RFC 2818 only allows IP addresses in SubjectAltNames (SANs), not in Subject name CommonName attributes. As defined in RFC 3280, IP addresses in SANs are stored in binary form as octet strings, that is, as 4-byte IPv4 or 16-byte IPv6 binary addresses, not as strings of decimal ASCII characters separated by dots, nor hexadecimal ASCII characters separated by colons. So, you won't see brackets around IP addresses in certificates, because they aren't stored as printable strings in certificates. Does that mean we need to convert them to their string representation before we call CERT_VerifyCertName(cert, hostname)? Short answer: Converting a binary IP address to a string representation, and passing that string to CERT_VerifyCertName is generally NOT advisable. Generally, the host name or IP address that the user (or application) provided (generally in string form) is the authoritative definition of the server that you're trying to reach, and that's what you want to pass to CERT_VerifyCertName. The danger of taking an IP address in binary form and converting it to a string form, and passing that to CERT_VerifyCertName, is that the binary form may have come from a DNS lookup (or NIS lookup) and therefore may already be falsified result. That is, a poisoned DNS or NIS server may have already given you the wrong IP address, the address of an attacker's system. You don't want to verify that the server's cert matches the attacker-supplied IP address, because the attacker's server's cert will undoubtedly match the attacker-supplied IP address. You want to verify that the server's cert matches the authoritative name (host name or IP address) of the intended server, supplied by the user. That acts as a double-check that the DNS/NIS lookup did not send you to a attacker's server. But even though the RFCs define how IP addresses are represented in certificates, I think you'll not find any real CAs that issue certs with IP addresses in them. There are a lot of reasons for that. And now I've stated some of those reasons. There are still others. And it's not safe to use DNS lookups or reverse DNS lookups as part of the server identity verification process. So, IMO, your best bet is to compare the host names with the host names in the certs, and leave IP addresses out of the server identity verification picture. -- Nelson B
Re: question about gathering data in SSL
) an SSL3/TLS record, and the caller should switch from the SSL2 record gathering engine to the SSL3/TLS record gathering engine. In other contexts within libSSL, SECWouldBlock means that the progress on the SSL socket is stopped because of something that is NOT related to the underlying socket. It indicates that the caller should NOT use a poll/select type function to determine when further progress can be made on the socket. libSSL defines interfaces for calling application-supplied callback functions for several purposes, some of which are: a) validating a received cert chain, b) the bad cert callback, which allows the application to choose to override an error in the received cert chain, and c) the client authentication certificate selection callback, which asks the client application to choose a client auth certificate to send to the server. The callbacks listed above may initiate other activity that must finish before further progress can be made in the SSL handshake. For example, an OCSP request may be sent, or the callback may choose to ask the user (through a dialog)how to proceed (e.g. to choose a cert from among several). While the application is waiting for response from the user (or OCSP responder), the application may not wish to stop the entire thread waiting for that result. So, the callback may return SECWouldBlock to libSSL, telling it that the answer for which the callback was called is not yet known. LibSSL responds to that value by taking a path of execution that suspends the progress of the SSL state machine at that point, and returns to the caller (e.g. to the caller of PR_Read). When that happens, libSSL returns PR_FAILURE with PR_WOULD_BLOCK_ERROR. That is, libSSL effectively turns SECWouldBlock into PR_WOULD_BLOCK_ERROR. This means that upon return of PR_Read, the calling application cannot distinguish between the cases where the SSL socket is blocked waiting for more data to arrive on the SSL socket itself, and the case where the socket if effectively blocked waiting on local user UI action or OCSP response, based solely on the error code. But since the callback function that returns SECWouldBlock to libSSL comes from the same application that called PR_Read, presumably the application can arrange to communicate that knowledge to itself. See also http://lxr.mozilla.org/mozilla/source/security/nss/lib/ssl/notes.txt -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: RFC2511 or PKCS10 and SPKAC
Richard Levenberg wrote: Neither RFC2511 or PKCS10 (Certificate Request specifications) mention the use of SPKAC. I'm pretty sure that SPKAC doesn't fit within PKCS10 but I've only cursorily looked at RFC2511 so I'm not positive that a SPKAC couldn't be hammered in there somewhere. I know that many toolkits handle the SPKAC but I was wondering if any specification included it a a component of Certificate Requests. Richard, I didn't recognize the term SPKAC and didn't find it anywhere in mozilla sources or documentation. So I did some digging and found this. The term SPKAC seems to be a term from OpenSSL documentation, a name for the format and content of the DER-encoded data sent by a Netscape or mozilla browser in response to a KEYGEN tag. NSS seems to call it a PKAC, which is short for Public Key And Challenge. NSS has a structure named CERTPublicKeyAndChallenge for this. See http://lxr.mozilla.org/mozilla/search?string=PublicKeyAndChallenge I found only one function in NSS that knows anything about that. It is SECKEY_ConvertAndDecodePublicKeyAndChallenge. It parses an input DER-encoded PKAC, and it is not called from any NSS libraries or QA test programs. NSS has no code to create a PKAC, but PSM does. Therefore I consider NSS's PKAC code to be a misplaced part of PSM. PSM encodes PKACs, apparently for KEYGEN tags. See http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsKeygenHandler.cpp#90 and http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsKeygenHandler.cpp#574 Now, to your question, which I gather is essentially What standard (if any) defines the PKAC that mozilla sends in response to KEYGEN tags? I think the short answers are: a) I don't know yet, and b) probably none! I'll ask our PSM guru to look at this. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: nickname and FIPS mode password length restrictions
Wan-Teh Chang wrote: Nelson Bolyard wrote: I tried the above command when the module was not in FIPS mode, and the above command also failed. ERROR: Token NSS FIPS 140-2 Certificate DB not found. Try the token name NSS Certificate DB in non-FIPS mode. I am trying to reproduce the behavior David reported, using the command that he reportedly used. We should be able to reproduce what he experienced. He reported that the command modutil -changepw NSS FIPS 140-2 Certificate DB -dbdir . succeeded, even though he entered password as the new password. I was testing the hypothesis that perhaps the softoken module was not actually in FIPS mode, but the command succeeded anyway, despite having the FIPS mode token name string in it, rather than the non-FIPS token name. My test concluded that if his module was in non-FIPS mode, the above command would fail due to the slot name mismatch. I considered the possibility that the modutil command failed silently, appearing to have succeeded. But in that case, the new password should not have taken, and should not have worked thereafter, and David reports that it DID work thereafter. So, I conclude that the command must have succeeded. I considered that there are somehow two sets of DBs involved (at least two secmod.db's) and that the secmod.db on which modutil was working is not the secmod.db being used by his other application. I thought perhaps modutil runs the softoken module in FIPS mode, and his application is running the module in non-FIPS mode, with the same cert/key DB pair. Or something like that. But that doesn't help explain how modutil could change the password to password while it has loaded the module in FIPS mode. So, at this point, the only remaining untested hypothesis I have is that this is a difference between 3.11.2 and 3.11.3. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla's use of AIA caIssuers URIs
Anders Rundgren wrote: NSS (and therefor mozilla products) do not do automatic fetching of certificates at this point in time. Currently all protocols have a way of transmitting the necessary intermediate certificates, and mozilla products depends on these protocols. In theory yes, in practice no. If you use TLS client-auth as an example, FF would require that every sub-CA was known in advance by the relying party (server) in order to provide the proper DNs for certificate filtering selection. No. In TLS client auth, the server sends out a list of names of CAs that it trusts as issuers of client auth certs. The client is required to send a cert in that is issued directly (or indirectly) by one of the CAs named by the server. That is, the client's cert must be issued by a named CA, or have a cert chain that chains up to a named CA. The client it obligated by the TLS RFC to send as much of its cert chain as is necessary to establish that its cert was issued by one of the CAs named by the server. So the server doesn't need to keep any intermediate CAs below the ones it trusts; that is, between its own named points of trust and the client's EE certs. It is thought that, in bridge CA environments, that the server will send names of bridge CAs that have been cross certified by its own trust anchor(s). The the server will keep any certs between its bridge CAs and its trust anchors, and the clients will keep any certs between their EE cert(s) and the respective issuing bridge CA(s). This seems quite efficient. I believe the AIA caIssuers extension was introduced to reduce the need for static configurations. And at some point the various standard protocols may be modified to no longer require the cert chains they presently require. Automatic fetching is a PKIX feature, and is targeted for NSS 3.12. Good! But the SSL and TLS protocols will not immediately cease to require the sending of the cert chains as previously explained when libPKIX becomes available. Kai wrote: Both your root.cert and cacert.cert seem to have same serial number and issuer. That is forbidden. AFAIK each CA has its own serial number space. This should make it OK to reuse a serial number even within a CA hierachy. I would be an error if I let the root sign another CA and used serial = 1 for that one as well. CRLs identify revoked certificates by two things: issuer name, serial number. The implication is that certificates must be uniquely identified by that combination. Even RFC 3280 requires this. Each CA has its own serial number space, and its own unique issuer name. For two different certs to have the same issuer name and same serial numbers means that one or more CAs goofed. Anders -- Nelson B 12345678901234567890123456789012345678901234567890123456789012345678901234567890 0112233445566778 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: AES in CFB128 mode?
[EMAIL PROTECTED] wrote: Why would you like to use the CFB mode? Because that's what the current (non-NSS) code does. I'd rather just port, not change, the code. Is the CFB mode used in your implementation of some standard? Just curious. No, it is not a standard. But it is used by SNMP http://www.rfc-archive.org/getrfc.php?rfc=3826 Well, that's close enough to standard for our purposes. NSS doesn't implement SNMP, but if an SNMP implementation wants to use NSS's softoken, perhaps NSS's softoken ought to implement it. It would mean implementing a new set of PKCS#11 mechanisms, IINM. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: handshake, next handshake, security handshake
Peter Djalaliev wrote: Hello, I have a question about something I don't understand in the SSL implementation of NSS. When ssl_Do1stHandshake is called, it checks three handshake function pointers in the sslSocket struct: handshake, nextHandshake and securityHandshake. What is the difference between the three? SSL stands for Secure Sockets LAYER. the Layer originally included other protocols besides the protocol that became known as the SSL protocol. It also included SOCKS. The SOCKS code and the original SSL2 code were implemented as nested state machines. These variables held the state values of the various nested machines. The SOCKS implementation is NSS was abandoned long ago. It was superseded by a separate pushable NSPR module, which allows its implementation to be completely decoupled from the implementation of the SSL protocol. The SSL2 protocol implementations in NSS still uses two separate state machines, one to parse SSL2 records and another to handle the succession of records which is the SSL2 protocol. I can see that the ss-handshake pointer is set in the beginning of the SSL handshake by either ssl_SecureConnect or by SSL_ResetHandshake (if the socket is already connected) to either ssl_BeginClientHandshake or ssl_BeginServerHandshake. ssl_BeginClientHandshake, in turn, sets that pointer to ssl_GatherRecord1stHandshake, which wil receive the server_hello record from the server. Is the ss-nextHandshake used only for the SSL v2 implementaion? Yes, I think so. What is the ss-securityHandshake used for? I think it may now be unused. I think it was part of the old SOCKS implementation that was abandoned. Regards, Peter -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: export web sites certificate
Kaspar Brand wrote: https://bugzilla.mozilla.org/show_bug.cgi?id=315871 Would it make sense to create a separate bug entry for the getPKCS7() patch, since this is actually a backend-only thing? Kaspar, let me suggest that you write to Kai and ask him directly how to proceed. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: export web sites certificate
Kaspar Brand wrote: what i am trying to do, is export the web sites certificates that are listed in the Certificate Manager of Firefox and store them into an other file. I have tried the certutil command in the command prompt but i get the message that it is not a recognizable command. Any ideas what should i do to export the web site certificates? [Shameless plug:] try the Cert Viewer Plus extension, this should help you get it done: https://addons.mozilla.org/firefox/1964/ I like what I see in https://addons.mozilla.org/firefox/1964/previews/ While I have the attention of the list - and hopefully of some of the NSS/PSM developers: what do you think about the getPKCS7() patch I proposed for Bug 315871 https://bugzilla.mozilla.org/show_bug.cgi?id=315871 (https://bugzilla.mozilla.org/attachment.cgi?id=230307)...? This would add support for exporting a cert in PKCS#7 format from Cert Viewer. Do you have previews for the UI changes that patch makes? Does that patch put the features of your extension info FireFox? You might attach a preview to that bug, or add a comment with a URL for the preview to it. Any feedback welcome! I can't speak for any other NSS or PSM developers, but I welcome any help with NSS or PSM. Kaspar -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: about s/mime
sh wrote: Thanks. I'm saw a bit of documentation and study cmsutil sources. But it's not enough. I've a task where I receive a raw cms from mime parser сhunk by chunk. And I need decode it when I can. And I need to know what certificate I can use for decoding. Where I can look such code? Thunderbird use s/mime library in the same way? May be I need look at Thunderbird sources? Yes, but I suspect that's going to be a lot more difficult to understand than the MUCH simpler program cmsutil, which already does most of what you want to do, and doesn't have all the complexity of the browser in it. See http://lxr.mozilla.org/security/source/security/nss/cmd/smimetools/cmsutil.c -- Nelson B 12345678901234567890123456789012345678901234567890123456789012345678901234567890 0112233445566778 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: nickname and FIPS mode password length restrictions
glen beasley wrote: Nelson B wrote: David Stutzman wrote: What is the min/max password length when the module is operating in FIPS 140-2 mode? Wan-Teh will have to answer that. I think it has changed recently. It seems that the requirements have changed since the last time NSS was FIPS 140 evaluated, or at least our new test lab interprets them very differently. see: http://wiki.mozilla.org/Security_Policy#Specification_of_Roles In FIPS mode, the NSS cryptographic module imposes the following requirements on the password. * The password must be at least seven characters long. * The password must consist of characters from three or more character classes. We define five character classes: digits (0-9), ASCII lowercase letters, ASCII uppercase letters, ASCII non-alphanumeric characters (such as space and punctuation marks), and non-ASCII characters. If an ASCII uppercase letter is the first character of the password, the uppercase letter is not counted toward its character class. Similarly, if a digit is the last character of the password, the digit is not counted toward its character class. That's what we used to do. But IINM, Wan-Teh decided to abandon that because of a new interpretation of the rules from our test lab. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-client-auth FIPS201
Anders Rundgren wrote: Reading the FIPS201-1 specification, I find no support for hosting any CA certificates associated with the user certificates. This makes me wonder how you can use TLS-client-authentication if the relying party (server) only has the root and not immediate CA certificates at hand. TLS (like SSL 3.0 before it) requires that the server send out a list of names (DNs) of the issuer CA(s) that it trusts to issue client auth certs. These can be roots or intermediates. Could be a bridge. That's up to the server. An empty list is not permitted by the TLS RFC nor the SSL3 ID. The client must be able to construct a chain from its own EE cert to one of the CAs named by the server, in order to prove (to itself) that its cert was actually issued by one of the server's named client auth CAs. The client sends that cert chain in to the server along with its signature. The server then has enough of the chain to prove to itself that the client's cert was issued by one of the CAs that the server named in its cert request. Just to verify that these things can be a cause of trouble I removed an immediate CA certificate from my local trust store and I could not longer login using my TPM-hosted certificate. Unclear if that was on the client or the server system (or both). The solution seems to be that the relying party has access to all immediate CAs for the roots it trusts? This appears to be a bit impractical for scheme CAs supporting a lot of independent sub-ordinate CAs. Any comments? Solution involves client keeping the cert chain(s) for its EE cert(s), at least to the level of the CA named by the server. Anders -- Nelson B 12345678901234567890123456789012345678901234567890123456789012345678901234567890 0112233445566778 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Concurrent usage of NSS DB (one writer, multiple readers)
Nate wrote: I'm working on certificate management in GNOME, and 'no concurrent access to NSS for a given configdir' has brought the efforts to a standstill for now. I see that a sharable DB is on the roadmap for NSS 3.13. Awesome. In the meantime I'm wondering if having one writer and multiple readers to the NSS DB is a safe method of sharing a cert database between processes. No, it is not. Sorry. Specifically, only one process would initialize with NSS_InitReadWrite() and all others would initialize with NSS_Init() -- Nelson B 12345678901234567890123456789012345678901234567890123456789012345678901234567890 0112233445566778 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: OCSP/CRL handling in Firefox
GaryK wrote: .NET CLR 2.0.50727; .NET CLR 1.1.4322),gzip(gfe),gzip(gfe) Injection-Info: m73g2000cwd.googlegroups.com; posting-host=65.205.251.51; posting-account=bqHXlg0AAABIeE5JRZLSrHSri2ZbRXKH What's all that stuff? I am a technical director at VeriSign and was asked a question that Gerv recommended that I post to this mailist. As you know, VeriSign has spent a fair of time, money and effort to roll out our OCSP service which is currently supported as an option in FF. Having said that we're also continuing to publish CRLs/CSRs (which is also expensive), and we put both AIA and CDP extensions in most of the certs we issue. The reason why we do this is that in RFC2560 (the one describing OCSP), Section 5 Security Considerations, says: For this service to be effective, certificate using systems must connect to the certificate status service provider. In the event such a connection cannot be obtained, certificate-using systems could implement CRL processing logic as a fall-back position. I'm curious to know what FF does in this regard. Does it fall-back to CRLs when it cannot connect to our OCSP server? If not are there any plans to implement something like this in the future? I'm having a deja-vu experience here. You sent this exact message before on 2006-08-07 news://news.mozilla.org:119/[EMAIL PROTECTED] and there was quite a thread of responses at that time, including one of mine, news://news.mozilla.org:119/[EMAIL PROTECTED] to which you replied news://news.mozilla.org:119/[EMAIL PROTECTED] Is there something different about this latest inquiry that I'm missing? Since we have both of this to the standard we want to make sure that clients are taking full advantage of both and if not why not? Thanks for the help. I'm guessing that your request somehow got resent accidentally. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: why NSS can't build in windowsxp?
lihb wrote: When i compile PKCS#11 Test Suite, there's a error that can't find function SECMOD_init(char *dbname) in pk11test.c, i used the latest version 3.11. So i download all version NSS, from 3.3 - 3.11 and i found from 3.4, i can't find the SECMOD_init(char *dbname). i hope find some messages from the nss-3.4-release-notes, but i don't find any message. Is this function dead or Pk11 test Suite disrepair? Yes, the PKCS 11 test suite was essentially abandoned some years ago, at about the time of NSS 3.1 or 3.2, if I'm not mistaken. It is not currently supported, and is not currently built as part of NSS releases. It has not kept up with changes to the main NSS shared libraries. In fact, IIRC, it predates the time when NSS was converted to be a set of shared libraries. It's open source. If you want to work on it to bring it back to life, such a contribution would be welcome, I think. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: problems with NSS and NSPR binaries
Michiel van Meersbergen wrote: Ok, I'm no using the ErrorText routines anymore. They were hardly necessary anyway. (Nelson: the solution you suggest requires the use of 'private' headers: I'd like to conform to the released version of NSS/NSPR and not use anything that is marked as private.) That's understandable ... sort of. The code in the nss/cmd/... directories is supposed to be sample code. It's not supposed to be code that you take and use directly, but code that gives you ideas about how to solve certain problems yourself in your code. I do want to make those 3 headers public. I hope to make that happen in NSS 3.12. I do have (yet) another question about the binaries though. For NSS, I can choose (for Windows) from two sets of binaries: WINNT4.0 and WINNT5.0. Where do you have those two choices? Does some server offer both WinNT4 and WinNT5 flavors of the same version of NSS (e.g. 3.11.0) ? I beleive I read somewhere that the WINNT4.0 version was supposed to be the misnamed WIN95 / WIN32 version, and that this version was recommended for use in currently being developed applications. Wherever you read that, it was wrong. (Even if *I* wrote it. :) Like NSPR, NSS has both Win95 and WinNT flavors. When the WinNT flavor is built on a real NT 4.0 OS, the directory comes out named WINNT4.0. When the WinNT flavor is built on WinXP (or Win2k, I think) it comes out named WinNT5.0. Either way, it's the WinNT flavor, and it must use the WinNT flavor of NSPR. The Win95 flavor of NSS must use the Win95 flavor of NSPR. Now, NSPR also has two flavors: WIN95 and WINNT. The WIN95 variant is recommended, as I can read in the README file there. mozilla client products always use the Win95 flavor on Win9x,ME,NT,2k,2003 and XP. NSS-based server products that run on WinNT,2K,2003 and/or XP generally use the WinNT flavor of NSS and NSPR, because it's compatible with Fibers (light weight threading commonly used in Windows servers). My problem is this: the NSS binaries in BOTH the WINNT4.0 and WINNT5.0 releases are dependent on some files (lib*4.dll) only found in the NSPR WINNT release. Yes, both of them are WinNT flavors of NSS. Both depend on the WinNT flavor of NSPR. In fact, it looks to me like there is only a WINNT release for NSS (I can't even figure out the difference in the 4.0 and 5.0 version, they are 99% binary equal). Can anyone shed some light on this? I'm not aware of any single release that is available in both of those WinNT forms. Sometime in the last year, the contributor of the WinNTx.0 builds switched from building on NT 4.0 to Win2003 (IIRC), so builds made before some date should be WinNT4.0 and after that date WinNT5.0. I'd be a little surprised if both sets of builds existed for the same exact version of NSS. (But I've been surprised before. :) Is the WIN95 release for NSS missing? Yes, AFAIK. I think we need contributed builds of Win95 flavor NSS and NSPR. The current contributor of the WinNT flavor builds is not interested in also offering Win95 flavor builds. Thanks! Michiel van Meersbergen -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: vague error message from certutil attempting keygen
David Stutzman wrote: I created a new security database with modutil, added a root module to it and then attempted to generate a key using certutil and received an I/O error: # certutil -G -k rsa -g 1024 -d . certutil: unable to generate key(s) : An I/O error occurred during security authorization. That error is SEC_ERROR_IO. It originally meant that NSS received an error on the file it tried to read to get your password (e.g /dev/tty). That's what that error message quoted above is trying to say. It meant I can't read your password, not your password was bad. Then it grew to mean that NSS had a problem reading any file while trying to do its job. It meant that the problem was with file I/O, not with security computations per se'. Then in NSS 4.5, it grew into NSS had an error for which no NSS error code seems appropriate (that is, it became a catch-all error code). Today, IMO, way too many errors report SEC_ERROR_IO when they should report another error code. It's not difficult to invent new error codes. On the other hand, it is difficult to get mozilla clients to put new error strings for new error codes into their products, which is why so many error codes are reported in dialogs with decimal error code numbers rather than with meaningful error strings. I took a guess at the problem and set a password for the db using: # modutil -changepw NSS Certificate DB -dbdir . and then it worked fine. Right. It is intentional (IINM) that you cannot generate keys in the DB slot until it is initialized, including a password. Is this something that's fine the way it is or would you prefer (is it possible) to have it actually say the password is the problem? Being unable to generate keys when the slot is uninitialized is intentional. Putting out a bad error message in that case is not. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: signing javascript
Christian, I see you're not the first person to have had troubles with this. See http://forums.tjworld.net/viewtopic.php?p=210 and https://bugzilla.mozilla.org/show_bug.cgi?id=321156 . Based on your description (which I'll not quote here), I think your intermediate CA cert does not have the extension that makes it eligible to issue object signing certs. There are two similar PKI schemes for signing of files containing code (scripts, executables, whatever). They are known as object signing and code signing. Object signing cert chains have special extension in every cert in the chain (except the root) that makes them eligible to be used for object signing. Code signing has a special extension in the End Entity cert, but not in the CA certs. It sounds like you have a code signing cert chain. But mozilla wants an object signing cert chain. And IIRC, signtool wants an object signing cert chain also. When you mark the intermediate CA cert as trusted for object signing, that tells NSS to behave as if the cert did have that extension, which is why signtool then works. But when you remove the cert from the certdb, it loses that trust marking (which is an override for the missing extension) and so when you download it from the server, once again the cert lacks the object signing extension, and so that cert chain validation fails. I can see a few ways out of this: a) get an object signing cert from a different CA, or b) get Certum to create an intermediate CA with the object signing extension and then reissue your cert subordinate to that new intermediate, or c) get mozilla to change their XPI security checking code, to require code signing instead of object signing, or to require either one, or d) get the NSS team to change NSS to accept code signing cert chains whenever it is told by the appliation to require object signing cert chains. Any of the last 3 require getting some entrenched group to budge. I'll do what I can for the last two. You can tackle the first two. Regards, /Nelson ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: signing javascript
files from the browser should work, AS LONG AS the browser is not running when the other tools are running. You should be able to see your cert in the browser's cert manager, and should be able to verify that its chain is complete, no missing certs. If the chain is incomplete, you should import the missing certs into your cert DB before doing the signing (using either the browser itself or using certutil). Remember to have only one program using the DBs at a time. The browser should not be running when you're using certutil or signtool on your browser's cert and key DB files. Once I generated my signed jar, I removed all added certs from mozilla and opened the javascript in the jar. Result was that the cert was not recognized: certum root CA - certum level I - mycert and certum level I is not a cert that is delivered with mozilla. HOwever, certum root CA is... Once I import certum level I, it works fine, however that is of no use to the users on the net as I cant ask them to import some cert. I wonder, however, whether it is possilbe to deliver the missing cert as part of the signed jar file? When you sign the jar file, signtool will put as much of the cert chain into the JAR file as it can find. If signtool can't find the complete chain, it will put an incomplete chain into the JAR. If your JAR file doesn't have the complete chain, then signtool couldn't find the complete chain in the cert DB and nssckbi.dll files to which it had access. The implication is that the Certum 1 intermediate CA cert was not in the browser's cert8.db file when you used it to run signtool. Any pointers on whether this is possible and how to do so? Make sure that the complete chain is available to signtool, then try signing again. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Simple guide for using certs and crypt on a smart card
Sideswipe wrote: Can some point me to some docs on how to import certs and and keys from a smart card in firefox and thunderbird? Not exactly. With FireFox and ThunderBird (FF/TB) you don't import certs and keys from smart cards. Instead, you make FF/TB aware of them on the smart card, and it uses them right on the smart card when it needs them. This is quite different from the MSIE approach, which imports the cert from the smart card to the system's cert store (registry) where it may stay, even after you remove the card. So, for FF/TB, the objective is to make sure that FF/TB can see the cert on the card, and can use the key on the card. To do that you need to a) ensure the PKSC#11 module for the smart card is installed into FF/TB and then b) ensure that FF/TB can see the cert on the card, so that you can select it for use in signing and/or encryption of email, and/or web authenticating. Admittedly I am new to this so I need some step-by-step instructions. When you installed your smart card hardware and/or software, it should have installed a software module (a PKCS#11 module, in the jargon) into FF/TB for you. You should be able to see it in FF's list of known crypto modules. Go to Tools - Options - Advanced (tab) - Security Devices (button) There you should see a list of Security Modules and Devices. That list should include: - NSS INternal PKS #11 Module - Builtin Roots Module and a third module, which is for your smart card. If it does, then you're read for step b (listed above). Otherwise, you must Load the module for your smart card in this dialog. To do that, click the Load button. Then type in a name for your module (e.g. NAME smart card module where NAME is your product's name), and the name of a PKCS#11 module file, e.g. mycoolpkcs11module.dll. You'll have to get the name of the .dll file from your smart card maker or smart card reader maker (if it has a separate reader). You only need to register that module once, not every time you use it. Once your smart card module is loaded, and you can see it in that list of Security Modules and Devices, You will want to Log in to it using the login button in that same Security Modules and Devices dialog. Then you're ready for the second step. The second step is to look at the certificates in the smart card using FF's Certificate Manger. When you're logged into your smart card, then you should be able to see your smart card's certificate(s) (if any) by going to the Certificate manager. Steps are: Tools - Options - Advanced (tab) - View Certificates (button) Then your smart card certificates shuold show up in Your Certificates, but they might show up in Other Peoples' certificates if FF cannot find the private key on the smart card. If you see your cert there, you should be able to highlight it and click on the View button to see all the gory (er, Wonderful ;-) details. Let's get that far before going on to the next step, getting this to work in TBird. Hope someone has some info for me Christian Bongiorno Ciao, -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: problems with NSS and NSPR binaries
Michiel van Meersbergen wrote: I'm running into some troubles using the original binaries from the NSS releases directory. Whether I use the debug or the optimized binaries for NSS 3.11 (from WINNT5.0_OPT.OBJ/) with the NSPR 4.6 binaries (also from WINNT5.0_OPT.OBJ/), I always get 'error 126' as the corresponding error text to an NSPR error code, At the present time, it is best (IMO) to not expect to get error strings from the official NSS shared libraries or other binaries. I hope to fix that in NSS 3.12. In the mean time, use these 3 header files: http://lxr.mozilla.org/security/source/security/nss/cmd/lib/NSPRerrs.h http://lxr.mozilla.org/security/source/security/nss/cmd/lib/SECerrs.h http://lxr.mozilla.org/security/source/security/nss/cmd/lib/SSLerrs.h Sample code to do that is seen at http://lxr.mozilla.org/security/source/security/nss/cmd/lib/secerror.c#53 -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New method for linking smart cards to web browsers
Anders Rundgren wrote: http://www.w3.org/2006/02/axalto-paper.html This paper says that we can soon forget about P11 and such and rely on AJAX-like access to crypto. We wouldn't have to worry about vendor-independent crypto device interface standards if everyone in the world would agree to adopt one vendor's proprietary standards! Why, of course! Why didn't we think of that? :-) ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS Cache question
modules should NOT be loaded when a process forks. Each child process must initialize its PKCS#11 modules for itself. So, for multi-process shared-memory servers, the parent should create the server session cache and create the listen socket(s), THEN spawn the children, which will inherit the shared cache and shared listen sockets, and then finally it (and each of the children) should initialize the PKCS#11 module for itself. Or, if the parent will not also act as a server, but only the children will accept connections on sockets, the parent can skip initializating the PKCS#11 module alltogther. This means that initializing the NSS/SSL server session cache takes place BEFORE calling NSS_Init (or any of its variants). Many find this surprising. The selfserv demo server app does all this correctly, IINM. Assuming that is ok, is it bad to call SSL_ShutdownServerSessionIDCache() if the cache hasn't been initialized? No, that should be harmless, as long as you don't have multiple threads trying to do this simultaneously. Of course, it would be a programming error to try to do this in multiple threads simultaneously. I briefly looked at the code and it seems ok to me but I don't want to make assumptions. It is intended to be safe to close the global server cache instance even if it has not been initialized. If it should prove not to be safe, that would be an NSS bug. thanks Hope this helps. I have a feeling I've just made the problem seem bigger :) rob -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to compile nss3.10 on FreeBSD?
Alex wrote: i have compiled nss3.10 successful on Windows platform(cygwin), but i ftp the same version nss to a FreeBSD platform, it can't compile? please help me, thanks. bash-2.05b# make nss_build_all ../coreconf/config.mk, line 44: Need an operator ../coreconf/arch.mk, line 56: Missing dependency operator ../coreconf/arch.mk, line 58: Need an operator ../coreconf/arch.mk, line 60: Need an operator ../coreconf/arch.mk, line 69: Missing dependency operator ../coreconf/arch.mk, line 71: Need an operator ../coreconf/arch.mk, line 73: Need an operator Error expanding embedded variable. Here's a thought: Try the build with gmake instead of make. On some platforms make is gmake. On others, gmake is separate. NSS makefiles are gmake makefiles. Try using gmake explicitly. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Get only personal certificates
Primo It wrote: Is possible to get only de Personal Certificates? the getPermCerts brings all certificates and getCACerts brigns all CA certificates. Is there some method that get just de Personal Certificates? Primo, Apparently your questions concern the Java JSS CryptoManager class, which has methods by those names. I hope one of our JSS experts will answer that question soon. You also asked: How can i get de installed tokens devices driver Which either means: a) how can I enumerate the tokens for a PKCS#11 module? or b) how can I enumerate the installed PKCS#11 modules? I'm not sure which of those questions you're asking. How can i set a new token device programacticali I think you're asking how to install a new PKCS#11 module, but I'm not sure. Please expect most questions to be answered after 1-2 business days. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Forcing specific CA for domain
Bob Relyea wrote: In general, this cannot be done. It is possible to put name constraints on CAs that are subordinate to a root CA, but not generally on root CAs. I was afraid of getting an answer like this but thanks for replying anyway. :) This is the general problem PKIX and cross certificates are supposed to solve. In the PKIX model you would create a new intermediate with the same subject and keys as the root cert you want to trust. You would then add constraint extenstions to the intermediate to limit what name spaces it can use (and what policies it can issue). That allows you to extend limitted trust to other certificate domains. This is consistent with what I said. Distrust all roots CAs but your own. Issue intermediate CA certs with name constraints that effectively replace all the distrusted root certs. PKIX is currently planned for NSS 3.12, so won't be available in any mozilla based products this year. He needn't wait for PKIX to do the above. PKIX is only needed if he's going to involve policy-based chain building. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: pkcs#7 envelopeddata decoding
Michiel van Meersbergen wrote: Another 'oddity' I should mention, is that the PKCS#11 DLL which provides access to the appropriate certificates and keys will ask for the proper authentication itself - in other words, when a private-key function like 'decrypt', 'sign' or 'unwrap' is called, it checks if authentication is needed, and asks for a password (via a message box). So I never need to provide any password-callbacks, do I? If your PKS#11 module does its own user authentication, it should tell the appliations that use it that it does so, by setting the CKF_PROTECTED_AUTHENTICATION_PATH flag in the token info flags. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Forcing specific CA for domain
Balint Balogh wrote: Hello Suppose Example Ltd. runs its own local CA that issues certificates to servers and email addresses at example.com and its subdomains. The certificate of this CA is installed as a trusted CA certificate into every browser (Firefox) and email client (Thunderbird) of employees. Example Ltd. wants to make sure that only their own CA may sign certificates claiming to belong to example.com or any of its subdomains. That is, if a user tries to connect to any *.example.com server whose SSL/TLS certificate has not been signed by the CA of Example Ltd., the user should see a security warning about an invalid server certificate (likewise for email if using S/MIME). In general, this cannot be done. It is possible to put name constraints on CAs that are subordinate to a root CA, but not generally on root CAs. Without this security measure, any CA that has its certificates in client software has the power to thwart SSL/TLS security by issuing fake certificates claiming to belong to *.example.com servers or email addresses. The user has control over which CAs he trusts. If there are CAs in the browser's list that the user believes to be untrustworthy, then the user can tell his browser to actively distrust them. Is there a way around this problem, without disabling or removing all other certificates? Certificates signed by other, widely recognized CAs, whose certificates are included by default in Mozilla products should still be considered valid except for *.example.com domains. If you really don't trust any CAs except your own to be truthful to you, then you should mark all other CAs but your own as distrusted. Thanks for any help. Balint Balogh Regards -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: My shy certificate
Dave One thing that isn't clear to me: how (with what program, by what exact steps) did you originally generate your pair of keys and get your certificate? I'm thinking now that perhaps you did it with some tool that did not use your TPM, and consequently, the private key was never in the TPM. Perhaps you did it with your mozilla-family product, or perhaps with Windows own certificate manager or cert enrollment software, and that software used its own native key generation and key storage, rather than the TPM. In that case, the private key you have now is not in your TPM, and getting it into the TPM may yet be a problem. Some TPM devices will only work with private keys that they generate themselves. That is, they will not let you import a private key into them. Now you have a cert and private key, working in mozilla (FF/TB/SM), but I think we have not yet established that the private key is in the TPM. You may find it difficult to import the private key into the TPM. So, assuming that you're the first of many future HP TPM users, please help us to understand exactly how you got that private key in the first place. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CERT_VerifyCertificate question
David Stutzman wrote: Here's some certutil -L output for the cert I am playing with here: Signed Extensions: Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Name: Certificate Type Critical: True Data: SSL Client,SSL Server That says the cert is valid for SSL, but not S/MIME or object signing. It sounds like you're inventing a new network appliation/protocol for this, so perhaps none of those categories directly applies to you. It's up to your application to ask for the usage that is relevant it it. I tested the certificate with the usages above passing in both certificateUsageEmailSigner and certificateUsageObjectSigner to CERT_VerifyCertificate and got a -8101 (SEC_ERROR_INADEQUATE_CERT_TYPE) both times. That's exactly as predicted, given the Certificate Type extension above. Is it ok to ignore cert usage and just look at the raw key usages myself and require that digital signature and non-repudiation be present or am I just beating the dead horse with the stick here and really should be using either an email signing cert or an object signing cert? You're not likely to get CAs to issue a cert for a new type of usage that you propose. So IMO your best bet is to decide which of the above usages most closely matches what you're doing, and then ask CERT_VerifyCert* to verify for that usage. For your personal testing and development purposes, you could easily just test for SSL client usage, since that's what you have. Personally, I'd say that what you're doing sounds more like email usage than SSL, because you're generating durable signatures, which email does and SSL does not. But for your immediate test purposes, SSL certs should be adequate. Again, I just need to sign an arbitrary blob of input data that is passed in and pass it back to the caller and it's not being used for email. Think of these usages more abstractly. Email usage generates signatures that are attached to the data, and that (may) last as long as the data to which they are attached. SSL generates signatures that are used at the beginning of an SSL connection and are then immediately discarded. The data that passes through the authenticated channel is not itself signed, and when the channel is over and done, there remains no durable signature. Which of those applications sounds more like yours? Figure that out, and then Pick a cert of that type. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: My shy certificate
Dave Pinn wrote: Nelson B wrote: Best bet is to get a formatted listing of the certificate itself, showing all the extensions and their criticality. OK, here goes: Non-critical X.509 version 3 extensions: * CRL Distribution Points * Authority Key Identifier * Subject Key Identifier * Authority Information Access * Subject Alternative Name * Netscape Cert Type * Certificate Policies Critical X.509 version 3 extensions (values shown below keys): * Basic Constraints - Subject Type=End Entity, Path Length Constraint=None * Key Usage - Digital Signature, Non-Repudiation (c0) I don't have a clue what it all means. Is it all good? Yes. Looks perfect. No unknown critical extensions there. All these extensions are known to mozilla products, except for the Policies extension which is not critical. In short, I see no reason among those extensions why the cert should not appear in the cert list of FF or TB. Out of curiosity, what tool(s) did you use to get that data? -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: My shy certificate
Dave Pinn wrote: or try wiht the token name certutil -L -h Embedded Security Chip X:\ThunderbirdProfilecertutil -L -h Embedded Security Chip -d . Enter Password or Pin for Embedded Security Chip: X:\ThunderbirdProfile That cannot be good, and Yes, I'm sure that I got the password right. OK. The fact that it prompted you for a password indicates that you did talk to the PKCS#11 module. It suggests that a) the PKCS#11 module is not making the certificate available, or b) the certificate cannot be parsed by NSS for some reason, or c) some other problem with the PKCS#11 module. There are more tools, including one that will go right down into the PKSC#11 module and examine the actual bits of its responses. But this is a debugging tool, designed to help the writers of PKCS#11 modules debug their modules. Even if you found something this way, you couldn't fix it (unless you're a developer of that PKCS#11 module or have source code for it). I think this is the point at which it is reasonable for you to ask your laptop maker to support their product. Ask 'em if they tested with any mozilla browser or email products. If you can get the complete binary certificate out of the thing, and can send me the certificate, I can examine that. That's about all that we haven't done that's reasonable to do, at this point, IMO. I wonder if they put the certificate into (say) windows certificate store rather than into the TPM. Perhaps all they put into the TPM is the private key? -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Duplicate messages in this group/list
Lately there have been a number of duplicated postings in this group/list. This seems to occur when members of the mailing list reply to a message, and send their reply to both the mailing list and the newsgroup. So, let me suggest to mailing list members that when you reply to a message be sure your reply goes to the mailing list, or the newsgroup, but not both. Then the readers will get just one copy. -- Nelson B (moderator: dev-tech-crypto mailing list) ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Windows Zip Util for XPI's?
Paul suckerformimi wrote: I've seen this asked many times, but I haven't seen any solutions posted. What zip utility can I use under windows to create a signed XPI? I can't find any that let me control the order of the files. Don't look for a special zip tool. Look for a JAR signing tool, and an ordinary zip tool. Any command line zip tool will let you control the order in which the files are added to the zip archive. It might require you to run the zip tool once for each file to be added. If you get a signed XPI file whose contents are not in the right order, you can merely unzip its contents into a tree of files, and then rezip those files into a new zip file in the right order. Any signed XPI file is actually a signed JAR file. The important thing about both types of files is *NOT* that they're zip files. There's nothing special about the zip format itself in XPI files or JAR files. This is somewhat explained in http://developer.mozilla.org/en/docs/XPI The important thing is that the files that make up the contents of the zip must conform to the specification of a signed JAR (Java ARchive). http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html To make either a signed XPI or signed JAR file takes two steps: 1. set the hierarchy of files according to the signed JAR specification, using any of the spec-conformant JAR signing tools, then 2. zip them up. In the case of XPI files, the files have to be zipped up in a certain order. But that's a mere detail of how they're zipped up, after the full signed JAR contents have been created. Creating the files that go into the JAR (zip) is the hard part. I am aware of two tools for creating signed JARs. 1. Sun's jar and jarsigner tools (which make a JAR, and then sign it) http://java.sun.com/j2se/1.5.0/docs/guide/security/SecurityToolsSummary.html 2. NSS's signtool http://docs.sun.com/source/816-5531-10/app_sign.htm http://lxr.mozilla.org/security/source/security/nss/cmd/signtool/README The JAR specification does not impose any order on the files within the zipped JAR. The files may appear in any order in the zipped JAR. It permits multiple signatures (signature block files) to exist in the JAR, with different subsets of files signed with each signature block. The XPI specification allows only one signature block file (that is, .rsa or .dsa) per JAR, and requires that it be the first file in the zipped JAR. NSS's signtool utility has some command line options that will also zip up the results. The -Z option does this. When used together, the -Z and -X options cause the zigbert.[rd]sa file to come first in the zipped output. Whether -Z is used or not, signtool leaves the hierarchy of files intact so that any ordinary zip tool may be used to do the final zip step. This gives the zip creator maximum flexibility over the type of compression used with each file, among other things. Also, what's the easiest way to tell whether my XPI is properly signed? Is there an NSS utility that does this? Signtool will tell you if your file is a valid JAR file, but will not check that it is also a valid XPI file. Ultimately, FireFox or SeaMonkey themselves are the best test tools for XPI files. Thanks in advance, Paul -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Go Daddy 6-in1 certs and NSS?
Frank Hecker wrote: Someone brought to my attention today that Go Daddy is now offering a 6-in-1 SSL certificate where they allow you to associate multiple domain names from different TLDs with a single certificate: https://www.godaddy.com/gdshop/whatsnew/landing.asp?se=%2Bapp%5Fhdr=ci=4635#anchor76 (For example, you might have an SSL certificate specifying the domain names as foo.com, foo.net, foo.org, and so on, up to six total.) Based on my reading of RFC 2818 (in particular section 3.1) and what I think is the relevant source code (in the NSS function cert_VerifySubjectAltName) it appears that such certificates should work fine in Firefox and other Mozilla-based products, assuming that the names are stored in the certificate using SubjectAltName as opposed to CN. Am I correct in this supposition? Yes. It should. I'd like to see an actual example of their 6-in-1 or wildcard certs in use on the internet. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox password changer
Charles Majola wrote: Can anyone tell me how I can go about changing firefox's saved proxy password from an external program. I'm trying to use libnss but I can't seem to figure out how it stores/retrieve the password. There's a sample program that shows how to decrypt those passwords. See it at http://lxr.mozilla.org/security/source/security/nss/cmd/pwdecrypt/pwdecrypt.c The difficult part is done by PK11SDR_Decrypt(). There's also a corresponding PK11SDR_Encrypt(). These are parts of the Secret Decoder Ring API. See the prototypes at http://lxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11sdr.h#44 -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Sign/Verify text in FireFox
Pablo Andrade wrote: I would like to ask you, if is there a solution out there so you can verifiy a signature on the server, or it has to be developed from scratch? Pablo, Your original inquire was about a way to Verify in FireFox. That's the subject of the message to which I'm replying. But you're asking about ways to verify on a server, which presumably is not running FireFox. We have a e-goverment solution, who signs/verify plain text documents at client side using CAPICOM. Now we are trying to use Firefox/Linux as an alternative to IE/Windows. We think Crypto.SignText from Mozilla could be a start, but we still have the verify problem. The signatures produced by crypto.signtext in FireFox are CMS (a.k.a. PKCS#7) signatures. NSS has several stand-alone scriptable command line tools that do this job. The cmsutil program would be my recommendation for this. -- Nelson B 12345678901234567890123456789012345678901234567890123456789012345678901234567890 0112233445566778 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: certutil not able to retrieve the subject dn of a certificate
udaybhaskar wrote: Dear all, I was trying to retrieve the subject dn of the enclosed certificate with enclosed? This mailing list does not permit binary attachments. I suggest you make a base64 encoded (a.k.a. PEM or ASCII Armored) version of the cert and send that in the body of your email. NSS API, in vain. (I am retrieving the subjectName field of CERTCertificate structure) I tried the same thing with certutil binary included in nss-3.9. Even that is not giving the subject dn. I was able to retrieve the derSubject field. But no success ,when I try to encode this item. I was able to get the individual fields of subject distinguished name such as common name, email, organization etc. using the NSS API (CERT_GetOrgUnitName http://lxr.mozilla.org/security/ident?i=CERT_GetOrgUnitName etc.) Please tell me if there is anything wrong with the subject DN field of this certificate. Regards, Udaybhaskar -- Nelson B 12345678901234567890123456789012345678901234567890123456789012345678901234567890 0112233445566778 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Building NSS 3.11.1 as static libraries on Windows?
Jim Spring wrote: At least when browsing: http://www.mozilla.org/projects/security/pki/nss/intro.html It looks like it should be possible to use the static libraries built on windows by linking against nss.lib, ssl.lib, and libnspr4_s.lib. However, this does not appear to be working properly -- when linking I am getting a whole lot of unresolved symbol messages. (I am using NSS in an external application...) I guess the basic question is, does NSS actually support building and using static libraries? Is there any voodoo necessary to get it to work? Jim Spring! Long time, no see! Actually, quite a few of the NSS command line tools link with NSS static libs. See a list of them with this URL: http://lxr.mozilla.org/security/search?string=USE_STATIC_LIBS I suggest you build one of them and look at its link command and follow that example. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: crlutil: stuck in infinite loop when creating a new crl
Paul Neyman wrote: Hello! I've been trying to create a new CRL using crlutil, and it gets stuck in an infinite loop. I've traced it down to SECU_FindCrlIssuer function. Here's the excerpt from the code: So, if the certificate is not trusted, and the call to CheckCertUsage does not return a success, the loop will restart from the head, because there's no advancement over the list. Am I missing something here? Paul, This sounds like https://bugzilla.mozilla.org/show_bug.cgi?id=325307 which was fixed over a month ago. Is it really the very same bug?? Please tell us the CVS version number of the source file that contained this error, and where and how you got it. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Importing CRL using NSS API
Paul Neyman wrote: Thanks for the quick reply. Let me clear up myself. Here's what's happening: The crlutil code, however, uses method SECU_ReadDERFromFile, which is not exported as public, and I get a failure during linking stage trying to use sectool.lib. Um, it's not? It was listed in the header under /private, so I assumed it's not. Thanks for clearing this up. I don't think it's cleared up yet. There are many different meanings for the terms public and private. The linker uses public to mean available in this library to resolve symbolic references from other binaries that are linked with this library. In that sense, all the symbols in sectool are public. Another use of public and private involves the intentions of the software developers. In that sense, public means the software developers intended for other people (other software) to use this symbol and private means the software developers intended for this symbol to be only used by NSS itself, internally, and did NOT intend for this symbol to be used by any code outside of NSS itself. Any time you see comments in a header file about a function being private, or you see a symbol defined in a header file in a directory named private, it refers to the latter meaning, the intentions and permissions of the NSS software developers. When the NSS developers declare a symbol to be private, they are saying that at any time, in any future release, they may remove or redefine that symbol, without warning or advanced notice. Any problem that you have when they do so is not their problem. So, it's best not to use symbols that the developers have declared private. Some symbols are public in the linker's sense of that word, but are private in the sense of the developers intentions. All the symbols in sectool are that way, IIRC. You said that you were having linking troubles. That sounds like you are saying that the linker believed the symbols were not public in the linker's definition of that word. That would be very surprising indeed, because, as I wrote before, sectool is not a shared library, and consequently there is no way for any of its internal symbols to be made private (in the linker's sense of that term). All its symbols are publicly linkable (as far as the linker is concerned, having nothing to do with developers' intentions). What problem are you having linking with sectool.lib? What error do you get? If I link sectool and nss3 (for other calls my application does) during linking stage, I get a bunch of errors about method redefinitions (already defined in nss3) and I get an error about MSVCRT conflicting with use of other libs. secutil.lib(secoid.obj) : error LNK2005: _SECOID_FindOID already defined in nss3.lib(nss3.dll) Wait. that error message doesn't mention sectool. It mentions secutil.lib. You shouldn't be linking in secutil.lib. secutil.lib is part of nss3.dll. secutil.lib(secasn1d.obj) : warning LNK4006: _SEC_ASN1DecodeItem already defined in nss3.lib(nss3.dll); second definition ignored Yeah, you definitely should not be linking in any of the .lib files that are components of nss3.dll into your code. You should be linking nss3.lib (for the purpose of using nss3.dll). Now, what do these secutil issues have to do with sectool.lib? LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library Sounds to me like you're trying to link in a LOT more than sectool and nss3. Take a look at how the command tools in nss/cmd/* are linked. Trying building some of them, and follow the examples of the link commands they use. That's my suggestion. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Importing CRL using NSS API
Wan-Teh Chang wrote: Paul, The code in mozilla/security/nss/cmd/lib is intended for use by the NSS command-line tools only. This is why the header file secutil.h, which declares those SECU_ funcitons, is marked private, and the static library libsectool.a (sectool.lib) is not part of the NSS binary distributions. That's true. On the other hand, our documentation also says in many places that the source code in nss/cmd is sample code, implying that it is somehow exemplary. We reserve the right to change or delete any private code without warning. That leads people to ask me if it's OK for them to make copies of (some of) the functions in the nss/cmd/lib sources. Clearly there's a problem if we have sample code that people cannot rely upon and cannot copy. We need to figure out some solution for this. Everyone shouldn't have to reinvent the wheel for functions in nss/cmd/lib just so that we have the right to change them at will. But I don't know the answer. I wonder if we need a slightly different license than the MPL for that code. -- Nelson B 12345678901234567890123456789012345678901234567890123456789012345678901234567890 0112233445566778 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox custom SSL (crypto) provider
Dan M wrote: Re-read my initial post, and I asked the wrong question. It was written in haste, my apologies. Let me clarify... We're actually not looking to replace the SSL engine in Firefox, but just use a different crypto provider (I was thinking OpenSSL crypto engine when I wrote the message). We're developing a hardware device similar to a crypto accelerator and, when it is installed on the local machine, we would like all SSL-related crypto routines in Firefox to be redirected to our device. By all SSL-related crypto routines, do you mean to include all the signature verification functions, such as those done to verify cert chains received from remote servers? My hardware developers tell me this could be quite cumbersome if we're not implementing the full PKCS#11 interface. I'm just looking to find out whether it can be done without implementing all the authentication features of PKCS#11. What are their concerns exactly? LOTS of people, companies and projects have implemented enough of PCKS#11 for their purposes, to do SSL with their crypto providers. That includes everything from high end network attached crypto accelerators to low end USB crypto fobs (dongles). NSS provides an open source framework for implementing a PKCS#11 module. NSS's own soft token PKCS#11 module is pretty complete (enough for NSS's own purposes) and is open source, so it provides major implementation clues for others doing their own implementations. Finally, I wonder what you mean by all the authentication features. Clearly a PKCS#11 module that will do private key operations without authentication of any sort is an oracle, just waiting to be used by bad guys. (Who needs to have your private key when they can just get your module to use if for them whenever they like?) In any case, I do think PKCS#11 is your best bet. It's well supported and LOTS of others have trod that path before you. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Importing CRL using NSS API
[EMAIL PROTECTED] wrote: I'm trying to import a CRL (in DER format) using NSS API. Since 3.4 API does not have an import function available, You're using NSS 3.4? The current NSS is 3.11 . I think 3.4 is no longer supported. I took the source code from the crlutil and massaged it to fit into our application. That sounds resourceful, but I'd be surprised if you can achieve what you want with NSS 3.4. The crlutil code, however, uses method SECU_ReadDERFromFile, which is not exported as public, and I get a failure during linking stage trying to use sectool.lib. Um, it's not? ALL the non-static functions in sectool.lib are public (in the linker's sense of that word). Since sectool is not a DLL, no .def file is relevant, and no function names are hidden. sectool is not a shared library, not a dll. sectool.lib is not a set of stub functions for accessing a DLL, that is, it is not an export lib (as would be the case if sectool was a DLL). The command dumpbin /EXPORTS sectool.lib doesn't show any symbols, because there aren't any DLL exports in it. sectool.lib contains the actual code for the library's functions. The command dumpbin /symbols sectool.lib shows the names of all the functions in sectool. The command dumpbin /SYMBOLS sectool.lib | fgrep SECU_Read outputs 101 0EC9 SECT6 notype ()External | _SECU_ReadDERFromFile What's the easiest way to make this function publicly available? It already is. it's in sectool.lib, not nss.lib. I tried modifying nss.def in nss/lib/nss, That .def file is for producing nss.lib, the export library file for nss3.dll. But the function you want is not part of nss3.dll, so nss.def has no relevance to this issue. but I'm not sure how to link sectool during nss.lib build; Are you trying to alter some code in nss3.dll so that it calls SECU_ReadDERFromFile, and then link SECU_ReadDERFromFile into nss3.dll? If so, I'd suggest calling SECU_ReadDERFromFile from your application instead, and linking your application (not nss3.dll) with sectool.lib. it seems to be built separately at a later stage. Yes. The code in sectool.lib is NOT for use in any NSS shared lib. I'd appreciate any hints. What problem are you having linking with sectool.lib? What error do you get? Is this a function name mangling issue? Are you calling SECU_ReadDERFromFile from c++ code? If so, then this is likely a problem with the declaration of SECU_ReadDERFromFile in the header file. Thanks. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox custom SSL provider
Dan M wrote: Hello, We've developed a custom SSL provider engine and would like to be able to use it as the default Firefox engine. We don't want to use it for other cryptographic operations because it doesn't fully implement the non-SSL related features of PKCS#11. Can this be done easily? Thanks, Dan No, it can't be done easily. Why would it be a good idea for users to be able to replace such a crucial security component easily? -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Signing with Firefox Built-in db
I want to try to bring some closure to this thread. suckerformimi did ultimately have success, and was finally able to sign his code with signtool. He was very resourceful. Along the way, he solved MANY issues, with just a little help from folks on this alias. I want to report on his journey. I don't think I'll give away any confidential information. He started with a pair of files containing a code signing cert and the corresponding private key, with file names ending in .spc and .pvk. The spc file was apparently an ordinary DER encoded cert (e.g. .cer file). The pvk file was (is) apparently an old Microsoft proprietary file format. The cert imported with Windows' cert manager in the usual way, but the pvk file was an unknown. He found a tool to import that pvk into his Windows private key store at http://www.microsoft.com/downloads/details.aspx?familyid=F9992C94-B129-46BC-B240-414BDFF679A7displaylang=en Once his cert and private key were imported into Windows, he was able to create a PKCS#12 file (.pfx) using Windows' cert manager cert export wizard. pk12util -l (list) was able to list the content of that pfx file without trouble. (That's a new feature of pk12util in NSS 3.11). So far, so good. But pk12util -i (import) always complained that the file had an improperly formatted DER-encoded message (SEC_ERROR_BAD_DER). He had the right password, and the file had friendly names for the certs and private keys. (Missing or wrong passwords and missing friendly names are the two known causes for failures of pfx file imports with NSS.) Finally, he got the idea to try importing the pfx file into NSS cert and key DBs using FireFox instead of pk12util, and that worked (!), which is mysterious. You see, FireFox and pk12util use the same code in the same shared library to decode and import PKCS12 files. So I'm a bit mystified why FireFox worked where pk12util failed. That's the subject of bug https://bugzilla.mozilla.org/show_bug.cgi?id=338335 Once he successfully imported the pfx file into NSS DBs, all he had to do was discover the friendly name (a.k.a. nickname) on his cert in the cert DB (something FireFox doesn't show, but certutil does). Then he was able to sign his code with signtool, using his FireFox NSS DBs. So, the issue is resolved for suckerformimi, but is just beginning for the NSS development team. I think we're not likely to solve that mystery of SEC_ERROR_BAD_DER until we get a pfx file with which we can readily reproduce that problem. I won't ask suckerformimi for his pfx file, since that would obviously compromise his code signing cert. If you have a pfx file that pk12util can't import, but FireFox can, and you're willing to let the NSS team have that pfx file (and its password) for debugging purposes, please contact me. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS Apache module - mod_nss
Rob Crittenden wrote: A fair bit of work has been done to mod_nss, an SSL module for Apache that uses NSS instead of OpenSSL, since it was released last September. Changes since then include use the NSS OCSP client, addition of a FIPS mode (similar to modutil -fips true -dbdir /path/to/database), options to seed the NSS Random Number Generator, support for Apache 2.2 as well as a number of important bug fixes. Rob, You da MAN! Seriously, I really appreciate the work you (and others?) have done on this! -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certificate Import Question
suckerformimi wrote: I was right-clicking the cert Windows Explorer (file manager) and opening the cert with MS Crypto Shell Extensions. OK, so any information you saw there was of no relevance to mozilla products, including the names of the certs (e.g. SignShot) displayed there. But I was importing and attempting to sign code with the NSS tools. Ok, to do that, you need to import all the following into NSS: a) the private key that corresponds to the public key in your cert b) your public key cert c) Any CA certs between your cert and the root issuing CA, if any. Now, I'm guessing that you enrolled to get your cert using Windows software. So, your private key is in one of Windows' key stores. You need to export all the stuff I listed above into a PKCS12 file (a file with a .p12 or .pfx suffix). Windows' cert manager will happily let you do that. Before doing that, you need to ensure that that the cert you're going to export has a friendly name, using Windows cert manager. When you export it to a pfx file, you need to give the pfx file a password. (Windows Cert manager will let you export it without a password but NSS won't let you import a pfx file without a password). I've imported the certificate into a db in the current folder using NSS certutil -A -n SingShot Object Signing -t TCu,TCu,TCu -d . -i mycert.spc When I do certutil -L -d . I get: SingShot Object Signing CT,C,C myTestCertu,u,Cu The u character means that NSS has the private key that goes with that cert. You can try to set that u flag yourself, (as you did in the above example), but it will have no effect. If you have the private key, then the u will appear, and if you don't, it won't. Should there be a 'u' in the 3rd column for the 'SingShot Object Signing' cert if it's valid for signing code? I suppose that might be the difference between my Thawte and temporary certs. You have to have the private key in order to sign anything, and apparently you don't. So you've imported the cert, but not the private key, You need to import both. Your cert shouldn't need any special trust flags. The argument -t ,, should work just fine, if you've got your issuer CA cert in your cert DB (or in the builtin list of CAs. How can I tell whether my certificate will even work for signing code using NSS tools? Well, once you have the cert AND private key imported, it should work. You're doing a good job of figuring out most of this stuff by yourself, which is commendable. So, keep going and I think soon you'll have it solved. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems importing a certificate
Paul Santapau wrote: Nelson B escribió: All the error codes for TBird's crypto are negative numbers, in the range -6000 .. -12288 and the number 1028 isn't in that range. Ok, good guess ;-). But the number that appears is really 1028 between parenthesis. I can send u an snapshoot if wanted, the only thing is that it is in spanish. Then that number must be a peculiarity of the Spanish localization of Thunderbird. Probably should be reported as a bug. NSS (TBird's crypto code) doesn't presently accept critical Policies extensions. Ok, and just in case some application wants to handle that critical extension, How can the application do it? What kind of check is nedded?. In this case, the application using NSS is Thunderbird. However, NSS's cert validation is not presently application-extensible. Handling of critical policy extensions is planned for NSS 3.12, which should be released (much) later this year. Data: Policy Name: OID.1.3.6.1.4.1.8149.3.5.2.0 Policy Qualifier Name: PKIX User Notice Qualifier Display Text: .C.e.r.t.i.f.i.c.a.d.o. .p.a.r.a. .a.p How did you get the Display Text? Did you used any nss tool?, I have try it with some tools but i cannot get that text, just a stream of unicoded bytes to decode. I used NSS's pretty printing tool, pp. Peter Gutmann's dumpasn1 tool would also do it. (google for it) Thank you very much for solving my issue Nelson. See if your CA will reissue the cert with a non-critical policy extension. If so, that will solve your problem most quickly. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certificate Import Question
Paul wrote: Is it possible that the leaf didn't make it into the db? When I do signtool -d . -k SingShot Media -p mypwd signed/ Yes, except that you have offered one piece of relatively strong evidence to the contrary, namely, that cert chain in your original post. If that cert chain was displayed by mozilla software (e.g. FireFox) then I'd say the cert must be in your cert DB (or else mozilla couldn't have displayed it). If that cert chain was displayed by some other software, e.g. Windows' own cert manager) then yes, it's possible that the cert is not in your cert DB. I get : signtool: the cert SingShot Media does not exist in the database. Did your cert have an email address in it? If so, try substituting that email address for SingShot Media in the signtool command above. Also, how can I check to see whether the cert contains any extensions? You apparently have certutil and signtool, two of NSS's numerous tools. What others do you have? And from what version of NSS do they come? If you have pp and if your SingShot cert is in a binary file, you can try pp -t certificate -i yourfile or if your cert is stored in a base64 encoded ascii file, you can try pp -t certificate -a -i yourfile -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems importing a certificate
Paul Santapau Nebot wrote: I receive the mail on Thunderbird, It says that the message includes a digital signature but there is an unknowed problem giving me at the end the number (1028). Are you sure about that number? All the error codes for TBird's crypto are negative numbers, in the range -6000 .. -12288 and the number 1028 isn't in that range. Is this possible a bug when working with TeletexString and the character @? Not likely. May be another reason? Can, please, anyone take a look to the attached certificate? I have noticed the list filters attachments, the certificate can be found here https://mortadelo.act.uji.es/eujier.der I think the problem is here: Name: Certificate Policies Critical: True NSS (TBird's crypto code) doesn't presently accept critical Policies extensions. Data: Policy Name: OID.1.3.6.1.4.1.8149.3.5.2.0 Policy Qualifier Name: PKIX User Notice Qualifier Display Text: .C.e.r.t.i.f.i.c.a.d.o. .p.a.r.a. .a.p -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: ftps
[EMAIL PROTECTED] wrote: Any plans to support ftp/ssl in Firefox? I think the answer is likely: no-one who frequents this newsgroup/list is planning to do so, but you should check in m.d.t.network. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certificate Import Question
suckerformimi wrote: I can't tell if my certficate imported properly. When I open the certificate it shows me the following certification chain: SingShot Media Thawte Code Signing CA Thawte Premium Server CA Out of curiosity, which tool shows the hierarchy like that, with the root at the bottom and the leaf at the top? When I list the contents of my certificate DB I get Thawte Code Signing CA c,c,C I gather that's the output of certutil -L . Yes? Should I be seeing only the one certificate in the DB, or all three? Shouldn't I at least be seeing our SingShot Media certificate? Ordinarily, certutil doesn't list the contents of the built in root cert module. To include the listing of built-ins, add -h all to your certutil -L command. I think that explains why you didn't see the root in the list. As for why you didn't see the leaf, I'd guess that the cert in question contains one or more critical extensions that are unknown to NSS. It used to be that NSS would not import a cert with unknown critical extensions. Now NSS will import it, but certutil will not display it. :-/ Could also be a consequence of this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=335021 Also, I've searched all over looking for some documentation on certutil and signtool. Is there any around? Start looking here: http://www.mozilla.org/projects/security/pki/nss/tools/index.html Regards, Paul -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Wanted: public https servers that request client auth
Do you know of an https server, directly reachable on the Internet, that requests (and/or requires) SSL/TLS client authentication? That is, one that requests that the client send a certificate to the server identifying the client, during the SSL/TLS handshake? If so, please send me (of this list) the URL of one or more. I'd like ot amass a list of them. Thanks. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS #7
Bruno Boutteau wrote: Nelson B wrote: Bruno Boutteau wrote: How can we import a PKCS #7 certificate or .cer in Firefox? It is easy with IE just click on it and accept the next OKs up to FINISH!!! Thanks in advance (Certificate was delivered on crypto smart card) Thanks for first answer Nelson. In certificate manager U can import your PKCS#12 certificate. In IE Import is able to import X509(.cer,.crt) certificate. Bruno, here's some background information you should know. When you use a certificate that identifies someone else (not you), you only need the certificate. When you use a certificate that identifies you, yourself, you need a certificate AND (most importantly) a PRIVATE KEY. The Private Key is the thing that you (your browser, your email program) uses to prove (to someone else) that you really are the rightful holder of your own certificate. You cannot effectively use your own personal certificate (that identifies you) without also having the private key for it. If you're trying to move your own personal certificate into your browser, you also need to move your private key with it, because your browser cannot do anything effective with your cert unless it also has your private key. You never want to send your private key to anyone else. It's private for you alone. A .der or .cer file contains a single certificate and nothing else. It cannot also contains a private key. It's useful for holding someone else's certificate. It's also useful for sending your certificate (without your private key) to someone else. It's useful for importing someone else's certificate into your browser. A PKCS#7 file is quite different from a .der or .cer file. It can contain any number of certificates, and a few other things, but like a .cer or .der file, it cannot contain any private keys. It is useful for transporting or importing more that one certificate at a time, but (again) you cannot import your private key from it. So, if you're looking to transport your own cert and private key, a PKCS#7 file is not what you want. A PKCS#12 file contains one or more certificates AND (most importantly) a private key. It's the way to transport your own personal cert and your own private key. It also can transport certs related to your cert, such as the cert belonging to the issuer (or authority) who issued your cert. When you go into the certificate manager dialog, there are various tabs shown there for certs belonging to different types of folks. There's a tab for your own personal certs. There's a tag for other people's email certs. There's a tab for SSL server certs, etc. Each tab has an import button that attempts to import a cert for that type of entity. When you attempt to import YOUR PERSONAL cert, certificate manager tries to open a PKCS#12 file (also called a pfx file) to get your cert AND your private key. In that tag, cert manager will only be satisfied with a PKCS#12 file. When you attempt to import someone else's cert, certificate manager does not attempt to open a PKCS#12 file. It attempts to open a file of any of the other types (IIRC), including PKCS7, .cer, .der, etc. Now here are some questions for you to answer. Please answer all these questions: 1. If you have recceived a smart card with your personal certificate and private key on it, why do you want or need to import that cert into your browser? importing a cert is done when your browser has no other way to access your cert. Your browser should quite happily access your cert from your smart card, right where it is, without needing to import it. 2. If this is your own personal cert, why are you trying to import it without also importing the private key. I just want to declare one certificate of my cryto smart card to Firefox Why? When you have a certificate and private key in a smart card, you don't need to declare them or import them at all. FireFox is able to find your certs on your smart card (if it sees the smart card at all, which depends on having the proper software installed) and doesn't need any separate importing to use certs on a smart card. By the way, this is also true for IE. If your smart card software is working properly, and all the necessary software is installed, you don't need to import any certificate files for IE to work, either. (Thunderbird too) but Firefox offers only PKCS#12 format for import and I have the certificate declaration in .cer and with Active Card manager I can make extraction of public information in PKCS#7 or .cer formats, Those formats than Firefox cant read! if I am right. Extracting your certificate (without your private key) into a .der, .cer or PKCS7 file (none of which contain your private key) is (or may be) a useful way to send a copy of your certificate, alone, to someone else. It is not a useful way for you to get your cert and private key into your browser and email programs , because they also need your private key. I suspect your situation
Re: certificate requirements for crypto.signText
Mikolaj Habryn wrote: On Sun, 2006-04-09 at 22:08 -0700, Nelson B wrote: These other functions do not, as a rule, require that the user cert have a chain that verifiably was issued by a locally trusted root. Verifying that the chain leads to a locally trusted root is a function for a relying party, not for a signer. The call chain looks something like nsCrypto::SignText - SEC_PKCS7CreateSignedData - sec_pkcs7_add_signer - CERT_VerifyCert. Is that last call then a bug in all cases? (Presuming of course that _add_signer is only called in signing operations) OK, well there's a pretty major problem right there: nsCrypto::SignText - SEC_PKCS7CreateSignedData PKCS#7 is another name for Cryptographic Message Syntax (CMS) version 1.0. The current IETF standard version of CMS is version 3.0. NSS has two separate implementations of CMS. One, libpkcs7, is about 10 years old, implements CMS 1.0, and has function names beginning with SEC_PKCS7. The other, libsmime, is about 5 years old, with function names starting with NSS_CMS. Libpkcs7 is known to have many problems. In the year 2000, the NSS team decided to rewrite libpkcs7, rather than attempt to fix all the problems with libpkcs7. That is how libsmime came to be written. (libsmime is misnamed, since it implements only CMS, not full SMIME). Libpkcs7 is now completely deprecated. Since the completion of libsmime in year 2001, applications should be using libsmime, rather than waiting for libpkcs7 bugs to be fixed. Sadly, when nsCrypto::SignText was implemented in 2004, the implementor chose to use the older deprecated SEC_PKCS7 API rather than the newer NSS_CMS one. Now, nsCrypto::SignText is demonstrating one of the many known problems with libPKCS7, one that IMO is likely to remain unfixed, given the existence of libSMIME. :-( (d) A local user cert that is not obviously unsuitable on its face (e.g. not expired, not bearing extended key usage extension that prohibits use for signing, etc.) Is there an existing function I should mention in the bug report that does all the above as an alternative to VerifyCert? CERT_FindUserCertsByUsage is one that I had in mind. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: certificate requirements for crypto.signText
Mikolaj Habryn wrote:
Should I take it upon myself to raise this in bugzilla?
Yes. File a bug in bugzilla.mozilla.org. It may get resolved differently
than you hope, but that is the right way to push this to resolution.
I'm not entirely
clear on what the right solution is or even what constraints to
describe; crypto.signText at some point calls a very generic
CERT_VerifyCertificate, which will fail under the described conditions
(no chain back to a root). I presume a good many other certificate
operations take the same path, some of which presumably mandate the
current behaviour.
CERT_VerifyCertificate is a function that is intended for use by the
application when it is acting as a relying party, that is, when it is
using a certificate from someone else, a certificate for which it does
not have the corresponding private key, and it needs to determine the
validity of that cert prior to use, such as when verifying a signature.
crypto.signtext is not such a case. It is not acting as a relying party.
It is performing an act (signing) that presumably will preceed some other
party relying on the certificates used to verify that signature.
(I wonder if there is a term of art for such parties, those who initiate
actions that cause others to become relying parties. For the present,
I will merely call them signers.) While using crypto.signtext, the
application is acting as a signer, not a relying party.
Signers need certs for which the application possesses (or has access to)
the user's private key. In NSS nomenclature, such certs are called
user certs. Signers need access to user certs.
Historically CERT_VerifyCert{ificate} is for use by relying parties, not
by signers. Signers need to find user certs. NSS has a separate set
of functions that exist to find user certs (separate from the set of
functions to Validate certs as a relying party). These other functions
do not, as a rule, require that the user cert have a chain that verifiably
was issued by a locally trusted root. Verifying that the chain leads to
a locally trusted root is a function for a relying party, not for a signer.
I think the bug here simply boils down to crypto.signtext using a
function that is for relying parties, not signers, for selecting a cert
to use for the signing act. That's probably not a big problem to fix.
Which identities should crypto.signText be able to use?
(a) Those for which a CA certificate has been loaded but not trusted?
(b) Any client certificate, regardless of whether or not the signing CA
is known?
(c) Something more exotic, such as (a) above except where the call to
crypto.signText supplies an unknown CA's DN in the ancillary arguments,
in which case any certificates signed by that particular CA are also (or
perhaps exclusively) permitted?
(d) A local user cert that is not obviously unsuitable on its face (e.g.
not expired, not bearing extended key usage extension that prohibits use
for signing, etc.)
Meanwhile what you should be able to do is to mark the CA only as
trusted for email which limits the risks.
Thanks for confirming that.
Odd that crypto.signtext should check for an email cert when it is not
performing email signing or encryption.
--
Nelson B
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to add custom badCertHandler
Kate X wrote: Hi, Now I am kind of stuck at this: We are building application using xpcom components. I am trying to add SSL support for our client, and I am using nsIHttpChannel interface to request a HTTP/HTTPS page. For HTTP works fine, when trying to open HTTPS page, first it will initializeNSS, then try to create secure socket to do transfer, but in handshake stage, certificate didn't get authorized, so it comes to get the badCertHandler, which I don't know how to add my own handler from the very top level(HttpChannel), then it goes to the default dialog UI ask for confirmUnknownIssuer(which I don't want to, this would add too much to our project). Would anybody give me a hint of how to add my custom badCertHandler, or anyother solution for this problem? Using a bad cert handler in that case is almost certainly the wrong thing to do. Defeating the cert chain validation will render your application completely vulnerable to various attacks, the very ones from which SSL (HTTPS) is intended to protect you. Why not use a valid cert from a known issuer? -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Where's mozilla's official CA cert list?
David E. Ross wrote: The policy at http://www.hecker.org/mozilla/ca-certificate-policy also needs to be moved to a mozilla.org or mozilla.com Web page. If this is indeed an official policy of the Mozilla Foundation or Mozilla Corporation, it should no longer be on someone's personal Web site. Bug #333272 addresses the original request, a list of official Mozilla CA certificates. https://bugzilla.mozilla.org/show_bug.cgi?id=333272 Bug #332517 addresses my request for an official publication of the certificate policy. https://bugzilla.mozilla.org/show_bug.cgi?id=332517 Thanks, David! -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Adding Ciphers
Jay Potter wrote: Nelson, We are planning on using a USB device that has keys for various vendors in a private area. The USB device can generate a session key based upon that secret vendor key. The Server can autogenerate that same session key. The session key does not have to be passed. The external module communicates with the USB device. If the device is removed, communication cannot take place. When the module communicates with the USB device, it authenticates that the device belongs to the client, and then and only then will generate the session key for the vendor. There is no authentication requried across the network only to the local USB device, something the client can take with him from machine to machine. Currently I'm thinking of an extenstion to firefox that would be called by the browser when the session key is needed. That extension would provide the interface to the USB device. Jay, you don't need a browser extension. You need a PKCS#11 module. Nothing would be transmitted across the network that can be used to generate the session key. The session key changes without human intervention. The uses only authenticates to the device that he carries with him. He doesn't leave any certificates behind that can be used by anyone else. This seems to be a very secure system that would be very hard to comprimise, as the keys are never on a client machine to intercept, and nothing can be intercepted that can be used to generate or guess at the key. The USB token is already developed. It holds hundreds of unique vendor keys, handles AES-256, generates true random numbers and handles the secure communication required. We are working on the external module, now what we need is the PKS-TLS-AES Cipher. Perfect match for a PKCS#11 module. Plus, given that PKCS#11 is a truly standard API, not specific to any one application (such as a mozilla browser), it will (potentially) work with LOTS of applications. Go check out PKCS#11 (and other PKCS standards) at http://rsasecurity.com/rsalabs/node.asp?id=2124 We are thinking that this shouldn't be to hard to impliment, as the RFC 4279 clienthello and ServerHello are pretty much the same as standard TLS. After that it just passes and identity string back and forth. Then the module would provide the PSK to set up the communication and then it should be on autopilot. Jay -- Nelson B 12345678901234567890123456789012345678901234567890123456789012345678901234567890 0112233445566778 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL/TLS upgrades - RFC2817
Rich Megginson wrote: Nelson B. Bolyard wrote: One more thing: http upgrade is EVIL. :-/ Why? And does that apply to LDAP upgrade as well? Because the recommended way to use TLS with LDAP is to use the startTLS extended operation on the unsecure port to upgrade the connection to TLS. Two issues: 1. RFC 2817 defines two forms of upgrade, optional and mandatory. The optional form never encrypts the request, only the response. So, if the request contains sensitive info, it's been sent in the clear. RFC 2817 provides no guidance (that I saw) as to when an http client should use one or the other. Further, as Julien as made clear, RFC 2817 provides no means by which a URL can tell the browser that for this URL, you MUST do a mandatory upgrade, and if that fails, you must STOP and not continue without ecnryption. So, RFC 2817 is useful only in applications that KNOW that they MUST upgrade or die. I submit that these are special purpose applications, not general purpose browsers. Some might say that RFC 2817 is also useful for opportunistic encryption but I consider that to be useless and a waste of time and CPU cycles. If my application (e.g. online banking) needs protection then it NEEDS protection. An encryption-based protection scheme that provides encryption or not, out of the control of the client, and out of control of the writer of web pages that have the URL/links in them, is a scheme that the user cannot RELY upon to protect him. Ergo, the user should only use it for data that he really doesn't care if it is encrypted or not. Then one asks, why waste precious shared resources (server CPU cycles) on such trivial stuff? 2. mandatory http upgrade and startTLS both seem to have similar properties WRT MITM vulnerability. An MITM need only intervene in a few initial messages - to prevent the server from learning that the client wishes to upgrade/startTLS, and to prevent the client from learning that the server is capable of ugprade/startTLS - to defeat it. Again, if an application, such as an ldaps client or an IMAPS client has been configured to upgrade/startTLS or die, and NEVER fall back to unencrypted communications, then the worst an MITM can do is a DOS attack. And of course we know that no crypto protocol can prevent a DOS attack. So, I see no problem with startTLS in applications like LDAP clients and IMAP clients, which are likely to be (able to be) configured to require that the upgrade/start succeed, or else stop. But for general purpose browsers, clearly one would not want to mandate successful upgrade on every http link, and no other means is defined to tell the browser this is a URL on which successful upgrade is mandatory. 3. A certain popular web server product has the property that the http and https parts of it share a common doc root. By default, if you merely turn on https support on one of their servers, your pages get served equally well with http or https, with or without SSL. Admins of those servers FREQUENTLY forget to take the extra actions to ensure that part of their doc root is accessible ONLY via https. A certain popular browser didn't warn about transitions from https to http. The web page authors tested only with that browser, and no never noticed that some of their links effectively disabled SSL, and after navigating one of those links, the browser would not then return to https. So the web site's web pages got sloppy, and unwittingly included http links in pages that should bear only https links. The web page authors never detected their error because their non-mozilla browsers never alerted them to it. Their users would start out with an https link, and begin to navigate the (bank) web site, and then after navigating it for a while, the user would discover to his horror that somehow his browser had silently stopped using SSL to talk to this server, and his last N pages from that server have had no protection. One of the most common questions we used to get from web site authors who used that particular brand of server was: why do our users who navigate our web site with Netscape/mozilla browsers get warnings about leaving encrypted pages while navigating, but users of other browsers do not? Some of them got pretty irate about these warnings, denying that they had done anything to disable encryption in their web sites. I would explain to those authors that in fact they WERE effectively disabling encryption for their users by going to http links to their pages. I pointed out that mozilla was protecting its users, and the other browser was not protecting its users. In every case, I got a thankful reply from a red-faced web site developer who appreciated being informed that his pages actually were disabling user security. (Search google groups for many occurrences of such interfaces between [EMAIL PROTECTED] and others.) Now, I submit that http upgrade will only make that old problem worse by orders of magnitude. Web site authors
Re: assertion failure in ssl3_config_match_init() when invoking ForceHandshake()
Peter Djalaliev wrote: Hello, I am trying to upgrade a normal HTTP connection to SSL in the Apache mod_nss module. So, You're the source of all those questions I've been getting! ;-) When the mod_nss module is initialized, it calls: - PR_Init - PK11_ConfigurePKCS11 - NSS_Initialize - NSS_SetDomesticPolicy. Also, I can see that 8 ciphers are being set with SSL_CipherPrefSet() Here are the NSS-related function calls that I make: - PR_CreateIOLayerStub return a file descriptor ssl That's a little unusual, but only a little. - SSLImportFD(NULL, ssl) - SSL_HandshakeCallback(...) - SSL_ResetHandshake(ssl, PR_TRUE) Your list of 8 NSS/NSPR functions down to this point doesn't include ANY functions for the configuration of an SSL socket. Well, you did mention SSL_CipherPrefSet(). Perhaps you did not list all the NSS functions called by mod_nss ? and then a loop invoking SSL_ForceHandshake(ssl) that terminates when the SSL handshake callback function has been called. However, when I call SSL_ForceHandshake, I get this assertion failure: in ssl3_config_match_init() in ssl3con.c Assertion failure: numPresent 0 || numEnabled == 0 Does anybody have an idea why this assertion fails? libssl uses replaceable locally configured PKCS#11 modules to do all the crypto. The capabilities of those modules may vary. A user might enable a cipher suite that requires a cryptogrpahic algorithm that is not available (or more precisely, a set of cryptographic algorithms that are not available on the same token). libssl also needs to be correctly configured with certs and private keys. So, in the course of actually setting up all the data to do the work, libssl goes down the list of cipher suits enabled by the application, and checks to see how many of them have all the necessary cryptographic support from the underlying PKCS#11 modules, including certificates, and public and private keys. If it concludes that NONE of the enabled cipher suites has all the crypto support that it needs, then this assertion triggers. That's what happened to you. Given that your list of called NSS functions above didn't include the functions to configure the SSL socket with certs and keys, I'd guess you didn't do that, and so ssl3_config_match_init found no certs and keys for any cipher suites. One more thing: http upgrade is EVIL. :-/ -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: RNG Seeding + Interesting Crash in NSS startup
Nelson B. Bolyard wrote: Among the system files, the best sources of entropy probably come from the files in Temporary Internet Files and the temp directories. I just noticed that I had been reading the code for WinCE, which is rather different from the general Windows code (Win95-WinXP). I'll change the bug I filed to be against NSS for WinCE, and open a new RFE for the rest of windows. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: RNG Seeding + Interesting Crash in NSS startup
RFE for this is now https://bugzilla.mozilla.org/show_bug.cgi?id=331314 Contributions welcome in that RFE. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Where's mozilla's official CA cert list?
Frank, http://www.hecker.org/mozilla/ca-certificate-list says it's an unofficial working document. So, where's the official list of CA certs in mozilla? And where is the official list of certs not in mozilla (with reasons why)? Google showed lots of stuff about policies, and lots of irrelevant stuff, but no official list. /Nelson -- 0112233445566778 12345678901234567890123456789012345678901234567890123456789012345678901234567890 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: list replies? (was Re: Fwd: cacert.org)
Nelson B Bolyard wrote: Kyle Hamilton wrote: (I /hate/ that I have to click 'reply all' to reply to the original poster /and/ the list.) What would you propose instead? Having a Reply-To: header in each message that replies to the alias? or ? The particular MailMan list management software we're using gives me rather few choices in the way of message header munging. I can 1. Insert a prefix in the subject line, e.g. Subject: [dev-tech-crypto] Re: list replies? ^ inserted 2. Replace the email address(es) in From: Sender: and Reply-To: headers with the address of the list itself, anonymizing the messages. (seems undesirable). 3. Make these other Reply-To header choices: a) leave it alone (as the poster created it) [now configured this way.] b) strip it out completely c) replace its contents with a constant string, e.g. with name of list. If there is consensus that a change to these setting is desired, I'm willing. Please discuss it in this list, not in private email to me. Thanks. -- Nelson B (list owner moderator) ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozillas 1.5+ (NSS 3.10?) select wrong certificate for authentication
Martin v. Löwis wrote: So I think it would be best if the browser detected that there is a better-suited certificate (one which doesn't need explicit user interaction); the browser should then also invoke explicit approval if the NR certificate is used even though select automatically was configured (explaining that this specific certificate is a formal signature). That's an interesting idea. Please file an Enhancement request bug in bugzilla.mozilla.org. But I wouldn't expect it to be implemented in the next 6 months, because there's no much work scheduled ahead of it. So in the meantime, get an EKU extension if you can. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to build the NSS cmds on Mac OS X?
ben wrote: Can someone tell me how I can build NSS lib and its utility cmds on Mac OS X? I have downloaded the Mozilla source code and successfully built it on OS X, but checked with the output obj dir, I didn't find the Security/nss was created and built. How I can include the NSS into my build? Have a look at http://www.mozilla.org/build/distribution.html There you will find some text about configuring with --enable-crypto I think that does the trick. Note: followups directed to mozilla.dev.tech.crypto -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: pkcs11 default provider
robert dugal wrote: I want to configure Firefox 1.5 to use my own PKCS11 provider as the default for all algorithms supported by my provider. I cannot appear to do this from the Device Manager dialog as that dialog has no way to set specify which algorithms should default to my library. The NSS utility modutil has the ability to install the p11 provider and configure which algorithms are default. Unfortunately modutil is not distributed with Firefox. When I got the v1.5 source tarball modutil source is there but I cannot get it to build. I tried several different binary releases NSS (3.9, 3.10,3.11) but in all cases modutil only allows specifying some algorithms as the default mechanisms. AES is not one of these so the internal NSS provider always ends up being the default. You found a bug! AES wasn't added to modutil when it was added to everything else in NSS. Please file a bug about this in bugzilla.mozilla.org, product NSS, component tools. And CC me in the bug report. (Remove NO and SPAM from my email address to get the real one) Is there any other way to configure my provider as the default? Are you sure that's really what you want to do? Does your module implement all the SSL-related PKCS#11 mechanisms? If not, it may be necessary to move keys from one module to another, which is typically quite costly (in terms of performance). -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
