Re: CAs and external entities (resellers, outsourcing)

On 28.12.2008 12:13, Kai Engert wrote: From my perspective, it's a CA's job to ensure competent verification of certificate requests. The auditing required for CAs is supposed to prove it. The verification task is the most important task. All people and processes involved should be part of the

PositiveSSL is not valid for browsers

Background: CertStar issued certificates without verification whatsoever. The faulty certs were signed with the PositiveSSL certificate, which is chained to the UserTRUST root cert that Mozilla ships. The UserTRUST cert is owned and operated by Comodo. Our policy mandates that CAs have a valid

Re: dropping the root is useless

On 29.12.2008 07:59, Nelson B Bolyard wrote: Perhaps the policy should even go so far, as Kai has suggested, as to require that whatever entity performs the verification of subject identity for the CA must be audited. Yes. Not perhaps. The verification is one of the two core operations of t

Re: CAs and external entities (resellers, outsourcing)

On 29.12.2008 19:04, Frank Hecker wrote: So, in theory at least a WebTrust for CAs audit is supposed to confirm management's assertions that verification of subscriber information is being done properly, including any verifications done by third-party RAs acting on behalf of the CA. In practice

Just change expiry time

If we decide that a CA does not operate properly,.but we don't want to cause problems for users, another option would be to shorten the expiry date of the relevant root certs to one year or less. Technically, that should be possible. The cert is public anyways. The current certs are probably s

Re: Can you rely on an Audit?

On 28.12.2008 14:23, Ian G wrote: [1] disclosure, I work as an auditor So, Ian, what are you trying to tell us? We can't yank roots. We can't rely on audits. How are we supposed to restore and ensure proper operation of the system? Obviously, just trusting CAs blindly and hoping for the bes

Re: PositiveSSL is not valid for browsers

On 30.12.2008 12:43, Ian G wrote: [Audits reliabilty] You already opened a thread about this (and I replied there). No point to open another sub-thread about this. Most all certificates carry no warranty No. This particular sentence appears under heading "Positive SSL Certificate", as I

Re: Just change expiry time

On 30.12.2008 13:49, Michael Ströder wrote: I see no problem the schedule the removal of a trust flag. For security reasons all users have to update browsers from time to time anyway. ;-} Yup, that's the low-tech version of effectively doing the same. And it gives more flexibility. _

A business model

I have an idea for a nice "make money fast" business model: I'll make a CA. I'll talk about trust-worthiness and doing sophisticated verifications etc.. In my guidelines and processes, I say that I'll offer "HighSec high security certificates", where I'll get the in-person signature and passpo

Re: Just change expiry time

On 30.12.2008 17:28, Nelson B Bolyard wrote: Before any more people promote the removal of trust flags, I suggest you read https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c11 Yes, granted. But - we can yank the entire root. I *think* that's what Michael meant. It may or may not be wha

MD2

On 30.12.2008 17:39, 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 in general) stop supporting MD5 for use in digital signatures. What is MD2? Is that a weaker predecessor of MD5? According to Wikipedia

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

On 30.12.2008 17:49, Chris Hills wrote: On 30/12/08 17:47, Nelson B Bolyard wrote: I meant to add: The paper with the real facts is seen at http://www.win.tue.nl/hashclash/rogue-ca/ In the meantime, could a list of the affected CA's be made available so that we may remove the trust bits from

Re: Unbelievable!

On 27.12.2008 13:34, Gervase Markham wrote: sayrer wrote: The truth is that we are basically unable to act without a lot of collateral damage. We should keep this in mind with future security technology. Relying on companies willing to take money for doing absolutely nothing (not even the ba

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

On 30.12.2008 19:50, Michael Ströder wrote: 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 in general) stop supporting MD5 for use in digital signatures. It would be nice if the user could define in

Re: PositiveSSL is not valid for browsers

On 30.12.2008 12:43, Ian G wrote: PositiveSSL Certificates are low assurance level Secure Server Certificates from Comodo ideal for mail servers and server to server communications. They are not intended to be used for websites conducting e-commerce or transferring data of value. ... Due to the i

Re: PositiveSSL is not valid for browsers

