Re: About assgining 1024-bit encrypted certificates & encoding of authority information

At 9:32 PM +0300 9/1/09, Eddy Nigg wrote: >On 09/01/2009 09:23 PM, Georgi Guninski: >>On Mon, Aug 31, 2009 at 10:30:03PM +0800, Tobby Lau wrote: >> >>>certificates till 2010 >>> >>2010 is 3 months away. It is also a completely arbitrary date that NIST pulled out of its ; folks at NIST are q

Re: attack against AES-256 with complexity 2^119

At 3:16 PM +0200 7/9/09, Ian G wrote: >Although I haven't read it at all, normally what happens is that the strength >of an algorithm of X bits is X/2. Say what!?! AES is an encryption function, not a hash function. AES-256 has a strength of 256 bits. -- dev-tech-crypto mailing list dev-tech-cr

Re: attack against AES-256 with complexity 2^119

At 8:08 PM +0300 7/8/09, Eddy Nigg wrote: >On 07/08/2009 08:03 PM, Peter Djalaliev: >>There has been an attack on the full AES-256 algorithm with space and >>time complexity of 2^119. Reportedly, the attack works on all keys. The title of the paper (and the body, of course) says otherwise. >Funn

Fwd: Has any public CA ever had their certificate revoked?

Peter Gutmann asked on a different mailing list: >Subject says it all, does anyone know of a public, commercial CA (meaning one >baked into a browser or the OS, including any sub-CA's hanging off the roots) >ever having their certificate revoked? An ongoing private poll hasn't turned >up anything

Re: SHA-1 collisions now 2^52

At 4:27 PM -0700 4/30/09, Robert Relyea wrote: >Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; >micalg=sha1; boundary="ms000907030103030804040502" > >Nelson B Bolyard wrote: >>SHA-1 has taken a significant hit. See >> >>http://eurocrypt2009rump.cr.yp.to/837a

Re: Work-around for Moxie Marlinspike's Blackhat attack

At 6:32 AM -0800 2/27/09, Kyle Hamilton wrote: >The Unicode standard actually cross-references each character and >visually-indistinct glyph. No, it doesn't. Foisting this off on other bodies such as the the Unicode Consortium is only a good idea when they actually are willing to take on the wor

Re: Take my database of certs/ssl details from high-traffic sites, please!

er or not a CA uses unpredictable serial number and date of issue and revocation, some browser vendors...". --Paul Hoffman -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Return of i18n attacks with the help of wildcard certificates

At 12:49 PM +0100 2/26/09, Jean-Marc Desperrier wrote: >Just one thing : The use of a wildcard certificate was a misleading red >herring in the implementation of the attack. > >What's truly broken is that the current i18n attack protection relies on the >checking done by the registrar/IDN, and th

Re: Return of i18n attacks with the help of wildcard certificates

At 7:09 AM +0100 2/24/09, Kaspar Brand wrote: >Kyle Hamilton wrote: >> Removal of support for wildcards can't be done without PKIX action, if >> one wants to claim conformance to RFC 3280/5280. > >Huh? Both these RFCs completely step out of the way when it comes to >wildcard certificates - just rea

Re: Return of i18n attacks with the help of wildcard certificates

At 2:19 AM +0200 2/23/09, Eddy Nigg wrote: >You don't like that I mention particular CAs, but the one I'm affiliated with >does to some extend. ;-) I do not like you mentioning particular CAs to advertise (yourself) or attack (your competitor); asking for a list of CAs that implement policies th

Re: Return of i18n attacks with the help of wildcard certificates

At 1:14 PM +0100 2/23/09, Jean-Marc Desperrier wrote: >Paul Hoffman wrote: >>TLD registries ask which language a name is in; some then do some >>filtering based on what characters they think are used by particular >>languages. This is far from a science and fails miserabl

Re: Return of i18n attacks with the help of wildcard certificates

>I think part of what's going on here is a confusion between CAs and domain >name registrars. IIRC there was indeed some sort of agreement among domain >name registrars to implement special checking for internationalized domain >names. There was no such agreement. TLD registries ask which langu

Re: Return of i18n attacks with the help of wildcard certificates

>On Sat, Feb 21, 2009 at 1:19 PM, Paul Hoffman wrote: >>>I don't see how the attack could have been done without wildcards. CA >>>guidelines say that certificates should not be issued with homographic >>>characters that might cause confusion >> >

