Re: Words from Comodo?
On Monday 29 December 2008 13:50:58 Eddy Nigg wrote: There is now an interest article at the register: http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/ snip Interesting that Comodo founded the CAB forum and Comodo created a standard for domain control validation. I wonder where exactly? This might be reason to join the CAB forum? Eddy, assuming Startcom meets the CABForum's membership requirements (see http://www.cabforum.org/forum.html), I would definitely encourage you to apply to join. This would allow you to contribute to the minimum standards for domain validation initiative mentioned by that Reg article. -- 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
Re: MD5 irretrievably broken
On Tuesday 30 December 2008 22:07:08 Kyle Hamilton wrote: I would suggest requiring all new roots approved to state that they do not and will not use MD5 in any newly-minted certificate (except possibly in a configuration like the TLS pseudo-random function). FWIW, Comodo have never signed (and we will never sign) any certificates with MD2, MD4 or MD5. Also, since we launched our CA business, we've always generated random certificate serial numbers. This is not yet policy, though it should be. (FWIW, this was known two years ago.) -Kyle H On Tue, Dec 30, 2008 at 8:39 AM, Chris Hills c...@chaz6.com wrote: A presentation was given at this year's Chaos Communication Congress in which it was described how researchers were apparently able to produce authentic signed SSL certificates thanks to a handful of CAs who rely on MD5. If true, is it time to disable MD5 by default? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- 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
Re: Words from Comodo?
On Tuesday 30 December 2008 22:22:11 Gervase Markham wrote: Ian G wrote: As far as I heard, the CABForum was also formed or inspired from a similar group of vendors (browsers) that got together at the invite of the Konqueror guy to talk about phishing one day ... I'm fairly sure it wasn't at the invitation of the Konqueror guy (George Staikos), but a CA-led initiative right at the very beginning. But my memory could be failing me, or there could have been meetings I didn't know about. Gerv, your memory is correct. Comodo instigated and hosted an Industry Round Table on May 17th 2005, inviting various CAs and Browser reps to attend. This meeting led directly to the formation of the CABForum. Comodo's intention was to stop the race to the bottom and to restore the value of the browser padlock by creating an industry standard for IV/OV and by persuading the browsers to differentiate between DV and IV/OV. (I just tried to post this same message with a PDF attachment containing the invitation to the Industry Round Table, but it appears that that message was blocked). Question for now: is the CABForum still a closed group? Depends what you mean by 'closed'. There are membership criteria, and anyone who fits the criteria can be a member. See the bottom of this page: http://www.cabforum.org/forum.html Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- 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
RE: How do I get the certificates out of the builtin object token?
Ahh...I did it from my Vista workstation's firefox profile which I knew had the roots module added. Nssckbi.dll or libnssckbi.so or whatever it is on a Mac is a special PKCS#11 module that is read-only and contains the trust anchors. By default with an NSS database, it's not added. You can add it yourself to a new or existing db using modutil. mbn ~ # mkdir nss mbn ~ # cd nss/ mbn nss # nsscertutil -N -d . Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character. Enter new password: Re-enter password: mbn nss # nssmodutil -list -dbdir . Listing of PKCS #11 Modules --- 1. NSS Internal PKCS #11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB --- mbn nss # nssmodutil -add roots -libfile /usr/lib64/nss/libnssckbi.so -dbdir . WARNING: Performing this operation while the browser is running could cause corruption of your security databases. If the browser is currently running, you should exit browser before continuing this operation. Type 'q enter' to abort, or enter to continue: Module roots added to database. mbn nss # nssmodutil -list -dbdir . Listing of PKCS #11 Modules --- 1. NSS Internal PKCS #11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB 2. roots library name: /usr/lib64/nss/libnssckbi.so slots: 1 slot attached status: loaded slot: NSS Builtin Objects token: Builtin Object Token --- mbn nss # nsscertutil -L -d . -h all Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Builtin Object Token:Verisign/RSA Secure Server CA CG,C, Builtin Object Token:GTE CyberTrust Root CA CG,C,C Builtin Object Token:GTE CyberTrust Global Root CG,C,C snip you get the point (BTW, ignore the nss prepended to the beginning of all the commands, I filed a bug with Gentoo a while back to have the NSS command-line utils be built by default and they didn't want a binary called digest laying around among others so they prepend nss before all the commands.) At this point you can follow my previous directions. Sorry I didn't explicitly mention this piece earlier. Good luck, Dave -Original Message- That doesn't give me the list of nicknames in the Builtin Object Token, that just gives me the list of nicknames in the softtoken. (I doubt that nssckbi is supposed to include this...) KyleMac:.netscape kyanha$ certutil -L -d . -h Builtin Object Token [...] StartCom Free Certificate Member's StartCom Ltd. ID u,u,u [...] Notably, modutil -list gives me this: --- 1. NSS Internal PKCS #11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB --- It does this regardless of whether I have libnssckbi.dylib (I'm on Mac OS X Leopard 10.5.6) in the profile directory. It also does this regardless of whether I have all of Firefox.app/Contents/MacOS/*.dylib in the profile directory. And it especially does this even when I'm in the profile directory. The version of nss I'm using is @3.11.9 (net), provided by darwinports. -Kyle H ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
RE: symmetric key issues with NSS 3.12
-Original Message- From: On Behalf Of Nelson B Bolyard Sent: Tuesday, December 30, 2008 2:25 PM Attempting to create a 128 byte (1024 bit) aes key on the token: C:\nss\fipssymkeyutil -K -n aesKey3 -t aes -s 128 -d . Enter Password or Pin for NSS FIPS 140-2 Certificate DB: aesKey3 128 1024 aes restricted AES has 1024 bit keys? Yea, about that. The first couple times I used symkeyutil to create the keys I didn't realize it was asking for the strength in bytes so when I put 128 I was getting 1024 bit keys. If it makes you feel any better when I tried to actually use it in Java (before I realized what I had done), I got a CKR_HOST_MEM error or something like that so It definitely didn't work. I'll file a bug against NSS 3.12, thanks for looking at this Nelson. Dave ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How do I get the certificates out of the builtin object token?
KyleMac:.netscape kyanha$ modutil -add roots -libfile /Applications/Firefox.app/Contents/MacOS/libnssckbi.dylib -dbdir . WARNING: Performing this operation while the browser is running could cause corruption of your security databases. If the browser is currently running, you should exit browser before continuing this operation. Type 'q enter' to abort, or enter to continue: Using database directory ERROR: Failed to add module roots. Probable cause : Unknown error: -2804. KyleMac:.netscape kyanha$ (The architecture is 'i386' on all of modutil, certutil, and libnssckbi.dylib.) -Kyle H On Wed, Dec 31, 2008 at 4:48 AM, David Stutzman dstutz...@dsci.com wrote: Ahh...I did it from my Vista workstation's firefox profile which I knew had the roots module added. Nssckbi.dll or libnssckbi.so or whatever it is on a Mac is a special PKCS#11 module that is read-only and contains the trust anchors. By default with an NSS database, it's not added. You can add it yourself to a new or existing db using modutil. mbn ~ # mkdir nss mbn ~ # cd nss/ mbn nss # nsscertutil -N -d . Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character. Enter new password: Re-enter password: mbn nss # nssmodutil -list -dbdir . Listing of PKCS #11 Modules --- 1. NSS Internal PKCS #11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB --- mbn nss # nssmodutil -add roots -libfile /usr/lib64/nss/libnssckbi.so -dbdir . WARNING: Performing this operation while the browser is running could cause corruption of your security databases. If the browser is currently running, you should exit browser before continuing this operation. Type 'q enter' to abort, or enter to continue: Module roots added to database. mbn nss # nssmodutil -list -dbdir . Listing of PKCS #11 Modules --- 1. NSS Internal PKCS #11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB 2. roots library name: /usr/lib64/nss/libnssckbi.so slots: 1 slot attached status: loaded slot: NSS Builtin Objects token: Builtin Object Token --- mbn nss # nsscertutil -L -d . -h all Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Builtin Object Token:Verisign/RSA Secure Server CA CG,C, Builtin Object Token:GTE CyberTrust Root CA CG,C,C Builtin Object Token:GTE CyberTrust Global Root CG,C,C snip you get the point (BTW, ignore the nss prepended to the beginning of all the commands, I filed a bug with Gentoo a while back to have the NSS command-line utils be built by default and they didn't want a binary called digest laying around among others so they prepend nss before all the commands.) At this point you can follow my previous directions. Sorry I didn't explicitly mention this piece earlier. Good luck, Dave -Original Message- That doesn't give me the list of nicknames in the Builtin Object Token, that just gives me the list of nicknames in the softtoken. (I doubt that nssckbi is supposed to include this...) KyleMac:.netscape kyanha$ certutil -L -d . -h Builtin Object Token [...] StartCom Free Certificate Member's StartCom Ltd. ID u,u,u [...] Notably, modutil -list gives me this: --- 1. NSS Internal PKCS #11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB --- It does this regardless of whether I have libnssckbi.dylib (I'm on Mac OS X Leopard 10.5.6) in the profile directory. It also does this regardless of whether I have all of Firefox.app/Contents/MacOS/*.dylib in the profile directory. And it especially does this even when I'm in the profile directory. The version of nss I'm using is @3.11.9 (net), provided by darwinports. -Kyle H ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org
Re: PositiveSSL is not valid for browsers
Eddy Nigg wrote: perhaps Mozilla should start to use EV certs for the update mechanism of Firefox and *enforce* it? There might be many other sites which potentially could wreak havoc not measurable in terms of money only. Perhaps we should. Can you file a bug about this, please? There may be technical or procedural issues which make it less than trivial, but filing a bug is the best way to find out what they are. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PositiveSSL is not valid for browsers
Kyle Hamilton wrote: Hmmm... actually, it would be possible, but only with the cooperation of the CAs. We currently know the EV policy OIDs for EV-enabled roots. What we don't know is the policy OIDs assigned for different types of validation, ...nor do we have, more to the point, a concrete definition of what should qualify as 'OV'. Each CA does things differently. That's why EV was created - to provide a minimum, defined, auditable standard of checking for purchaser identity. Saying browsers need to differentiate DV from OV is basically saying we need to do the entire EV process again, but setting a lower bar. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PositiveSSL is not valid for browsers
On 31/12/08 15:38, Gervase Markham wrote: Eddy Nigg wrote: perhaps Mozilla should start to use EV certs for the update mechanism of Firefox and *enforce* it? There might be many other sites which potentially could wreak havoc not measurable in terms of money only. Perhaps we should. Can you file a bug about this, please? There may be technical or procedural issues which make it less than trivial, but filing a bug is the best way to find out what they are. Hmmm, odd that Frank views EV as ecommerce and here we see another view of EV as technical delivery of updates. As the update mechanism is an integral part of the software, it is somewhat obscure to me why a consumer branded product like EV would have anything to do with the technical delivery of updates? (Ah, I suppose this is discussion for the bug...) iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PositiveSSL is not valid for browsers
On 12/31/2008 04:36 PM, Gervase Markham: Kyle Hamilton wrote: Hmmm... actually, it would be possible, but only with the cooperation of the CAs. We currently know the EV policy OIDs for EV-enabled roots. What we don't know is the policy OIDs assigned for different types of validation, ...nor do we have, more to the point, a concrete definition of what should qualify as 'OV'. Each CA does things differently. That's why EV was created - to provide a minimum, defined, auditable standard of checking for purchaser identity. Saying browsers need to differentiate DV from OV is basically saying we need to do the entire EV process again, but setting a lower bar. Yes, basically we need a class or type in between DV and EV, preferable defining DV clearly as well. EV is clearly maximum, whereas DV is clearly minimum. There is a middle ground ignored which is bad. There are organizations which can't be validated according to EV, they would certainly benefit from it. Besides that, I believe there is also a need for IV. From my experience there are many subscribers which don't need, want or can do EV, but nevertheless want something more than DV. The same is for the relying parties. We don't need to redefine EV, but add another class (even if you are very proud of EV). :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org 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: PositiveSSL is not valid for browsers
On 31/12/08 01:31, Ben Bucksch wrote: On 30.12.2008 23:34, Kyle Hamilton wrote: That difference /can/ be communicated to the end-user, unobtrusively. Sure, but they can't use that information. I just asked a friend whether she knows what VeriSign is - she never heard of it. If you have no concept about how all that works, no idea what a MITM attack is, how can you make a decent decision? Right. She doesn't know what Verisign is because the browser won't let Verisign brand itself to her. I guess it would be different if Verisign were a search engine :P but we are in the department of the central URL bar, not the right-hand search bar. Besides, the amount of colors we can use is limited. ;-) Um, countries and flags say different. Favicons say different. Corporate logos say different :-) We'd be happy if people would even check the domain name in the URLbar and the lock icon! Most people here were surprised to learn that Comodo has 7000 resellers They do? Nice for them. Where is this disclosed? How many certs are they selling? If the Danish group were indicative we are looking at around 700k. - how is a user supposed to know all the levels of verification, esp. as we seem to find new lows all the time? The problem at hand is that Comodo's RAs under PositiveSLL simply made no verifications at all, although they were *legally required* to do so. Do you mean contractually required ? Minor point. How are we supposed to match that to UI? We can't. It's simply a failure of the CA. They get worse and worse and worse. It's *not* a UI problem. We just have to yank them, it's that simple. Then, users don't have to worry. Put Comodo's name on the chrome. They will never fluff it again, I guarantee it, or sue me. (OK, that's a bit of a joke, please don't take it literally. The thing is that they have zero incentive to do it correctly. Give them an incentive?) (For those looking for a biased argument or an advocacy approach in the above, note that I published this argument frequently before my current role as auditor of a CA. It's just business common sense.) iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How do I get the certificates out of the builtin object token?
Kyle Hamilton wrote, On 2008-12-31 06:36 PST: KyleMac:.netscape kyanha$ modutil -add roots -libfile /Applications/Firefox.app/Contents/MacOS/libnssckbi.dylib -dbdir . WARNING: Performing this operation while the browser is running could cause corruption of your security databases. If the browser is currently running, you should exit browser before continuing this operation. Type 'q enter' to abort, or enter to continue: Using database directory ERROR: Failed to add module roots. Probable cause : Unknown error: -2804. KyleMac:.netscape kyanha$ (The architecture is 'i386' on all of modutil, certutil, and libnssckbi.dylib.) Kyle, Please file a bug about this. Product: NSS, component: Libraries Error -2804 is not a known NSS or NSPR error code. It's not even in the range of known error codes. The known ranges are: -5k+1 ... -6k NSPR -7k+1 ... -8k NSS -11k+1 ... -12kSSL So, this failure is a mystery. Note also that if the nssckbi file is in the directory where the DBs live, it should get loaded automatically, even if it's not in the secmod DB. But given the failure you're seeing, I'd be surprised if that works for you. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
Kyle Hamilton wrote: Ummm... has an enterprise PKI ever been included in Mozilla? Sorry, I wasn't being clear here. I'm not referring to enterprises that have their own root CAs. I was referring to schemes where enterprises work through CAs like VeriSign to issue certificates to their own employees, servers, etc. IIRC in a number of these schemes the CA is responsible for actually issuing the certificates but the validation is done by the enterprise. (For example, the CA might provide a web-based interface by which authorized representatives of the enterprise can submit previously-validated CSRs to the CA, and get back certificates in return.) In these cases the enterprises are essentially acting as RAs. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
RE: Can't unwrap key into NSS in FIPS mode
Nelson, I wonder if anything from this thread has any bearing here as you describe some FIPS restrictions: http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/a5d22af274d36c6a?pli=1 I've been trying to help out Alex in the Sun forums and pointed him over here with this issue. Does it matter whether the RSA and AES keys are session or token objects? I've imported the session AES into the token and then pulled it back out and done encrypt/decrypt which works fine. Wrapping and unwrapping are where the problem occurs. I can check and see if importing some RSA keys via pk12util into the database and then pulling them out makes any difference. Dave -Original Message- raw Key : SunPKCS11-NSScrypto AES secret key, 128 bits (id 12, session object, sensitive, extractable) java.security.InvalidKeyException: Could not create key at sun.security.pkcs11.P11SecretKeyFactory.createKey (P11SecretKeyFactory.java:226) at sun.security.pkcs11.P11SecretKeyFactory.convertKey (P11SecretKeyFactory.java:131) at sun.security.pkcs11.P11Cipher.engineGetKeySize(P11Cipher.java:582) at javax.crypto.Cipher.b(DashoA13*..) at javax.crypto.Cipher.a(DashoA13*..) at javax.crypto.Cipher.init(DashoA13*..) at javax.crypto.Cipher.init(DashoA13*..) at EncryptionTest.main(EncryptionTest.java:88) Are you sure this is not coming from the cipher.unwrap call? If you add a line of code to print info about the unwrapped key, does it show that key to be in the NSS token? Can anybody tell me what am I doing wrong? Or, may be, point me to some working JAVA code that performs wrap/unwrap of the key in NSS token? Maybe one of our seasoned Java veterans can help with those questions. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
RE: Can't unwrap key into NSS in FIPS mode
If I wrap/unwrap with a token object RSA key, I get a different error trying to encrypt with the unwrapped AES key: RSA key from NSS DB: SunPKCS11-NSSfips RSA private key, 2048 bits (id 2464323849, token object, sensitive, extractable) pulled sym key out of keystore? SunPKCS11-NSSfips AES secret key, 16 bits (id 3126949473, token object, sensitive, extractable) Wrapped symmetric key with RSA key, wrapped size = 256 Unwrapped symmetric key using RSA private key, unwrapped key: javax.crypto.spec.secretkeys...@17fde Exception in thread main java.security.InvalidKeyException: Could not create key at sun.security.pkcs11.P11SecretKeyFactory.createKey(P11SecretKeyFactory.java:226) at sun.security.pkcs11.P11SecretKeyFactory.convertKey(P11SecretKeyFactory.java:131) at sun.security.pkcs11.P11Cipher.engineGetKeySize(P11Cipher.java:582) at javax.crypto.Cipher.b(DashoA13*..) at javax.crypto.Cipher.a(DashoA13*..) at javax.crypto.Cipher.init(DashoA13*..) at javax.crypto.Cipher.init(DashoA13*..) at NssPkcs11.main(NssPkcs11.java:62) Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ATTRIBUTE_VALUE_INVALID at sun.security.pkcs11.wrapper.PKCS11.C_CreateObject(Native Method) at sun.security.pkcs11.P11SecretKeyFactory.createKey(P11SecretKeyFactory.java:221) ... 7 more Dave -Original Message- Actually, the cipher.unwrap call passes fine, but when I print the unwrappedKey - it looks like a secretKeySpec rather than a key that resides in NSS token. But I can't figure out what am I doing wrong - 'cause I explicitly pass provider to all my cipher initializations... ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Can't unwrap key into NSS in FIPS mode
David Stutzman wrote, On 2008-12-31 11:30: If I wrap/unwrap with a token object RSA key, I get a different error trying to encrypt with the unwrapped AES key: RSA key from NSS DB: SunPKCS11-NSSfips RSA private key, 2048 bits (id 2464323849, token object, sensitive, extractable) pulled sym key out of keystore? SunPKCS11-NSSfips AES secret key, 16 bits (id 3126949473, token object, sensitive, extractable) 16 bits? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
Frank Hecker wrote, On 2008-12-31 10:48 PST: Nelson B Bolyard wrote: A representative of Verisign has posted a response to this issue at https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php The VeriSign post is not 100% clear on exactly how VeriSign has removed this vulnerability (to quote the blog post). Is it simply that VeriSign has now discontinued using MD5 when issuing RapidSSL certificates and other end-entity certificates under the various VeriSign/thawte/GeoTrust brands? Material elsewhere in the post seems to imply that this was the only corrective action taken (or that needed to be taken), but I don't recall it being made explicit in the post. After reading the above-cited blog post, I conclude that RapidSSL was changed to stop using MD5, and that other Verisign-controlled CAs still plan to stop using MD5 before the end of January. It's not clear to me that the other CAs that still use MD5 have been made invulnerable, or how that was actually accomplished, if it was. There are a number of ways (besides replacing MD5) that could have been used to make the CAs less vulnerable, including (but not limited to) - switching to a large random serial number instead of a sequential (and hence predictable) serial number - issuing certs with less predictable notBefore and notAfter validity dates. (Just randomizing the number of seconds in each would go a long way.) - cease issuing certs from those CAs until they can be switched to SHA1. It would be nice to know which (if any) of those measures have been taken, because that would increase my confidence that the CAs actually have been made less vulnerable. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
Personally, I cannot see that there is an imminent danger. The attack requires substantial resource, unpublished techniques, dramatic timing attempts and retrys and no doubt other caveats ... and will be stopped whenever MD5 is dropped, which is apparantly very soon or already. See the report of Hal Finney below (one of the half dozen most reliable people in security crypto work). (It would seem that the maximum Mozilla needs to do is simply stop accepting MD5. E.g., like Verisign, advance plans to drop it end Jan forward to end today.) Although the attack is widely puffed up as the end of the world as we know it, it looks quite narrow and harmless, as most of these are. Or? iang On 30/12/08 20:51, Hal Finney wrote: Re: http://www.win.tue.nl/hashclash/rogue-ca/ Key facts: - 6 CAs were found still using MD5 in 2008: RapidSSL, FreeSSL, TC TrustCenter AG, RSA Data Security, Thawte, verisign.co.jp. Out of the 30,000 certificates we collected, about 9,000 were signed using MD5, and 97% of those were issued by RapidSSL. RapidSSL was used for the attack. - The attack relies on cryptographic advances in the state of the art for finding MD5 collisions from inputs with different prefixes. These advances are not yet being published but will presumably appear in 2009. - The collision was found using Arjen Lenstra's PlayStation Lab and used 200 PS3s with collectively 30 GB of memory. The attack is in two parts, a new preliminary birthdaying step which is highly parallelizable and required 18 hours on the PS3s, and a second stage which constructs the actual collision using 3 MD5 blocks and runs on a single quad core PC, taking 3 to 10 hours. - The attack depends on guessing precisely the issuing time and serial number of the good certificate, so that a colliding rogue certificate can be constructed in advance. The time was managed by noting that the cert issuing time was reliably 6 seconds after the request was sent. The serial number was managed because RapidSSL uses serially incrementing serial numbers. They guessed what serial number would be in use 3 days hence, and bought enough dummy certs just before the real one that hopefully the guessed serial number would be hit. - The attacks were mounted on the weekend, when cert issuance rates are lower. It took 4 weekends before all the timing and guessing worked right. The cert was issued November 3, 2008, and the total cert-purchase cost was $657. - The rogue cert, which has the basicConstraints CA field set to TRUE, was intentionally back-dated to 2004 so even if the private key were stolen, it could not be misused. My take on this is that because the method required advances in cryptography and sophisticated hardware, it is unlikely that it could be exploited by attackers before the publication of the method, or the publication of equivalent improvements by other cryptographers. If these CAs stop issuing MD5 certs before this time, we will be OK. Once a CA stops issuing MD5 certs, it cannot be used for the attack. Its old MD5 certs are safe and there is no danger of future successful attacks along these lines. As the paper notes, changing to using random serial numbers may be an easier short-term fix. Therefore the highest priority should be for the six bad CAs to change their procedures, at least start using random serial numbers and move rapidly to SHA1. As long as this happens before Eurocrypt or whenever the results end up being published, the danger will have been averted. This, I think, is the main message that should be communicated from this important result. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How do I get the certificates out of the builtin object token?
Bug 471734. Poking around Apple's developer site, the only thing I can come up with for error -2804 is cfragNoLibraryErr, with the description The named library was not found. I'm also seeing that some functions in the code fragment library were deprecated in 10.5, but I can't find information on what they were superseded by. -Kyle H On Wed, Dec 31, 2008 at 10:22 AM, Nelson B Bolyard nel...@bolyard.me wrote: Kyle Hamilton wrote, On 2008-12-31 06:36 PST: KyleMac:.netscape kyanha$ modutil -add roots -libfile /Applications/Firefox.app/Contents/MacOS/libnssckbi.dylib -dbdir . WARNING: Performing this operation while the browser is running could cause corruption of your security databases. If the browser is currently running, you should exit browser before continuing this operation. Type 'q enter' to abort, or enter to continue: Using database directory ERROR: Failed to add module roots. Probable cause : Unknown error: -2804. KyleMac:.netscape kyanha$ (The architecture is 'i386' on all of modutil, certutil, and libnssckbi.dylib.) Kyle, Please file a bug about this. Product: NSS, component: Libraries Error -2804 is not a known NSS or NSPR error code. It's not even in the range of known error codes. The known ranges are: -5k+1 ... -6k NSPR -7k+1 ... -8k NSS -11k+1 ... -12kSSL So, this failure is a mystery. Note also that if the nssckbi file is in the directory where the DBs live, it should get loaded automatically, even if it's not in the secmod DB. But given the failure you're seeing, I'd be surprised if that works for you. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
At 6:48 PM + 12/31/08, Frank Hecker wrote: Nelson B Bolyard wrote: A representative of Verisign has posted a response to this issue at https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php The VeriSign post is not 100% clear on exactly how VeriSign has removed this vulnerability (to quote the blog post). Is it simply that VeriSign has now discontinued using MD5 when issuing RapidSSL certificates and other end-entity certificates under the various VeriSign/thawte/GeoTrust brands? Material elsewhere in the post seems to imply that this was the only corrective action taken (or that needed to be taken), but I don't recall it being made explicit in the post. I read that blog posting to mean that they were going to keep issuing certs using MD5 signatures, but would use unpredictable sequence numbers like other VeriSign CAs do. Someone can validate that by buying a new cert from them. :-) ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 12/31/2008 08:57 PM, Frank Hecker: employees, servers, etc. IIRC in a number of these schemes the CA is responsible for actually issuing the certificates but the validation is done by the enterprise. (For example, the CA might provide a web-based interface by which authorized representatives of the enterprise can submit previously-validated CSRs to the CA, and get back certificates in return.) In these cases the enterprises are essentially acting as RAs. And on the same token, the CA could perform the validation of the domain through said web interface. I'd see exception for whole IP blocks and batch submissions, whereas the IP block ownership and details of the batch submission have been validated by the CA manually beforehand. The enterprise scenario doesn't present a situation which would justify exemption of domain validation requirement. As per proposal it still would be possible though with appropriate attestation about the RAs capabilities and controls in place. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org 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: CAs and external entities (resellers, outsourcing)
On 12/31/2008 12:30 PM, Rob Stradling: Yes, Reseller and RA are 2 distinct roles. However, in some cases, a single entity may choose (and be approved) to perform both of these roles. I fully agree that the Reseller role should not perform any validation procedures at all. Robin, could you provide some clarifications and your opinion concerning the post I made titled Facts about Comodo Resellers and RAs in particular in relation to the CP and CP statements here: http://groups.google.com/group/mozilla.dev.tech.crypto/msg/416aa6f5b5610ccf -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org 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: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Kaspar Brand wrote: Michael Ströder wrote: I'd love to have an option to forbid CRMFRequest calls... Not too difficult to achieve, actually. Just add this line to your prefs.js: user_pref(capability.policy.default.Crypto.generateCRMFRequest, noAccess); That may work now, but capability control for individual DOM properties is gone in Firefox 3.1 betas for performance reasons. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