On 30.12.2008 20:51, Frank Hecker wrote: Ben Bucksch wrote: "not intended for ... e-commerce. ... the certificates carry no warranty" Ben, this is a pretty common disclaimer that CAs (including CAs other than Comodo, I believe) make for DV certs (i.e., certs for which only the doma

Re: PositiveSSL is not valid for browsers

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

Re: A business model

Florian, I think you refer to cert issued to spammers holding a domain, and getting a DV cert for that domain that they registered? The cert is issued correctly for the domain, just the organization does not do clean business. This is a totally different issue. I am talking about a phisher bei

EV/OV/DV (was: PositiveSSL is not valid for browsers)

FWIW: On 31.12.2008 15:47, Eddy Nigg wrote: EV is clearly maximum No. EV is what I always expected all certs to be. It's really the minimum. The whole security hangs of a phone call. It has lots of loopholes. For me, anything less is rather pointless. DV: verify via http or plaintext mail -

Email signatures using MD5 (was: MD5 broken, certs whose signatures use MD5 now vulnerable)

On 31.12.2008 03:26, Nelson B Bolyard wrote: Dan, I believe Paul was suggesting that he did not want to see signatures on email messages themselves be invalidated just because they use MD5. The email messages themselves have different vulnerability characteristics than the signatures on the cer

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. Very good point. Indeed, I don't want to trust the security

Re: Full Disclosure!

On 03.01.2009 04:59, Eddy Nigg wrote: The report is available from here: https://blog.startcom.org/?p=161 That's surely interesting, but the report does not contain any details of interest. It only says "The attack ... involved proxying ,intercepting all communication from and to the browse

Re: Full Disclosure!

On 03.01.2009 07:18, Eddy Nigg wrote: The validations wizard allows for a selection of a few possible email addresses considered for administrative purpose or as listed in the whois records of the domain name. The flaw was, that insufficient verification of the response at the server side was p

Fully open operation (was: Full Disclosure!)

On 03.01.2009 16:48, Eddy Nigg wrote: ...I wouldn't be willing to disclose each and every detail of code, preventive measures, controls and procedures and possible events. Well, I think this might be a good idea, though. I could even go so far as to demand that all operations of the CA, includ

Re: PositiveSSL is not valid for browsers

On 03.01.2009 15:54, Florian Weimer wrote: The EV process does not verify ... that it is the legal entity which controls the domain name mentioned in the Common Name field. Are you saying that Fluff, Inc. could get a cert for mozilla.org, assuming Fluff, Inc reveal its legal identity? ___

Re: Full Disclosure!

On 03.01.2009 20:01, Eddy Nigg wrote: the other layers of defense Please don't call the blacklist a real "layer of defense". If he didn't try to get a cert for paypal.com, it would have worked. All layers failed. Please be honest enough to yourself to admit that, so that you can try to find

Re: Full Disclosure!

On 03.01.2009 20:03, Eddy Nigg wrote: On 01/03/2009 09:03 PM, Nelson B Bolyard: I hate to say it, but it's possible for the browser user to change those values without either (a) modifying the browser or (b) using some proxy tool. I don't know another way, but I'm glad to learn how. You can

Re: PositiveSSL is not valid for browsers

On 03.01.2009 18:09, Florian Weimer wrote: Are you saying that Fluff, Inc. could get a cert for mozilla.org, assuming Fluff, Inc reveal its legal identity? Yes, that's the essence. Well, that's a hole large enough that you can drive a trunk through. I'm sure it's pretty easy to

Re: CAs and external entities (resellers, outsourcing)

On 31.12.2008 19:57, Frank Hecker wrote: 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 VeriS

Re: Fully open operation

On 04.01.2009 19:54, David E. Ross wrote: The line from auditor to the public has been drawn in the courts, where lawsuits against auditors by investors injured by corporate fraud have been successful. Yes. But as Ian pointed out, and you can see in the audit documents, e.g.

Re: Proposal to split this list

On 05.01.2009 01:35, Nelson B Bolyard wrote: There's no mozilla.policy hierarchy. It can be created. There's already a mozilla.governance, which would fit there, too. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.moz

Re: Proposal to split this list

On 05.01.2009 01:00, Eddy Nigg wrote: A dev.security...yes, the forgotten step child of crypto. At times we used to post there (and cross post to crypto) and don't know why crypto became the de-facto list for all CA/SSL/Policy related issues. Because crypto (including CA) is just a small a

Re: CABForum place in the world

On 07.01.2009 17:16, Ian G wrote: That is, if Phishing and Malware and XSS and website hacks and identity-is-credit and any number of other things are causing so many losses in the good ol' US of A and the other identity-fraught markets ... so much so that the FBI bothers to measure them ... th

Re: CABForum place in the world

On 07.01.2009 17:16, Ian G wrote: That is, if Phishing and Malware and XSS and website hacks and identity-is-credit and any number of other things are causing so many losses in the good ol' US of A and the other identity-fraught markets ... so much so that the FBI bothers to measure them ... th

Re: CABForum place in the world

On 08.01.2009 14:46, Johnathan Nightingale wrote: - All of this would be better with KCM, which is why I filed this bug to discuss the possibility. https://bugzilla.mozilla.org/show_bug.cgi?id=kcm Thank you! Fantastic proposal, thanks for having the guts to challenge status quo and seriously

Re: A / V / Text encryption methods

Hi D3something, as Ian said, ignore Skype. Look at open-source video chat apps (there are a few). Then look at open source crypto libs (openssl, maybe NSS, etc.), and crypto email solutions (esp. GPG), and crypto chat solutions (e.g. GPG in Jabber) and how the key exchange works. Then think ab

Key Continuity Management

https://bugzilla.mozilla.org/show_bug.cgi?id=kcm (= bug 398721) Based on request by Johnathan in mailman.1145.1231422435.4224.dev-tech-cry...@lists.mozilla.org , and by Nelson in the bug (to keep out advocacy), I hereby open a thread to work out the technical details how we could make that wor

Cert expiry with Key Continuity Management

On 08.01.2009 22:09, Ben Bucksch wrote: * How to deal with cert expiry A possible solution (already posted in comment 18 in the bug): * Require website owners to continue using the same private key. * A fingerprint of that private key is put in the certificate. * We store on first

Re: CABForum place in the world

On 08.01.2009 23:35, Eddy Nigg wrote: On 01/08/2009 11:44 PM, Ian G: Well, what Firefox does is cert-exception-click-thru-ordeal; whereas people are asking for key-continuity-management, with perhaps the emphasis on the last word. Well, is it than an endorsement for self-signed certs? It's

Re: Cert expiry with Key Continuity Management

On 08.01.2009 23:15, Nelson B Bolyard wrote: I encourage people to read through that bug, especially the early comments, before contributing here. (The later comments are mostly "me too") Esp. because the first are from you (and are dissenting, and therefore important, while agreeing comments a

Re: CABForum place in the world

On 01/09/2009 01:12 AM, Ben Bucksch: It's not an *endorsement*, but making it possible to use them without fat warning Which is exactly the same thing... No. "Make it possible" and "endorse" are two entirely different things. the longer a key is used the bett

Re: Cert expiry with Key Continuity Management

Advocacy: One of the core assumptions of the x.509 world is ONE SIGNATURE, and ONE AUTHORITY. Thing is: There is no one authority :-). God doesn't issue SSL certificates. Apart from him, I trust only me and my friends. Different school of thought. Yes, definitely. It's the reason why S/

Re: Cert expiry with Key Continuity Management

First off, please note that this is a proposed *change* to the PKI system. A small change, but nevertheless a change, yes. We're trying to make it more secure. So, "That goes against current definitions" is not an argument, it's inherent. No, the question OCSP asks is ... "is this cert revok

Re: Cert expiry with Key Continuity Management

On 09.01.2009 05:32, Ben Bucksch wrote: The OCSP responder is also allowed to forget about the revocation status of any cert that's outside its validity period. Our CAs would not be allowed to do that. It's fairly trivial to keep the whole list. P.S. That wouldn't even be str

Re: Cert expiry with Key Continuity Management

On 09.01.2009 02:15, Robert Relyea wrote: Ben Bucksch wrote: Advocacy: One of the core assumptions of the x.509 world is ONE SIGNATURE, and ONE AUTHORITY. Thing is: There is no one authority :-). God doesn't issue SSL certificates. Apart from him, I trust only me and my friends. T

