Re: [FORGED] Re: CA generated keys

[Michael Ströder via dev-security-policy]

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

[Michael Ströder]

Peter Gutmann wrote:
> Ryan Sleevi  writes:
> 
>> 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

[Michael Ströder]

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

[Michael Ströder]

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

[Michael Ströder]

Peter Gutmann wrote:
> Rob Stradling  writes:
> 
>> 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

[Michael Ströder]

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

[Michael Ströder]

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

[Michael Ströder]

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?

[Michael Ströder]

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?

[Michael Ströder]

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