Re: Return of i18n attacks with the help of wildcard certificates

At 1:28 PM -0500 2/20/09, Benjamin Smedberg wrote: >On 2/20/09 12:11 PM, Nelson B Bolyard wrote: >> Benjamin Smedberg wrote, On 2009-02-19 07:39: >> >>> It sounds to me that we could and should fix this bug simply by disabling >>> punycode for the wildcard portion. >> >> I'm not sure what you're pr

Re: what is the new work requirement for the auditor?

>Seems to me that this is another case where we're having problems >because we're using a term ("CPS") which is widely understood, but >for which more than one meaning exists. As long as we continue to >use it without defining it, we will have problems of people seeming >to agree, but having diffe

Re: Hongkong Post Root Inclusion Request

At 7:58 PM -0800 2/12/09, Nelson B Bolyard wrote: >Recently, a CA that uses partitioned CRLs applied to admission to >the Mozilla/NSS root CA list. Our choices appear to be: > >1) Do not admit their root until support for partitioned CRLs is done. >(There is no active plan of record to do that wor

Re: Policy: revoke on private key exposure

At 6:23 PM -0800 2/4/09, Kyle Hamilton wrote: >There are two states in the NIST key state transition diagram that are >appropriate to this entire concept... "compromised" (state entered >when the private information associated with it -- i.e., the private >key and its passphrase, and has only one p

Re: Policy: revoke on private key exposure

At 5:09 PM + 2/4/09, Frank Hecker wrote: >1. To what extent do typical CPSs and CPs address this issue? In other words, >if we were to read the average CPS/CP, would it have language that would >unambiguously tell us whether our policy requirement were met or not? Or is >this something that'

Re: Policy: revoke on private key exposure

At 12:29 PM +0100 2/1/09, Ian G wrote: >On 31/1/09 17:08, Paul Hoffman wrote: >>If a trust anchor has a CRL that is too large for for the implementation to >>handle, the implementation MUST remove that trust anchor from its pile. > > >Wouldn't it be better to mark t

Re: Policy: revoke on private key exposure

>On 31/1/09 03:56, Kyle Hamilton wrote: >>The PKIX standard can deal with problems of this extent. >> >>If an implementation of the standard cannot, then the implementation >>is nonconforming, and cannot be expected to interoperate. > > >Do you mean, an implementation should be able to deal with a

Re: Policy: revoke on private key exposure

It is kind of sad that this discussion has become "CAs should not revoke certificates when the private keys are exposed because Java cannot handle CRLs reliably". That says more about the failures of Java than it does failures in PKIX. --Paul Hoffman -- dev-tech-crypto mailing lis

Re: Policy: revoke on private key exposure

At 1:21 PM +0100 1/29/09, Jean-Marc Desperrier wrote: >Eddy Nigg wrote: >>[...] >>Well, this thread started out with the request that Mozilla should >>change it's policy to require CAs revoke certificate when the private >>key is known to be compromised. > >Given the practical problems of revoking

Re: Proposal to split this list

At 12:53 PM +0100 1/29/09, Ben Bucksch wrote: >On 27.01.2009 05:20, Gervase Markham wrote: >>https://bugzilla.mozilla.org/show_bug.cgi?id=475473 >>filed to create mozilla.dev.security.policy. And please let's not have a >>bikeshed discussion about the name. >> > >Sorry to do just that, but I thin

Policy: revoke on private key exposure

At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote: >Perhaps Mozilla should change its policy to require CAs to revoke certs >when the private key is known to be compromised, whether or not an attack >is in evidence, as a condition of having trust bits in Firefox. Fully agree. --Pau

Re: Take my database of certs/ssl details from high-traffic sites, please!

>Is this useful for people? Yes. If for some reason you need to stop supporting this wonderful, please let this list know in advance. I, for one, would be willing to take it over. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https:

Re: Proposal to split this list

lp keep the policy people keep their discussion out of bits-on-the-wire and up in the "what should we be doing" layer. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Suggestion: Announce date for MD5 signature deactivation

At 5:29 PM -0800 1/13/09, Julien R Pierre - Sun Microsystems wrote: >Just because root CAs have stopped using MD5 doesn't mean every intermediate >CA in the world has stopped yet. It would be a fairly arduous task to >determine that. If a sub CA hasn't stopped using MD5 yet, they may be subject

Re: Suggestion: Announce date for MD5 signature deactivation

At 9:00 PM +0200 1/13/09, Eddy Nigg wrote: >On 01/13/2009 05:23 PM, Paul Hoffman: >>>Useful yes, up to certain extend. If there is too much information in the >>>policy, it will start to be problematic. >> >>For whom? > >For Mozilla mostly. We disagree her

Re: Cert expiry with Key Continuity Management

At 3:31 PM + 1/13/09, Rob Stradling wrote: >Why "almost every piece of PKIX validating software" ? > >I think it would be worth it if, at a minimum... > - the majority of CAs added the extension to the certificates they issue, >and... > - Mozilla implemented support for the extension in NSS.

Re: Suggestion: Announce date for MD5 signature deactivation

At 11:16 AM +0200 1/13/09, Eddy Nigg wrote: >On 01/13/2009 10:15 AM, Rob Stradling: >>Eddy, I do think that the Mozilla CA Certificate Policy should cover >>*all* "actual" problematic practices. In this particular case, I think that >>a blacklist of unsupported/non-allowed/not-recommended algorith

Re: Cert expiry with Key Continuity Management

validating software added the extension, it wouldn't really add much value. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: On reading PKIX

>Thus, the CA is the only one who takes actions related to its >commitment to the binding. (Others may choose to disbelieve a given >binding, either via not accepting the CA's statements or by >specifically distrusting a specific statement; the latter can be done >via a private OCSP responder am

Re: On reading PKIX

At 2:48 PM -0800 1/12/09, Nelson B Bolyard wrote: >I explain it to people this way: The notAfter date is the date after which >the CA has no further obligation to report that the cert was ever revoked. Yes, quite right. >(It actually is obliged to report revocation ONE more time after the >notAft

Re: On reading PKIX

At 1:42 PM -0800 1/12/09, Kyle Hamilton wrote: >Technically, 'expiration' is also an action taken by the CA. No, it is an action taken by time passing. When the time in the univers is the same as the time listed as "notAfter" in the cert, the cert expires. That's it. >It's >basically saying, "I

Re: On reading PKIX

At 10:07 PM +0100 1/12/09, Ian G wrote: > * RFC5280 is an implementation document and doesn't do > semantics much, if at all. > * It does not define the meaning of expiry or revocation. > * By _meaning_, I mean semantics, what outsiders should take > as the message being delivered, im

Re: Suggestion: Announce date for MD5 signature deactivation

ve to be >explicitly stated in the Mozilla CA Policy? Yes. > If yes, what else must be stated there or is the intend of the policy clear > enough? Everything that we know that some CAs might do wrong that is not acceptable to Mozilla should be listed there.

On reading PKIX

At 1:52 PM +0100 1/12/09, Ian G wrote: >These are word games. What is the definition of these words? If you look in >the RFCs, likely (I have not, please correct me if I am wrong) A better idea would be for all of us to read them and point out where in the document it says something. For exam

Re: Suggestion: Announce date for MD5 signature deactivation

order to stay in the root pile. Further, even if a "technicians can turn off MD5", you are ignoring all the MD5-based certs that they have already issued for which there is no security threat. >This is what happened at Verisign, they were 1 month (apparently) away from >droppi

Re: Suggestion: Announce date for MD5 signature deactivation

>The main difference is that my solution would force all MD5 certs out of >circulation by the given date, no matter their expiration date, ...for no valid security reason... > while yours would allow MD5 certs with long validity periods to stay in use. ...because there is no security problem wi

Re: Suggestion: Announce date for MD5 signature deactivation

At 12:51 PM -0500 1/9/09, Johnathan Nightingale wrote: >On 8-Jan-09, at 3:45 PM, Paul Hoffman wrote: > >>At 6:51 PM +0100 1/8/09, Jan Schejbal wrote: >>>As the MD5 algorithm is obviously not secure anymore, >> >>This statement is not based on reality, so the rest

Re: Cert expiry with Key Continuity Management

At 12:42 AM +0200 1/9/09, Eddy Nigg wrote: >On 01/09/2009 12:15 AM, Nelson B Bolyard: >>It requires that CAs NEVER "forget" about any certs they previously >>issued, not even after they expire. It means that a CA's list of revoked >>certs will grow boundlessly. It makes CRLs become impractically

Re: Suggestion: Announce date for MD5 signature deactivation

At 11:41 PM +0100 1/8/09, Jan Schejbal wrote: >>MD5 is not secure for applications that blindly sign inputs from non-trusted >>parties that can predict the content of the part of the message before the >>submitted text. This is an attack on the collision-resistance of the function. > >I assume th

Re: Suggestion: Announce date for MD5 signature deactivation

At 6:51 PM +0100 1/8/09, Jan Schejbal wrote: >As the MD5 algorithm is obviously not secure anymore, This statement is not based on reality, so the rest of the message does not follow. MD5 is not secure for applications that blindly sign inputs from non-trusted parties that can predict the conten

Re: OCSP bypass in recent demo/exploit

Is there any way I can suck back the last two messages I sent on this thread and pretend they never happened? I guess not. Please ignore my assertions about what the AIA extension does: I was completely wrong. As we were making the AIA extension in the PKIX WG, we discussed multiple proposals,

Re: OCSP bypass in recent demo/exploit

At 6:51 PM -0800 1/5/09, Julien R Pierre - Sun Microsystems wrote: >Paul, > >Paul Hoffman wrote: > >>>3) A corollary of (2): Even when parent == grandparent, and hence parent >>>is also a sibling, it's not generally true that you can use the OCSP URL >>>

Re: OCSP bypass in recent demo/exploit

At 4:01 PM -0800 1/5/09, Nelson B Bolyard wrote: >Paul Hoffman wrote, On 2009-01-05 08:54: >> At 3:09 PM +0100 1/5/09, Ian G wrote: > >>> [...] Hence, once we rogue-players have created a certificate like this, >>> the CA cannot revoke it using its own control me

Re: Proposal to split this list (was: Re: Full Disclosure!)

At 1:35 PM -0800 1/5/09, Wan-Teh Chang wrote: >On Sun, Jan 4, 2009 at 12:32 PM, Paul Hoffman wrote: >> >> I propose that Mozilla form a new mailing list, dev-policy-trustanchors. The >> topics for that list would include: >> >> - All new trust anchors being added

Re: OCSP bypass in recent demo/exploit

At 3:09 PM +0100 1/5/09, Ian G wrote: >The recent MD5 collision attack has also demonstrated a "brittle" side of OCSP >[1]: > >http://blogs.technet.com/swi/archive/2008/12/30/information-regarding-md5-collisions-problem.aspx > >It seems that, assuming we can create an intermediate or subroot certi

Re: Full Disclosure!

At 6:08 PM +0200 1/5/09, Eddy Nigg wrote: >Therefor we can't lump just all failures together and as you correctly stated, >there is no clear line between one and the other. This is what I was saying. What you said was "As I see it, our case indeed was a bug, the Comodo case was negligence". That

Re: Proposal to split this list

>Ian G wrote, On 2009-01-04 16:01: >> On 4/1/09 21:32, Paul Hoffman wrote: >> >>> I propose that Mozilla form a new mailing list, >>> dev-policy-trustanchors. The topics for that list would include: >>> >>> - All new trust anchors being added t

Proposal to split this list (was: Re: Full Disclosure!)

threads that have literally nothing to do with crypto but everything to do with policy. Thoughts? --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Full Disclosure!

Why is this relevant to this mailing list? --Paul Hoffman ___ 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 11:05 AM -0800 1/2/09, geoff.tol...@gmail.com wrote: >On Dec 31 2008, 3:10 pm, Paul Hoffman wrote: > >> 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 Veri

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

Re: MD5 broken, certs whose signatures use MD5 now vulnerable

At 1:16 PM -0800 12/30/08, Nelson B Bolyard wrote: >Paul Hoffman wrote, On 2008-12-30 12:43: >> At 8:39 AM -0800 12/30/08, Nelson B Bolyard wrote: >>> The upshot of this is probably going to be that, in a short time, all >>> the world's browsers (and PKI software

Re: Just change expiry time

gue subordinate CAs, having a "replacement cert" mechanism for NSS / Mozilla trust anchor stores would be great. >I see no problem the schedule the removal of a trust flag. For security >reasons all users have to update browsers from time to t

Re: MD5 broken, certs whose signatures use MD5 now vulnerable

ld be revised as soon as possible to include no trust anchors that use MD5 in their signature algorithm. Although the attack described in the paper does not directly affect MD2, it is very likely that the same math used by the researchers could be applied to MD2

Re: Unbelievable!

At 7:16 PM +0100 12/25/08, Michael Ströder wrote: >I'd tend to punish a rogue CA by removing their root CA cert from NSS. >Maybe this serves as a good example to other CAs that the Mozilla CA >policy is really enforced. Otherwise nobody will care. This is Firefox we're talking about, not IE. Do yo

Re: Unbelievable!

At 11:13 PM -0800 12/24/08, Daniel Veditz wrote: >Paul Hoffman wrote: >> At 1:16 AM +0200 12/24/08, Eddy Nigg wrote: >>> Select Preferences -> Advanced -> View Certificates -> Authorities. >>> Search for AddTrust AB -> AddTrust External CA Root

Re: Unbelievable!

At 1:46 PM -0800 12/24/08, Nelson B Bolyard wrote: >Paul Hoffman wrote, On 2008-12-24 09:55: > > - Remove all trust anchors one-by-one >> - Add your single trust anchor >> - Sign the certs of any CA you want >> - Add those signed certs to the pre-loaded validation pa

Re: Unbelievable!

At 11:35 AM -0800 12/24/08, Kyle Hamilton wrote: >In the terminology of ASN.1 and PKIX, I want a standardized PKIX >extension that allows for a SEQUENCE OF Certificate within the >tbsCertificate structure. That makes no sense to me, but I would have to see a complete proposal to understand why yo

Re: Unbelievable!

h (not root) cert list I haven't tried this myself, but it should work. I have been told that something very similar to it works fine in XP/Vista for IE. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://l

Re: Unbelievable!

e, and the folks who might remove Comodo from the root pile are following the issue, probably more closely than they are letting on. Do you really think "oh, but if only Paul Hoffman would be critical, then things will really change"? FWIW, I would be shocked if you could not get th

Re: Unbelievable!

At 1:16 AM +0200 12/24/08, Eddy Nigg wrote: >Select Preferences -> Advanced -> View Certificates -> Authorities. Search for >AddTrust AB -> AddTrust External CA Root and click "Edit". Remove all Flags. > >This would remove the trust from the potentially affected sites and their >certificates. Com

Re: Unbelievable!

At 2:51 PM -0800 12/23/08, Kyle Hamilton wrote: >I believe that Startcom (and other certification authorites in >Mozilla's root program) would likely have cause to bring an action for >the tort of negligence against Mozilla. I feel that this is something >that Mozilla should likely ask its general

Re: Unbelievable!

At 3:15 PM +0200 12/23/08, Eddy Nigg wrote: >If they don't shut that site, we can perhaps just publish the private key for >the mozilla.com certificate as well so everybody can enjoy it. It is indeed unbelievable to hear the COO of a CA company making threats like this. I'm sure that making such

Re: Unbelievable!

At 11:27 AM -0800 12/23/08, Kyle Hamilton wrote: >I'd rather deal with disruption caused thereby (and, yes, the user >complaints generated thereby -- at least then the end-user would KNOW >that there's a problem that's being dealt with rather than having a >FALSE SENSE OF SECURITY) than let those p

Re: UTF8 support in the Firefox certificate store?

At 6:13 AM -0800 12/6/08, [EMAIL PROTECTED] wrote: >Initially I posted this on another support forum, but was kindly >requested to post here instead: > >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 test

Re: DNSSEC? Re: MITM in the wild

At 8:20 PM +0200 11/15/08, Eddy Nigg wrote: >Lets stay focused! This thread started off with a purported newbie having a problem with seeing self-signed certs where she shouldn't have. It then morphed into a discussion of security UI design. Then it went to what users shold and should not be tol

Re: DNSSEC? Re: MITM in the wild

At 11:52 AM -0800 11/10/08, Nelson Bolyard wrote: >DNSSEC only attempts to ensure that you get the (a) correct IP address. s/only/only currently/ You can stick any data you want in the DNS. Currently the most popular data is the A record (IP address) associated with a domain name, but is it quit

Re: MITM in the wild

>Well, all the arguments have been heard on this already, and positions are >fairly entrenched. It seems futile to have the debate over and over, and I >for one would like to point out that it is uncomfortable to treat it like a >political campaign. > >Perhaps a vote? Not for me, but perhaps a

Re: revocation of roots

At 9:42 AM -0700 10/24/08, Robert Relyea wrote: >Paul Hoffman wrote: >>Robert: you are already in that business by distributing trust anchors that >>you have (sometimes) vetted. You are a CA without signing anything, just by >>distributing a trust anchor repository. >>

Re: revocation of roots

a mess because it is a protocol and not just a seat-of-the-pants management task as it is today, but it is also hopefully less of a mess because it can be done outside of the software update cycle. --Paul Hoffman ___ dev-tech-crypto mailing

Re: revocation of roots

traceable management action" != "open message protocol". --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: revocation of roots

At 4:39 PM +0100 10/22/08, Gervase Markham wrote: >Julien R Pierre - Sun Microsystems wrote: >> If the root could "revoke itself", in the case of root cert key >> compromise, ie. the root cert's private key becoming public, anybody >> could then sign revocation information for that root CA - whethe

Re: revocation of roots

At 2:02 PM + 10/21/08, Frank Hecker wrote: >Paul Hoffman wrote: >>If you want to to be able to "revoke" roots, please consider instead >>getting active in the current work on TAMP (trust anchor management >>protocol) being discussed in the PKIX WG. > >Than

Re: revocation of roots

hread from this list, TAMP allows the trusted party to put limitations on a trust anchor, such as "only good for signing keys with names in *.com" and so on; that information doesn't need to reside in the trust anchor itself. My two cents --Paul Hoffman __

Re: MITM in the wild

users who have been MITM attacked chose to defeat their >protections, and switch to a product with less security. There is zero evidence that the people who switched were under attack. They may have been going to a site that was, in fact, self-signed. We have no way o

Re: MITM in the wild

;t see the expertise here for any of us to be stating the One True Solution. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: revocation of roots

At 2:45 AM + 10/18/08, Frank Hecker wrote: >Yes, but as I understand it what is being discussed here is a more elaborate >scheme whereby, for example, we (Mozilla) might run an actual CA just for the >purpose of cross certifying the roots that we accept. Like Nelson, I can't >remember who ex

Re: revocation of roots

At 11:13 AM -0700 10/17/08, Nelson B Bolyard wrote: >A root that revokes itself invokes the liar's paradox. >NSS wishes to avoid the fate of the android Norman. :) Sorry, but that's a bit too glib. A "suicide note" is one valid method of trust anchor management. It does not invoke t

Re: Dealing with third-party subordinates of T-Systems and others

At 3:02 PM +0300 10/3/08, Eddy Nigg wrote: >Here I wanted to add something...it's not that we should prevent >intermediate third-party CAs or cross-signing, but we need to apply the >same requirements on all CAs. But we don't. All the legacy CAs have different requirements put on them. To me, thi

Re: questions on root creation

At 4:59 PM -0700 9/23/08, Nelson B Bolyard wrote: >In finality, you have to pick a table from someone you believe has done a >really good job of analyzing it. Right. >Given that NIST's tables are the basis >for the US Government's protection of its own secrets, which it guards >jealously, I'm inc

Re: questions on root creation

At 4:23 PM -0700 9/23/08, Nelson B Bolyard wrote: >Paul Hoffman wrote: >> At 2:29 PM -0700 9/22/08, Nelson B Bolyard wrote: > >>> In CA certs, NSS understands the EKUs to mean "this CA can only issue >>> certs valid for these purposes", rather than mea

Re: questions on root creation

c ciphers (3DES, AES) and hashes. See tables 2 and 3, pp 63-64 in >> >>http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf > > >Ah, good point. http://keylength.net/ might be easier to read :) But is not as good of a reference. Understandi

Re: questions on root creation

At 2:29 PM -0700 9/22/08, Nelson B Bolyard wrote: >Ian G wrote, On 2008-09-22 09:45: >> Hi all, > >Hi Ian, >This reply isn't complete. I'm just going to discuss the questions with >easy answers. > >> * the following extended key usage fields within roots: >> + Server Authentication >>

IPsec implementations using NSS?

Greetings again. Are people aware of any IPsec implementations using NSS's crypto, even as a non-default build option? --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cannot make 3.12 on FreeBSD 7.0

>I just added build instructions for 3.11.4 and 3.12.1 to the page > Thank you. That page has a *lot* of variables that the 3.11.4-specific page does not. >I see that you, Paul, were the last previous e

Re: Cannot make 3.12 on FreeBSD 7.0

At 5:28 PM -0700 9/9/08, Wan-Teh Chang wrote: >On Tue, Sep 9, 2008 at 4:52 PM, Paul Hoffman <[EMAIL PROTECTED]> wrote: >> >> I nuked mozilla/* and used the two cvs commands above. The make >>now ends with: >> >> /usr/bin/ld: cannot find -lnssutil3 &g

Re: Cannot make 3.12 on FreeBSD 7.0

At 2:56 PM -0700 9/9/08, Nelson B Bolyard wrote: >Paul Hoffman wrote, On 2008-09-09 13:52: >> Greetings again. I'm trying to build 3.12 on FreeBSD 7.0. I follow >> the directions on >> >><http://www.mozilla.org/projects/security/pki/nss/nss-3.11.4/nss-3.11.

Cannot make 3.12 on FreeBSD 7.0

libnss.a -rw-r--r-- 1 phoffman phoffman 21196 Sep 9 13:44 nss.def -rw-r--r-- 1 phoffman phoffman 33720 Sep 9 13:44 nssinit.o -rw-r--r-- 1 phoffman phoffman 2876 Sep 9 13:44 nssver.o Any clues how I can move forwards on this? --Paul Hoffman _

Re: Comparison of OpenSSL and NSS

At 11:43 PM +0200 7/23/08, Daniel Stenberg wrote: >If you can stand a comparison that also involves GnuTLS, then the GnuTLS guys >have one: > > http://www.gnu.org/software/gnutls/comparison.html There are a lot of question marks on that for NSS. Someone familiar with all the NSS extensions

Re: Comodo ECC CA inclusion/EV request

>Paul Hoffman wrote: >> At 3:24 PM -0700 7/18/08, Wan-Teh Chang wrote: >>> On Fri, Jul 18, 2008 at 1:58 PM, Paul Hoffman <[EMAIL PROTECTED]> >>> wrote: >>>>> There's a test site with a Comodo-issued ECC cert at >>>>> https:

Re: Comodo ECC CA inclusion/EV request

At 11:04 AM +0100 7/19/08, Rob Stradling wrote: >I think that the ECDSA signature algorithms will only be supported in OpenSSL >0.9.9 (not yet released) and above. > >Try a recent openssl-SNAP-2008mmdd.tar.gz from ftp://ftp.openssl.org/snapshot >instead. Will do. Non-mandatory question: what soft

Re: Comodo ECC CA inclusion/EV request

At 3:24 PM -0700 7/18/08, Wan-Teh Chang wrote: >On Fri, Jul 18, 2008 at 1:58 PM, Paul Hoffman <[EMAIL PROTECTED]> wrote: >> >>>There's a test site with a Comodo-issued ECC cert at >>> >>> https://comodoecccertificationauthority-ev.comodoca.c

Re: Firefox 3; CAs; Slashdot; guess what happens next

At 5:15 PM -0700 7/18/08, Nelson B Bolyard wrote: >Paul Hoffman wrote, On 2008-07-18 16:16: >> <http://ask.slashdot.org/article.pl?sid=08/07/18/1721234> > >It's gratifying to see the numbers of people who do understand PKI and >are refuting the usual ignorant nonsens

Re: Comodo ECC CA inclusion/EV request

At 6:18 PM -0400 7/18/08, Frank Hecker wrote: >Paul Hoffman wrote: >> At 9:27 AM -0400 7/18/08, Frank Hecker wrote: >>> Paul Hoffman wrote: >>> > Has anyone validated the ECC paramters they used? >>> >>> Not that I'm aware. >> >&

Firefox 3; CAs; Slashdot; guess what happens next

___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Comodo ECC CA inclusion/EV request

At 9:27 AM -0400 7/18/08, Frank Hecker wrote: >Paul Hoffman wrote: > > Has anyone validated the ECC paramters they used? > >Not that I'm aware. I think that's unfortunate. It is easy for all of us to test the parameters for RSA certs, but few of us have softwa

Re: Comodo ECC CA inclusion/EV request

Has anyone validated the ECC paramters they used? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

  1   2   >