Re: UTF8 support in the Firefox certificate store?
Paul Hoffman wrote: I have created a X.509 v3 client certificate using OpenSSL. The CN and OU field contain UTF8 characters, in this case Thai characters for testing purposes. Are those fields encoded with UTF8String as they should be? Exactly, that's the crucial question. Chances are very high that the CN and OU attributes are encoded as TeletexStrings/T61Strings - which means that this is probably another manifestation of https://bugzilla.mozilla.org/show_bug.cgi?id=458745. Michael, try adding string_mask = MASK:0x2002 to your OpenSSL config file and recreate the certificate - this will most likely fix your problem for Firefox (with the exception of the title bar display). Kaspar ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging
On 12/03/2008 07:09 PM, Nelson B Bolyard: Kaspar Brand wrote, On 2008-12-03 08:36 PST: http://sni.velox.ch/httpd-2.2.x-sni.patch is working pretty well for 2.2, though (have a look at https://sni.velox.ch). Kaspar, Thank you for building and maintaining that web site. It is the ONLY web site known to me that implements SNI. I use it from time to time for testing the client-side SNI in NSS. I appreciate your leadership in this area, and your contributions to Mozilla. I wonder if mod_nss supports SNI the same way the patched mod_ssl version does. I knew about mod_gnutls did, but since there were other issues with it, I never went for it... I took the opportunity to blog about SNI and (shamelessly promoting) our patched SNI capable packages. The post includes a test case as well: https://blog.startcom.org/?p=131 -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Anders' p2 challenge
Given this example, and using traditional technologies and protocols, this problem appears intractable. However, there is a new solution - becoming an OASIS standard shortly - that not only solves this problem, but goes beyond this stage of the problem to address the next stage of the problem. Everybody on this forum understands that when this Purchase Order is sent encrypted, it has to be encrypted with a symmetric key, and the symmetric key has to be encrypted with the public key of the receiver(s) and packaged with the ciphertext PO (ala S/MIME). However, there is no current standard to do this with groups - just individuals. But, if the symmetric key is abstracted out of the package and an infrastructure exists to support its secure distribution on the internet, the problem is solved. The infrastructure I speak of is a Symmetric Key Management System (SKMS). It is part of an Enterprise Key Management Infrastructure (EKMI), which includes a PKI. While the Purchasing problem is not very complex, lets run with it to continue the thread: a) When a Purchasing Manager (PM) wants to send an encrypted/signed PO to a vendor's Order Receiving System, the vendor issues the PM a signing and an encryption certificate from the vendor's EKMI. b) After the PM prepares the PO, they sign it with their company issued digital certificate, and then using the vendor-issued signing certificate, request a symmetric key from the vendor's EKMI; c) The vendor's SKMS, validates the request based on the signature and cert-chain, and issues a symmetric key based on policies defined by the vendor in the SKMS; the key is transported after being encrypted under the vendor-issued encryption certificate to the PM; d) The PM receives the key, verifies the response, encrypts the PO (into an XML Encryption-schema conformant document) and sends it off to the vendor's ORS; the PM erases the symmetric key from their system when done - they don't need it anymore; e) Vendor's ORS is configured with its own pair of certificates from the SKMS. When it receives the encrypted PO, it requests the same symmetric key from the SKMS; the SKMS had escrowed it even before sending it to the PM; the ORS knows the key-identifier because it is embedded in the XMLEncryption document; f) SKMS recieves request; based on access-control rules, it returns the symmetric key to the ORS, which now decrypts the signed PO sends it off to the Order Receiving Group alias. Any receiver on the vendor's side can now verify the signed PO and process the PO. An alternate approach is to have the XMLEncryption document go to all the Order Receiver's on the vendor's side. When the receiver is ready to process the PO, they request the symmetric key from their SKMS, and after receiving the key based on their signed request and access control rules, decrypt the PO and continue processing it. Using S/MIME-like design, but abstracting the key out of the encrypted document, this problem - and another more complex problem as shown in slides 15-17 of this 18-month old presentation: http://www.oasis-open.org/committees/download.php/24594/ekmi-webinar.pdf is solved. (Using the purchasing system example, it would be analogous to the order receivers being able to share the encrypted PO dynamically with a select sub-group out of a group hundreds of thousands of parts suppliers to the vendor). Arshad Noor StrongAuth, Inc. Anders wrote: When any of you guys have made a *public* write-up on how you would address the [related] issues mentioned on p.2 in this document http://webpki.org/papers/web/A.R.AppliedPKI-Lesson-1.pdf you are ready for the real discussion. 1. How is the purchaser (P) going to select and acquire a suitable Order Receiver (OR) encryption certificate from the selling organization? 2. How is the buying organization’s Purchasing System Server (PSS) able to perform its logging, authorization, and control tasks if purchase orders already have been encrypted by the Purchaser using a public key from an external selling organization? 3. How is the selling organization’s Order System Server (OSS) supposed to decipher and validate incoming orders if they are encrypted by a public key of a specific Order Receiver (ORn) employee? In case the designated OR is unavailable, how is OSS going to be able to delegate order handling to another OR? 4. How are different Order Receivers (ORs) supposed to cooperate if they cannot see each others’ tasks? Are the particular Order Receiver and Purchaser also the natural entities for handling associated invoices? I know that there is not a single person on this planet who can :-) ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging
Nelson B Bolyard wrote: (Snipped. Your interpretation is not inaccurate but isn't where we are heading.) I think this list is NOT the place for the debate over the superiority of open vs. closed source software. This is the open source locker room, not the open/closed source battle field. Agreed, all. Now, if the discussion can be steered to how Mozilla's crypto can succeed at becoming as popular as Skype may be, WITHOUT it having to resort to - closed source, Indeed, if we look at Skype's closed source, it isn't really an advantage to them in security or popularity terms, only in competition, which doesn't interest us here, so much. - proprietary designs (restricted intellectual property), Sure, I concur with that, for the same reasons as open source. - being a closed system with no interoperability, that may be worthwhile for this forum, IMO. This may be an issue, but let's see how it develops. My issue is not one of source, open v. closed, but one of: standards v. non-standards. Before we get to that, let's see how the open source thing works and see if we have an agreement on that. Open source leads to interoperability and the ability for any number of players to play in the market. This counterbalances the economies of scale in IT, and holds back the dominant players -- Microsoft -- by ensuring there is a steady series of small ideas from small players. Because it is *our net* we also feel good about these things, which has a very important side-effect: people want to contribute and they want to download when the product is open. That's Mozilla's space place; agreed? And, we are probably agreed that open source is better for security [1] so I'll assume that too. Now, there is a side-effect of the interoperability argument that creates a need for *standards*. Simply put, so that all can play, the new successful technology needs to be turned into a standard. The problem with this is that it slows down any change. Indeed, by some lights it may make change impossible, or reduce it to only trivial or inoffensive things [2]. What's the problem with that? Well, it might be that slowness is the price of open source and interoperability, combined, and for general purpose open source we might accept that price. The IETF is the expression of our acceptance of the price, in the net. However, there is one exception to that where it isn't so rosy: security. For this, let me leap across to Boyd's OODA model. In Boyd's world of observe-orient-decide-act, he modelled combat between adversaries. This happens to match security; we have the defenders and attackers. OODA is a loop; what he presents as one for each: one adversary goes through OODA, the other does too, again the first, again the other each time bettering their position w.r.t. last round, each time trying to out-do the other. Here's the punchline: the one who can turn faster wins. The one who can turn inside the other guy's OODA (this metaphor is taken from the old fighter combat days of Spitfires v. Messerschmitt 109s) is the one that gains more each time, and eventually wins [3]. We can measure the times that defender and attacker can turn their OODA loops . Suffice to say, in the internet world of security, the attacker turns in his loop around much faster than the defender. To the extent that this model applies, the difference is so severe in some areas that it is game over. Assuming a real combat as opposed to a parade ground review, the attackers will turn their OODA loop faster, much faster, and win. Examples are spam, phishing, viruses, malware, etc; as soon as a defence comes out, the attacker has turned inside and attacked us from elsewhere. Proof? When was the last time that you heard of one of these things going down in volume/losses? Why is this? Well, one reason is that the defender OODA loop is simply larger. If it includes extra nodes, then it takes time to travel all the nodes. E.g., anti-virus has to include the OS, and PKI has to include the standards body [4], and a bug fix has to include the user-update effort. The entire loop must then be slower, even if we know everyone is working at the same speed. Why doesn't this matter in general purpose open source? Because outside security, we have an absence of active attacker and an absence of real losses. When Firefox blows up, the user restarts, switches browser or even files a bug. Only slight losses of time patience there. Also, when an Internet security system is breached by an active attacker, the value that can be lost could be an entire bank account [5]. In general purpose software failures, there isn't an attacker that turns faster, and takes more of our money when he wins. In summary, there is no disagreement between open source and general internet software. But there is a clash between security and standards [6]. Standards slow down
Re: SECOM Trust EV root inclusion request
On Saturday 06 December 2008 06:33:13 Frank Hecker wrote: snip * SECOM Trust doesn't currently support OCSP. OCSP is not (yet) mandatory for EV, so this is not an issue from a policy perspective. IIRC this will not pose a technical problem either, as long as EV certs issued by SECOM Trust don't have an AIA extension with OCSP URL. That assumes that https://bugzilla.mozilla.org/show_bug.cgi?id=413997 will not be implemented before such time as SECOM Trust do start to support OCSP. * SECOM Trust had one caveat on their EV audit, having to do with their not performing certain background checks on staff. As noted in Kathleen Wilson's summary document (attached to the bug), this is apparently a side-effect of Japanese laws and regulations, and not a substantive problem. I suggest reading Kathleen's summary document to get an overview of this request; thanks again to Kathleen for preparing these! For this request and subsequent requests I'm going to adopt a suggestion made by Eddy a little while back: Rather than having a two-week discussion period divided into two phases, I'm going to have a single one-week discussion period. After that week, if there are no outstanding issues relating to the request then I am going to go ahead and officially approve it. However if there are outstanding issues that in my opinion are relevant, then I'm going to postpone further consideration of the request. This will allow time to try to get the issues resolved, after which we can start a new public discussion period. Frank -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