Re: Cert expiry with Key Continuity Management

Hi Robert, thanks for the reply. I think there are two major misconceptions, at least one of them my fault: * I am not proposing to mandate that the private key stays the same (contrary to what my original bullet list said). I am merely proposing that the new key is signed by the

Re: A / V / Text encryption methods

On 09.01.2009 03:56, Julien R Pierre - Sun Microsystems wrote: Of course, when it comes to audio and video chat, part of the very data that's being transferred can serve to authenticate the other party (voice print, video), somewhat reducing the need for transport-level authentication ... This

Re: Suggestion: Announce date for MD5 signature deactivation

On 09.01.2009 18:51, Johnathan Nightingale wrote: SHA-1 is heading that way as well, and the decisions we make here will likely shape policy for SHA-1's eventual decommissioning as well. I think it's important to prepare now that we actually *can* decommission SHA-1. This means: * All popular

Re: Cert expiry with Key Continuity Management

On 13.01.2009 09:48, Rob Stradling wrote: I made a similar suggestion to ietf.pkix in October 2006. See... http://www.imc.org/ietf-pkix/mail-archive/msg01964.html ...and the rest of that thread, including... http://www.imc.org/ietf-pkix/mail-archive/msg01984.html ... Ben, I agree that having m

OT: mozilla.org domain ownership

