Re: [FORGED] Re: CA generated keys
Matthew Hardeman wrote: > On Wednesday, December 13, 2017 at 5:52:16 PM UTC-6, Peter Gutmann wrote: >> In all of these cases, the device is going to be a safer place to generate >> keys than the CA, in particular because (a) the CA is another embedded >> controller somewhere so probably no better than the target device and (b) >> there's no easy way to get the key securely from the CA to the device. > > Agreed, as I mentioned the secure transport aspect is essential for > remote key generation to be a secure option at any level. I have strong doubts that all these Internet-of-shitty-things manufactures will get ever anything like this right. I agree with Peter: Private key generation is the least you have to worry about when using such devices. Also I'm seriously concerned that if the policy is changed to allow CA-side key generation and this gets adopted, the CAs will be forced to implement key escrow disclosing keys to . => Mozilla policy *shall not* be changed to allow CAs to generate the end entities' keys. (The only reasonable use-case for a CA generating the private keys is to ensure that they are immediately stored in a secure device. But that's not really applicable in this broad use-case.) Ciao, Michael. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom & Qihoo Incidents
Peter Gutmann wrote: > Ryan Sleeviwrites: > >> What is the goal of the root program? Should there be a higher bar for >> removing CAs than adding them? Does trust increase or decrease over time? > > Another thing I'd like to bring up is the absolute silence of the CAB forum > over all this. Apple have quietly unilaterally distrusted, Mozilla have > debated at length (three months now) and are taking action, but the regulatory > body that should be taking charge, the CAB forum, has (apparently) taken > absolutely no action. > > Does anyone know the position among other browser vendors, Chrome, IE, Opera, > Konqueror, Chromium, Midori, the dozen or more forks of various bigger > browsers, the dozens(?) of mobile browsers, and so on. Most Linux distributions ship a package like "ca-certificates-mozilla" which simply copies the Mozilla trusted CA cert set and converts it into several trust store formats. So the impact is much broader besides web browsers even affecting e.g. MTA-MTA SMTP communication. (Yes, I fully understand that Mozilla refuses to take responsibility for that.) Ciao, Michael. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incidents involving the CA WoSign
Gervase Markham wrote: > On 07/10/16 04:21, Peter Gutmann wrote: >> That still doesn't necessarily answer the question, Google have their CRLSets >> but they're more ineffective than effective in dealing with revocations >> (according to GRC, they're 98% ineffective, >> https://www.grc.com/revocation/crlsets.htm). > > That statistic assumes that all revocations are equal, which is clearly > not true. A revoked cert for www.google.com is orders of magnitude more > important to Chrome users than one for www.gerv.net. Which "Chrome users"? Sure there are some users (at least me) for which my domains are "high-value domains" and much more important than the Google domains. Ciao, Michael. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 exception First Data
Dean Coclin wrote: > First Data's customers don't use browsers so Firefox can disable SHA-1 > tomorrow > and not affect them. So why to have your CA certificate trusted in Firefox's cert DB? > First Data has asked for a reasonable extension which doesn't affect browsers. If it does not "affect browsers" why do you need an extension? Ciao, Michael. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incidents involving the CA WoSign
Peter Gutmann wrote: > Rob Stradlingwrites: > >> Easy. It doesn't make a sound. Unrevoked certificates don't make sounds >> either. > > What I was really asking, in a tongue-in-cheek way, was whether there was any > indication of how successfully the information could be propagated to > browsers. Since the heroic Mozilla devs removed CRL support from Firefox, nope. Ciao, Michael. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: address prefixes allowed for domain control validation
Peter Bowen wrote: On Sun, Mar 22, 2015 at 4:18 PM, Kathleen Wilson kwil...@mozilla.com wrote: admin@domain administrator@domain webmaster@domain hostmaster@domain postmaster@domain What do you all think? (Note this is also in Baseline Requirements section 11.1.1) It is hard to know which to remove without any data on how customers are using these today. I would guess that admin administrator are the more problematic ones, as they are not covered in any RFCs. The other three are in http://tools.ietf.org/html/rfc2142. Sorry for the late reply. But the main problem in the cases mentioned before was that one of those local parts could be freely chosen for the domain. So the really hard requirement is: The domain owner must blacklist all those white-listed local parts when users can choose their e-mail address for a domain. The CA cannot do much about it. If one thinks about removing some of the local parts from the white-list the hope is to raise the *likelihood* that the local part is already blocked by the true domain owner and cannot be freely chosen. Ideally if a CA sends a challenge to such an administrative e-mail address a cautious admin could notice a possible fraud and additionally inform the CA what's going on. Hmm, relying on one admin e-mail alias seems to be not really sufficient. So how about sending separate validation challenge e-mails to more than one of those white-list addresses? This would also raise the likelihood of hitting a reserver mailbox. How about requiring three challenge mails to admin mailbox addresses? Or how about an even broader weighted list and a minimum treshold? Being domain owner I would not mind the extra work grabbing more than one e-mail from my domain admin catch-all mailbox. Ciao, Michael. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Name Constraints
Ryan Sleevi wrote: Given that sites in consideration already have multiple existing ways to mitigate these threats (among them, Certificate Transparency, Public Key Pinning, and CAA), Any clients which already make use of CAA RRs in DNS? Or did you mean something else with the acronym CAA? Ciao, Michael. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Client certs
Gervase Markham wrote: A question which occurred to me, and I thought I'd put before an audience of the wise: * What advantages, if any, do client certs have over number-sequence widgets such as e.g. the HSBC Secure Key, used with SSL? http://www.hsbc.co.uk/1/2/customer-support/online-banking-security/secure-key It seems like they have numerous disadvantages (some subjective): * Client certs can be invisibly stolen if a machine is compromised * Client certs are harder to manage and reason about for an average person * Client certs generally expire and need replacing, with no warning * Client certs are either single-machine, or need a probably-complex copying process What are the advantages? With client certs you don't need online access to a server backend infrastructure like for all the OTP mechs. Revocation checks can be done with simple CRLs. So it's far easier at the server's side. Ciao, Michael. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
Kathleen Wilson wrote: In the case of EV certs, Mozilla is still checking the CRL when the OCSP URI is not provided. Which CRL? Where does it come from? Though, I believe the plan is to stop checking CRL in the future... https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34 Instead of checking explicitly for an OCSP responder URI in the AIA extension, let's simply remove the support for downloading CRLs from Firefox's EV checking. That will have the effect of enforcing that all certs in the chain have an OCSP AIA extension, except possibly for the end-entity certificate if the server stapled the end-entity OCSP response. I agree with the CA representatives that a missing OCSP AIA URL isn't harmful when a stapled OCSP response is provided. So, I am OK with allowing that exception, at least for now. Anyone writing such a non-sense surely is on NSA's payroll. Ciao, Michael. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
Kaspar Brand wrote: Another 10 days have passed without any apparent sign of Mozilla's willingness to address the case of the non-existence of an OCSP responder for the Cybertrust SureServer EV CA. And since CRL support was dropped in recent Firefox/Seamonkey releases there's no revocation checking mechanism for those certs at all. Otherwise, the CA Certificate Policy is definitely becoming nothing but a farce (cf. e.g. item 2 of the Inclusion Policy, a public process, based on objective and verifiable criteria), and the Enforcement Policy in particular will remain a paper tiger in all eternity. Is that news to you? The policy discussions here are just security theater - since years... Ciao, Michael. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy