Internet-Draft for a quick-and-dirty incremental improvement, whitelist-based CRL processing
http://www.ietf.org/id/draft-hamilton-cmr-00.txt Basic overview: 1) Import CRLv2 and all semantics. 2) Change the integer identifying the sequence format from 1 to 3 (v4). 2) Change default processing path to INVALID/REVOKED. 3) Place all potentially-valid (i.e., issued certificates which have not expired) certificates in a non-delta CRL with removeFromCrl as the reasonCode. This should be very easy to implement. It should also be very easy to implement a whitelist-fed OCSP responder which can be shared with CAs who need such. (return REVOKED unless it's on the whitelist with removeFromCrl.) -Kyle H-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
For discussion: MECAI: Mutually Endorsing CA Infrastructure
This is an idea how we could improve today's world of PKI, OCSP, CA's. https://kuix.de/mecai/ Review, thoughts and reports of flaws welcome. Thanks and Regards Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure
On 10/21/2011 08:09 AM, Kai Engert wrote: This is an idea how we could improve today's world of PKI, OCSP, CA's. https://kuix.de/mecai/ This is great. We need these kinds of ideas. Review, thoughts and reports of flaws welcome. OK, this is a serious thought, not just a flippant remark: Why would CAs want to act as VAs, and more importantly, why would they want to revoke their vouching? CAs seem to put a lot of emphasis on structured legal agreements/contracts. Surely they have such agreements in place when they cross-sign each other, so they would likely want them for this VA system. Contracts are enforced primarily by legal action with courts and lawyers and this adds very concrete risks and expenses even in the clearest of cases. On the other hand, declining to stop vouching for a partner CA experiencing some moderate problems (e.g. some compromised resellers issued fraudulent certs that were eventually revoked) seems associated with purely abstract risks (e.g. loss of confidence in the system as a whole). CAs are not the Relying Parties (i.e., users) and they're not even the software vendors to the RPs (like Mozilla). It's not clear to me if they feel the RPs are actually party to these contracts or to what extent they otherwise consider themselves liable to the RPs. But I suspect that the CAs themselves would be at least as reluctant to eliminate one of their fellow members as a vendor of client software. So is providing the CAs collectively with a tool to more efficiently reinforce or remove endorsements amongst themselves going to result in a substantial improvement over the system we have now? Or would the cost of new infrastructure be better spent on something else like, say, a more robust mechanism for informing users about software security updates? - Marsh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure
On 10/21/2011 03:09 PM, From Kai Engert: This is an idea how we could improve today's world of PKI, OCSP, CA's. https://kuix.de/mecai/ Review, thoughts and reports of flaws welcome. Interesting - but it probably will never work. I don't see CAs cooperating to this extend, it will probably create a few other issues on the way. However I'm still not sure why hard fail for revocation status can't be enforced. You've got OCSP, CRLs and if browsers implement fail-over and redundancy correctly, it could work already today I guess. From my experience it's the browsers which fail to use the full potential. For CAs that don't provide sufficient alternatives (multiple OCSP URIs, CRLs), redundant servers etc., subscribers will find better sources for their certificates. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
NSS crash in FIPS mode
I'm seeing the crash below after integrating NSS 3.12.5 into tomcat 6.0.29. Anyone have any ideas or suggestions? # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x52504bda, pid=10055, tid=1413200784 # # Java VM: Java HotSpot(TM) Server VM (11.2-b01 mixed mode linux-x86) # Problematic frame: # C [libnss3.so+0x46bda] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x08ea4800): JavaThread Finalizer daemon [_thread_in_native, id=10084, stack(0x5436b000,0x543bc000)] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x003c Registers: EAX=0x, EBX=0x525ac304, ECX=0x543bbc08, EDX=0x1d4ac740 ESP=0x543ba784, EBP=0x543ba798, ESI=0x1d4ac740, EDI=0x09215da8 EIP=0x52504bda, CR2=0x003c, EFLAGS=0x00010202 Top of Stack: (sp=0x543ba784) 0x543ba784: 543ba7a8 0650046a 525ac304 0x543ba794: 525ac304 543ba7b8 524e8efc 0x543ba7a4: 543ba7e8 524e8edc 0x543ba7b4: 525ac304 543ba7e8 524e9c7a 1d4ac740 0x543ba7c4: 08ea4914 0x543ba7d4: 543ba878 52a27f1c 09215da8 0x543ba7e4: 08ea4914 543ba818 52a12203 1d4ac740 0x543ba7f4: 09215da8 0040 09215da8 55870a80 Instructions: (pc=0x52504bda) 0x52504bca: 10 8b 45 08 e8 00 00 00 00 5b 81 c3 31 77 0a 00 0x52504bda: ff 70 3c e8 56 a0 fc ff 8b 5d fc c9 c3 90 55 89 Stack: [0x5436b000,0x543bc000], sp=0x543ba784, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libnss3.so+0x46bda] C [libnss3.so+0x2aefc] C [libnss3.so+0x2bc7a] PK11_DigestOp+0x8e C [libjss4.so+0x11203] Java_org_mozilla_jss_pkcs11_PK11MessageDigest_update+0x5f j org.mozilla.jss.pkcs11.PK11MessageDigest.update(Lorg/mozilla/jss/ pkcs11/CipherContextProxy;[BII)V+0 j org.mozilla.jss.pkcs11.PK11MessageDigest.update([BII)V+42 j org.mozilla.jss.provider.java.security.JSSMessageDigestSpi.engineUpdate([BII)V +7 j java.security.MessageDigest$Delegate.engineUpdate([BII)V+7 j java.security.MessageDigest.update([B)V+5 j com.sun.crypto.provider.HmacCore.a([BII)V+16 j com.sun.crypto.provider.HmacSHA1.engineUpdate([BII)V+7 j javax.crypto.Mac.update([B)V+33 j com.sun.net.ssl.internal.ssl.MAC.compute(BLjava/nio/ByteBuffer;[BII) [B+60 j com.sun.net.ssl.internal.ssl.MAC.compute(B[BII)[B+7 j com.sun.net.ssl.internal.ssl.OutputRecord.addMAC(Lcom/sun/net/ssl/ internal/ssl/MAC;)V+36 j com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecordInternal(Lcom/ sun/net/ssl/internal/ssl/OutputRecord;)V+5 j com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Lcom/sun/net/ ssl/internal/ssl/OutputRecord;)V+294 j com.sun.net.ssl.internal.ssl.SSLSocketImpl.sendAlert(BB)V+222 j com.sun.net.ssl.internal.ssl.SSLSocketImpl.warning(B)V+3 j com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(Z)V+196 j com.sun.net.ssl.internal.ssl.SSLSocketImpl.close()V+43 j com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.finalize()V+1 v ~StubRoutines::call_stub V [libjvm.so+0x375c9d] V [libjvm.so+0x5057f8] V [libjvm.so+0x375b30] V [libjvm.so+0x39f557] V [libjvm.so+0x385fea] C [libjava.so+0xcb9e] Java_java_lang_ref_Finalizer_invokeFinalizeMethod+0x6e J java.lang.ref.Finalizer.invokeFinalizeMethod(Ljava/lang/Object;)V -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