On 13.01.2009 23:09, Gervase Markham wrote: Mozilla Corporation is listed as the registrant owner of mozilla.org in WHOIS. FWIW, I think that should be fixed. mozilla.org is owned by the project. The project is currently is legally represented by the Foundation (that's its purpose). It's fine

Re: OT: mozilla.org domain ownership

On 14.01.2009 20:28, Johnathan Nightingale wrote: On 14-Jan-09, at 2:03 PM, Ben Bucksch wrote: Foundation must hold the end of the string that controls it all - both legally (board etc.) and technically (domain ownership, repo backup copy (which luckily everybody has, so no problem)). What

Re: OT: mozilla.org domain ownership

On 15.01.2009 16:06, Johnathan Nightingale wrote: I see. And what if, given that the foundation is a small entity with few full time employees, they decided to contract out the management of the technical side of things to, e.g., the Mozilla Corporation? They are already doing that. I am not

Re: OT: mozilla.org domain ownership

On 15.01.2009 18:27, Reed Loden wrote: Well, if you really want to go as far as to want mozilla.org's owner to be MoFo, what do you say about the O= in the SSL certificate for *.mozilla.org? The O= is currently Mozilla Corporation, rather than Mozilla Foundation. I don't care, myself. Not sur

Re: Cert expiry with Key Continuity Management

On 23.01.2009 12:14, Rob Stradling wrote: For the additional signature(s) to become especially useful, the primary signature on the certificate would need to be substantially broken (e.g. by a pre-image attack on the hash algorithm). But if this happened, it is likely that the CA would revoke th

Re: Fully open operation

On 14.01.2009 18:49, Ian G wrote: In _Rampell_ [2]: "... Those audits are relied on not only by the clients on whose financial matters audits are performed but upon a host of other individuals and entities who may rely on the information in making their own economic decisions. Audited statemen

Re: DSV/S-TRUST root inclusion request

On 16.12.2008 18:43, Frank Hecker wrote: S-TRUST is operated by Deutscher Sparkassenverlag (DSV) Just a little background on this: Sparkasse is a "mutual savings bank". They are fairly popular in Germany: Every region has its own (and their geographical coverage usually does not overlap much)

Re: DSV/S-TRUST root inclusion request

On 16.12.2008 23:04, Frank Hecker wrote: However I suspect that S-TRUST is constrained in its practices by the relevant German laws and/or EU directives. Unfortunately I couldn't find any references that address this particular issue. Even if so, such a law wouldn't preclude a root *specifical

Re: DSV/S-TRUST root inclusion request

(OT: Just culture) On 17.12.2008 13:11, Ian G wrote: Have they legislated that pi is 3 again? Welcome to Europe, we hope you enjoyed your flight, and will travel on pi airlines around the globe again :) For the record, it was the US - Indiana specifically - which legislated pi, see a quick

Re: Proposal to split this list

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 think it's more than bikeshed: I do not think that CA po

Re: Proposal to split this list

On 09.02.2009 17:45, Ian G wrote: I've posted something ... hopefully non-contraversial ...: a suggestion on the list charter. That was a good one. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

On 10.02.2009 02:23, Nelson B Bolyard wrote: I'd post this in the policy working group, if that was operational ... :( In our esteemed Kathleen Wilson wrote: According to https://wiki.mozilla.org/CA:How_to_apply “If there are no open issues or action items after the first discussion perio

Re: how do we agree?

On 13.02.2009 16:15, Ben Bucksch wrote: Ian, I also disagree with your change. CPS IMHO must be public, period. It's important for "Relying parties". The CPS is the only thing that shows what the CA actually does and warrants to relying parties. Even more so must the "r

Re: how do we agree?

On 12.02.2009 20:11, Ian G wrote: On 11/2/09 21:26, Eddy Nigg wrote: On 02/11/2009 06:43 PM, Ian G: OK, I made some changes on the wiki For reference, Ian added, and Eddy reverted: (old text) The CP/CPS should be publicly available from the CA's official web site (added text) (we re

Re: how do we agree?

On 13.02.2009 16:56, Ian G wrote: But it isn't me that sets the criteria, it is in this case ETSI, and the *policy* clearly says that ETSI is acceptable, and apparently ETSI say non-publication is ok. FWIW, this is irrelevant. *We* require the ETSI. We can also require additional requirements

Re: how do we agree?

