http://permalink.gmane.org/gmane.comp.mozilla.crypto hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.mozilla.crypto/16765 <pre> QQ or EMail OK? na2650945&lt; at &gt;163.com </pre> chu wang 2012-05-14T12:19:33 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16764 <pre>I really don't understand what you are speaking. I'm in Beijing , so could you give me your cell phone number? If so, I will call you later. On 05/14/2012 01:38 PM, chu wang wrote: </pre> wdeng 2012-05-14T08:47:20 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16763 <pre>Yesterday thoughts: Some policies say "Before signing, a preview of what is going to be signed must be shown to the user". If we use something like: signedData=sign(key,dataToBeSigned) this could show, for example, a pdf preview of what is being signed. I love that idea, but what if i actually want to sign a bunch of documents? for(i=0;iz10;i++){ signedData=sign(key,dataToBeSigned[i]) } will show 10 previews, and thats horrible. What about using another API instead? signInit(key) //key to sign signAdd(data) //one call for each document to be signed in this block signFinal() //show a single preview for all documents in this block and do signing (of approved/selected) there could be also a sign wrapper like: sign(key,data){ signInit(key) signAdd(data) signFinel() //preview &amp; sign } BTW: i also realized that server signature validation requires public key, so privacy issues relating public key are impossible to avoid. Open to</pre> helpcrypto helpcrypto 2012-05-14T06:53:49 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16762 <pre>Hi all. I want to by the NSS calls the P11 module. So I have some quessions. 1.PKCS #11 Conformance Testing where download. 2.How to compile NSS,Which have detailed guidance document? 3.Other browsers, such as chorme also supports NAPI, how to call the P11, but also through the NSS? 4.What are the advantages of the NSS call P11 NPAPI? Thanks. Firefox Chinese little information. If there is something wrong, please forgive me. </pre> chu wang 2012-05-14T05:38:14 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16760 <pre> Nelson is right. I looked into a check we added recently for 3). It was added in NSS 3.12.7: https://bugzilla.mozilla.org/show_bug.cgi?id=554354 Since you're using NSS 3.12.5.0, that makes 3) less likely, but still possible. Yes. To track this down, we need the server's certificate chain and the "Server Key Exchange" handshake message, if it is used. Wan-Teh </pre> Wan-Teh Chang 2012-05-09T17:43:01 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16759 <pre> Bernhard, I think the most likely explanations are these: 1) Server certificate has a public key that is too small, too large, has a too small public exponent (if RSA), an unknown key type, or a key for an Elliptic Curve that is not supported by NSS. 2) Some other certificate in the server's cert chain has one of the above problems. 3) The server is attempting to use "Server Key Exchange" for forward secrecy, and the key it is offering for that purpose has one of the problems mentioned above. 4) The server is selecting a cipher suite that is incompatible with the type of key in its public key certificate. Ii suggest you use tcpdump or ssltap to get a trace of your own. Regards, /Nelson </pre> Nelson B Bolyard 2012-05-09T02:33:40 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16758 <pre>Hi, Wan-Teh Chang schrieb (07.05.2012 20:39 Uhr): Is there anyone who can say for sure, if this is true or not? Is there a better place to ask? In Firefox it should work this way, according to http://mike.kaply.com/2012/03/30/customizing-firefox-default-profiles/ "If you add additional files into this directory, those files are copied into the default profile along with the rest of the files. This is most commonly used if you want to have default certificate databases. I’ve seen cases where someone started Firefox, added the certificates and certificates authorities they needed and then copied the various *.db profiles from their profile and put them in the default profile so all their users would get them." Marc </pre> Marc Patermann 2012-05-08T13:22:19 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16757 <pre>Hi experts, an OpenAM community member is using OpenAM policy agent to connect to an ssl-secured server. The policy agent uses NSPR 4.8.2, NSS 3.12.5.0 optimized build for Linux (RHEL) 64bit. If the agent tries to open a connection to a specific, ssl-enabled OpenAM server, error '-8152' is raised. What might be the root-cause for this error? Could I get some additional output from an optimized build or do I really need a 'DEBUG' build to leverage NSS environment variables (https://developer.mozilla.org/en/NSS_reference/NSS_environment_variables)? Interestingly the same agent can connect to other ssl-enabled servers. Unfortunately the community member will / can not provide a network trace showing the handshake messages. TIA, Bernhard </pre> Bernhard Thalmayr 2012-05-08T11:53:45 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16756 <pre> Any comments? </pre> helpcrypto helpcrypto 2012-05-08T07:34:16 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16755 <pre>On Mon, May 7, 2012 at 9:20 AM, Marc Patermann &lt;hans.moser&lt; at &gt;ofd-z.niedersachsen.de&gt; wrote: Hi Marc, Perhaps the cert8.db file in defaults/profile in the program directory is not being used by Mozilla programs? If that's true, then I'm afraid that you will need to add your CA to every profile, rather than relying on defaults/profile in the program directory. Wan-Teh </pre> Wan-Teh Chang 2012-05-07T18:39:53 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16754 <pre>Hi, I posted my issue on Thunderbird-Enterprise before and Ludovic Hirlimann sent me here. I created an own CA and put the cert in cert8.db by GUI in Thunderbird 10 ESR. As far as I understand it, the way to go is to put the corresponding cert8.db file in defaults/profile in the program directory. (Which works for mimetypes.rdf.) For what I tested it does not work. On a blank profile cert8.db is always the original file, my CA is never included. If I copy back cert8.db by hand, the CA is in there. So the file itself is fine, but it seams to be never used. What did I do wrong? Marc </pre> Marc Patermann 2012-05-07T16:20:13 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16753 <pre> On Thu, Apr 26, 2012 at 12:32 AM, helpcrypto helpcrypto &lt;helpcrypto&lt; at &gt;gmail.com&gt; wrote: I observe that yes, this is "base64 encoding the data to be signed before the signature is created". Huh. Someone who thinks like I do. This information has value, thus this information must be protected. Fortunately, I have something for that. Behold: the Identity Escrow Agent. This is a certifier who would take { your full certificate, a new public key }, the set signed with both asserted keys (axiomatic binding), then create a certificate around the new public key which says "I know who this is, but I shall not tell anyone except legitimate state authority." The idea is that site owners would be able to start requiring this kind of certificate, so that they can hold spammers and vandals accountable -- without becoming private information trustees and becoming subject to various states' felonization of handling personal information with less than PCI 2.0 controls. This is a use which is far less</pre> Kyle Hamilton 2012-05-04T06:05:15 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16752 <pre> On Thu, May 3, 2012 at 4:27 PM, Wan-Teh Chang &lt;wtc&lt; at &gt;google.com&gt; wrote: GenerateKeyPair(purpose:keyEncryption) GenerateKeyPair(purpose:Signature) I think this is due to France, and legacy requirements for different caps on encryption versus signature key strengths. I don't know if these are still concerns. This is not correct for EC. To do PKEncrypt there, you must have both the source private key and destination public key available to perform ECDH key agreement. Then, put that agreed value through a key derivation function (digest), and finally symmetrically encrypt the random message symkey with the derived symkey. There is no reversible transform from something which can be calculated solely from the public key, unlike RSA. Please implement RSA and DSA with a second, null parameter, so that this use can be enabled for EC. ALGORITHM_ECDSA should be in there as well. However, I do not agree with the idea of enumerating algorithms and modes separately. Down that path lies ECB a</pre> Kyle Hamilton 2012-05-04T05:45:00 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16751 <pre> Bob, Thank you!!! You are right. I'm faking the dynamic memory allocation with a static one and with some other tweaks. Ofcourse, I've modified mpi as well to get this work. I am using the data allocation. I will start working on this and get back to you. Regards, Vejey </pre> VJ 2012-05-04T05:48:05 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16750 <pre>David, I'll go into my vision of what I aspire to ("The Truly Universal PKI") in another message. Why I focus on what I do may become clearer then. tl;dr: 1. CMS is the primary motivator for BER indefinite reading, if not writing/digesting. 2. To prevent ECB and non-KDF key agreement, enumerate values for { algorithm, mode } and { keyAgreement, derivationFunction } tuples. This will prevent naive implementations of ECB and non-KDF key agreement in JavaScript or other clients. 3. Never allow non-Mozilla-implemented digest objects to provide any digest value for a signature, without a preference. 4. I wish for a truly expansive and comprehensive API. 5. Instead of defaults, perhaps allow the author to ask for a specific type of algorithm and a minimum strength, using lower-case type codes and bit-strength numbers. -Kyle H On Fri, Apr 20, 2012 at 8:40 PM, David Dahl &lt;ddahl&lt; at &gt;mozilla.com&gt; wrote: Aside from CMS (RFC5652), https://en.wikipedia.org/wiki/CAdES_%28computing%29 , a set of extension</pre> Kyle Hamilton 2012-05-04T05:12:13 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16749 <pre> On Thu, Apr 26, 2012 at 12:32 AM, helpcrypto helpcrypto &lt;helpcrypto&lt; at &gt;gmail.com&gt; wrote: This is what the unique tags on ASN.1 UTF8String and IA5String and PrintableString and Shift-JIS and such are for, specifying the encoding. The certificate is not the public key. The public key is the only identity the computer can comprehend, and the certificate is metadata about the key which is (ideally) trusted for fiduciary work. The public key itself is its own identity as well, so your point doesn't even rely on having a unique hash. But! Here's someone who actually thinks like I do, that this information has value, and therefore this information must be protected. Fortunately, I have something for that. Behold: the Identity Trustee. This is a certifier which would accept your current certificate and a newly generated public key, both signed by both the certified keypair and the generated keypair. It would then sign a certificate for the generated public key which says, basically, "I know who </pre> Kyle Hamilton 2012-05-04T05:12:13 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16748 <pre>David, Here are my review comments on https://wiki.mozilla.org/DOMCryptInternalAPI: 1. I don't understand the difference between the two methods that generate key pairs: PKGenerateKeyPair SigGenerateKeyPair 2. PKEncrypt just need a public key, not a key pair. 3. I suggest not assigning 0 to any algorithm enumerator. This allows the use of 0 as an invalid value. We can't use -1 because the type is unsigned long. So ALGORITHM_RSA should be 1 and ALGORITHM_DSA should be 2. 4. Like PKDecrypt, Sign just needs aKeyID, which represents a private key. 5. Verify should take a public key. 6. The second arguments of Sign and Verify should have the same name (because the refer to the same thing) and the name should not imply it is encrypted (such as aPlaintext and aClearBytes). You can use 'message' as the argument name. 7. When verifying a MAC, the byte comparison must be constant time to avoid leaking timing info. Leaking timing info of MAC verification could be problematic in some situations. Thi</pre> Wan-Teh Chang 2012-05-03T23:27:07 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16747 <pre>This seems surprising with out modifying mpi. The underlying mpi code assumes that it can allocate data, so unless you are faking it out with some sort of manual allocator, I don't see how you can even get a basic RSA op to work. If you are trying to decode this in an enviroment that can't allocate data, you are in for some difficulty. To decode the above you need: 1) a base64 decoder, and 2) an asn1/der decoder. There are some internal NSS templates to do this (as least the der part). Of course if you can't allocate, non of the NSS decoders would work for you (The simplest requires NSPR arenas). Anyway the path forward is to do a base64 decode on the above data (you have to strip the ---- XXXXX----- portions yourself. The function you want is ATOB, so either ATOB_convertAsciiToItem or ATOB_AsciiToData() (defined in base64.h). Once you have the binary you want to decode the DER value. You can see some samples in mozilla/security/nss/lib/softoken/legacydb/keydb.c. The function seckey_decrypt_pr</pre> Robert Relyea 2012-05-02T16:21:59 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16746 <pre>+2! On Sat, Apr 28, 2012 at 8:13 PM, Robert Townley &lt;fosscoder&lt; at &gt;gmail.com&gt; wrote: </pre> helpcrypto helpcrypto 2012-05-02T06:58:53 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16745 <pre> On Tuesday, 1 May 2012 00:46:21 UTC+8, Robert Relyea wrote: Hi Bob, I'm extracting private interfaces for RSA functions compatible for our own VM, with our own instruction sets. Even, Dynamic memory allocation cannot work there. I've tested these low level functionality for RSA. Now, Is there a way to get the above keys - stripped and make it work in low level? Is it feasible? or I should consider doing something else? Thanks, Vejey </pre> VJ 2012-05-01T19:01:33 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16744 <pre> +1 </pre> Robert Townley 2012-04-28T18:13:37 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.mozilla.crypto