On 13.02.2009 20:37, kathleen95...@yahoo.com wrote: Certigna’s CPS contains sensitive information that cannot be posted publicly at this time. As such, the following possible solutions are recommended: 1) Publish a version of the CPS with the confidential material redacted. Yeah, that's fin

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

On 03.05.2009 09:06, Ian G wrote: (5) possibly as consequence of all the above, it can be claimed that it is an empty threat, and no more than a security/marketing tool for PKI people. Consequently, we need to either: * Make that threat not empty * Create other ways to make CAs behave when the

EV guidelines

rming that he/she did sign the applicable document". Maybe I have overlooked something, but I could give them the address of eBay, or my address with an eBay sign, and *my* phone number, sign the doc, and then when they call me, greet with "Ben Bucksch of eBay speaking" and confi

Applicability of SSL / use-cases

(Followup-To m.d.t.crypto) In private discussion, Eddy of StartCom suggested SSL CA certs for * internal sites (company webmail/IMAP, VPN etc.) * private discussion (blogs, forums, chat) * generally everything where you supply a login/password. I think other solutions are more appropriate

mxr.mozilla.org (was: AltIssuerName)

David Stutzman wrote: BTW, on an unrelated note, does anyone know the difference between lxr.mozilla.org and mxr.mozilla.org? #developers topic says: please test http://mxr.mozilla.org/ the code might land as http://lxr.mozilla.org I originally went here: http://mxr.mozilla.org/security/sou

Re: mxr.mozilla.org

David Stutzman wrote: Then I clicked on Security (http://mxr.mozilla.org/security/) In the "Text Search" box I typed "CERTCertificateStr" and clicked Find. Scrolled down to: /data/lxr-data/security/mozilla/security/nss/lib/certdb/certt.h, * line 76 -- typedef struct CERTCertificateStr CER

Setting the hostname to verify the cert against

I am trying to implement XMPP, in chrome-JS. XMPP resolves the server hostname using DNS SRV lookups, so if I want to get the server for "foo.com", I may end up with e.g. "abcdxmpp.foo.com" as hostname. The user opened the connection to "foo.com", though, and the SSL certificate is for "foo.co

Re: Setting the hostname to verify the cert against

On 24.01.2011 06:54, Kaspar Brand wrote: You're looking for SSL_SetURL (http://mxr.mozilla.org/mozilla/ident?i=SSL_SetURL) Thanks! but note that this is currently not exposed to JS land... maybe something to add to PSM's nsNSSSocketInfo? Meh! It's an extension to be deployed to customers in

Re: Setting the hostname to verify the cert against

On 24.01.2011 12:38, Ben Bucksch wrote: Worst comes to worst, I can always override the cert error, and do the check myself, but that's going to get quite ugly. I have to say the PSM IDL interfaces are coming right out of the black hole. I implement nsIBadCertListener2 and nsISSLErrorLis

Re: Setting the hostname to verify the cert against

On 24.01.2011 15:10, Ben Bucksch wrote: In my nsIBadCertListener2::notifyCertProblem(), I try to getInterface(nsITransportSecurityInfo) from socketInfo, because nsNSSIOLayer.cpp::nsNSSBadCerthandler() lines 3348 and 3577 suggest that it should be a nsNSSSocketInfo object, which implements

Re: Setting the hostname to verify the cert against

01.2011 16:09, Ben Bucksch wrote: * check what the exact error is, and handle "hostname mismatches cert" error only (OPEN - that's why I tried to get the nsITransportSecurityInfo.errorMessage above, so I don't know how to achieve that) * override that err

Re: Setting the hostname to verify the cert against

On 24.01.2011 19:36, Marsh Ray wrote: The correct solution would be to fix the certificate on the server. No, actually, that would be a security bug. XMPP (better known as "Jabber", "Google Talk" etc.) uses DNS SRV lookups to find the hostname of a server. For the user, the connection just go

Re: Setting the hostname to verify the cert against

Just to be clear, to avoid confusion: this was a pure programming question, not a server admin or PKI setup question. I write a client for an existing standard protocol, and it's supposed to work with the existing servers, over which I have no control. Ben -- dev-tech-crypto mailing list dev-t

Re: Setting the hostname to verify the cert against

On 26.01.2011 00:02, Honza Bambas wrote: Ben, proxy info (the last argument) could make a trick for you. Fill proxy info with host:port of the server (as it actually stands as a proxy between the two clients). Let host name passed to createTransport() be the name of the [cert]. Thanks for t

CCC security conference 31C3

"Largest hacker conference in the free world". Running at the moment. All talks made available on video. Many talks in English. German talks should be translated to English, in the order of interest. "Hacking" here means "Having fun using devices in creative/new ways" and anything security-relate