Re: Revoking Trust in one ANSSI Certificate

On Mon, Dec 9, 2013 at 2:17 PM, Jan Schejbal jan.schejbal_n...@gmx.dewrote: I would really love to see the explanation how someone accidentally issues and deploys a MitM Sub-CA... I think it will turn out to be essentially the same reason that Microsoft got burned with the Flame attack.

Re: Exceptions to 1024-bit cert revocation requirement

I thought that what we were trying to do here is break a deadlock where Cas wait for browsers and vice versa. I have no trouble telling a customer with a 15 year 512 bit cert that they need to change for a new one if they want it to work for ssl with the browsers Revoking it without their

Re: Exceptions to 1024-bit cert revocation requirement

On Mon, Dec 23, 2013 at 8:54 AM, Rob Stradling rob.stradl...@comodo.comwrote: On 21/12/13 22:57, Phillip Hallam-Baker wrote: I thought that what we were trying to do here is break a deadlock where Cas wait for browsers and vice versa. I have no trouble telling a customer with a 15 year 512

Re: Stop using SHA1 in certificates

The hashclash attack requires the CA to do more than just use SHA-1. They have to use a predictable serial number. That is not an argument for not withdrawing SHA-1 toute haste. It is however a reason for folk not to do the usual headless chicken thing. Striking out SHA-1 effectively means the

Re: Which SHA-2 algorithm should be used?

On Wed, Jan 8, 2014 at 8:34 PM, Peter Gutmann pgut...@cs.auckland.ac.nzwrote: Man Ho (Certizen) ma...@certizen.com writes: If there is no constraints on choosing SHA-256, SHA-384 or SHA-512, why CAs are so conservative and prefer SHA-256 rather than SHA-512? I think going directly to a

Re: Revocation Policy

Before we get any further into this conversation, I'll just point out that business models are not something we can discuss in CABForum. We can 'probably' tell you what we believe the rules to be but we can't make any comment on what they should be either in CABForum or here. On Thu, Apr 10,

Re: Turn on hardfail?

If there was a DoS attack it would be the first and the last. OCSP is only a DoS issue for servers that don't staple. All modern servers can staple if configured to do so. Further it is only the weaker CAs that don't have DoS proof OCSP service. So if there was a DoS attack we would see a sudden

Re: OCSP and must staple

have any update on the status of the must-staple OID? -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Brian Smith Sent: Thursday, April 10, 2014 5:06 PM To: Phillip Hallam-Baker Cc: dev-security-policy

Re: Short-lived certs

On Thu, Sep 4, 2014 at 6:43 PM, Ryan Sleevi ryan-mozdevsecpol...@sleevi.com wrote: On Thu, September 4, 2014 11:20 am, Phillip Hallam-Baker wrote: Some constraints: 1) Any new scheme has to work equally well with legacy browsers and enabled browsers. Sure. However, this requires

Re: Short-lived certs

On Fri, Sep 5, 2014 at 5:30 AM, Gervase Markham g...@mozilla.org wrote: On 04/09/14 14:25, Rob Stradling wrote: When attempting to access an HTTPS site with an expired cert on Firefox 32, you'll see a This Connection is Untrusted page that lets you add an exception and proceed. But when

Re: Short-lived certs

+1 Short lifetime certs don't solve every problem with revocation. But they allow us to drastically reduce the problem space. That makes applying other mechanisms viable. The end goal has to be to reduce the time window of vulnerability to the time it takes people to respond to phishing sites

Re: Client certs

On Thu, Sep 25, 2014 at 8:29 AM, Gervase Markham g...@mozilla.org 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?

Re: Client certs

A relevant point here is that one of the main reasons for the difficulty in using client certs was a preposterous patent claim to the implementation of RSA in a hardware device with a USB serial interface. I kid you not. That might not be as much of an issue these days. The patent might have

Re: New free TLS CA coming

On Thu, Nov 20, 2014 at 6:22 AM, Richard Barnes rbar...@mozilla.com wrote: I am from Mozilla, and the replies here are exactly right. From the perspective of the Mozilla root CA program, Let's Encrypt will be treated as any other applicant, should they choose to apply. No immediate

Re: DSA certificates?

DSA was the mandatory to implement algorithm originally since that was out of patent earlier than RSA. I would like to kill as many unused crypto implementations as possible. The algorithm might be sound but an implementation that has never been used in practice is a huge liability. On Tue,

Re: Name Constraints

On Mon, Mar 9, 2015 at 11:38 AM, Michael Ströder mich...@stroeder.com wrote: 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

Re: Tightening up after the Lenovo and Comodo MITM certificates.

On Wed, Feb 25, 2015 at 8:59 AM, Peter Kurrasch fhw...@gmail.com wrote: I'm not sure I totally follow here because informed consent requires the ability to inform, and I don't think we have that yet. The way any attacker operates is to find gaps in a system and make use of them. In my

Re: Requirements for CNNIC re-application

CT is an accountability control, not an access control We need both Sent from my difference engine On Apr 14, 2015, at 18:05, Matt Palmer mpal...@hezmatt.org wrote: On Tue, Apr 14, 2015 at 01:38:55PM +0200, Kurt Roeckx wrote: On 2015-04-14 01:15, Peter Kurrasch wrote: Let's use an

Re: Requirements for CNNIC re-application

On Tue, Apr 14, 2015 at 8:09 AM, Kurt Roeckx k...@roeckx.be wrote: On 2015-04-14 13:54, Rob Stradling wrote: On 14/04/15 12:38, Kurt Roeckx wrote: On 2015-04-14 01:15, Peter Kurrasch wrote: Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov and let's further suppose

Re: Consequences of mis-issuance under CNNIC

On Thu, Apr 2, 2015 at 11:05 AM, Kurt Roeckx k...@roeckx.be wrote: On 2015-04-02 16:34, Phillip Hallam-Baker wrote: Further no private key should ever be in a network accessible device unless the following apply: 1) There is a path length constraint that limits issue to EE certs. 2

Re: Policy Update Proposal: Remove Code Signing Trust Bit

On Fri, Oct 2, 2015 at 12:36 PM, Brian Smith wrote: > -- Forwarded message -- > From: Brian Smith > Date: Thu, Oct 1, 2015 at 7:15 AM > Subject: Re: Policy Update Proposal: Remove Code Signing Trust Bit > To: Gervase Markham

Re: Policy Update Proposal -- Specify audit criteria according to trust bit

On Tue, Sep 22, 2015 at 4:47 AM, Brian Smith wrote: > Kathleen Wilson wrote: > > > Arguments for removing the Email trust bit: > > - Mozilla's policies regarding Email certificates are not currently > > sufficient. > > - What else? > > > > > * It isn't

Re: [FORGED] Re: Policy Update Proposal -- Remove Email Trust Bit

On Fri, Sep 25, 2015 at 8:47 AM, Peter Gutmann wrote: > Eric Mill writes: > > >can anyone lay out what the steps to doing that would look like so the > S/MIME > >community can react in more concrete ways? > > Well, first you'll have to tell the

Re: Nation State MITM CA's ?

On Thu, Jan 7, 2016 at 2:00 PM, Kathleen Wilson wrote: > On 1/6/16 3:07 PM, Paul Wouters wrote: >> >> >> As was in the news before, Kazakhstan has issued a national MITM >> Certificate Agency. >> >> Is there a policy on what to do with these? While they are not trusted, >>

Re: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ?

It really isn't a good idea for Mozilla to try to mitigate the security concerns of people living in a police state. The cost of doing so is you will set precedents that others demand be respected. Yes providing crypto with a hole in it will be better than no crypto at all for the people who

Re: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ?

On Tue, Jan 12, 2016 at 11:46 AM, Jakob Bohm <jb-mozi...@wisemo.com> wrote: > On 12/01/2016 16:49, Phillip Hallam-Baker wrote: >> >> It really isn't a good idea for Mozilla to try to mitigate the >> security concerns of people living in a police state. The cost of

Re: When good certs do bad things

On Fri, Jun 3, 2016 at 2:03 PM, Nick Lamb wrote: > On Friday, 3 June 2016 17:25:11 UTC+1, Peter Kurrasch wrote: > > Regarding use of the term "bad", what does anyone think about this as an > alternative: "furtherance of criminal activity" > > As far as I'm aware all of the

Re: [FORGED] Re: Nation State MITM CA's ?

On Mon, Jan 11, 2016 at 1:45 PM, Jakob Bohm wrote: > On 09/01/2016 19:22, Kai Engert wrote: >> >> On Sat, 2016-01-09 at 14:11 +, Peter Gutmann wrote: >>> >>> That would have some pretty bad consequences. With the MITM CA cert >>> enabled, >>> Borat [0] can read every

Re: Private PKIs, Re: Proposed limited exception to SHA-1 issuance

On Mon, Feb 29, 2016 at 7:09 AM, Peter Gutmann wrote: > Jürgen Brauckmann writes: > >>Nice example from the consumer electronics world: Android >= 4.4 is quite >>resistant against private PKIs. You cannot import your own/your corporate >>private

Re: StartEncrypt considered harmful today

On Thu, Jun 30, 2016 at 12:46 PM, Juergen Christoffel < juergen.christof...@zv.fraunhofer.de> wrote: > On 30.06.16 18:24, Phillip Hallam-Baker wrote: > >> What makes something easy to hack in Perl does not make for good security >> architecture. >> > > Bad d

Re: StartEncrypt considered harmful today

Argh As with Etherium, the whole engineering approach gives me a cold sweat. Security and scripting languages are not a good mix. What makes something easy to hack in Perl does not make for good security architecture. :( On Thu, Jun 30, 2016 at 11:30 AM, Rob Stradling

Re: Implementing a SHA-1 ban via Mozilla policy

Remember the DigiNotar incident? At the time, I thought that pulling the DigiNotar roots was exactly the right thing to do. I didn't say so as it isn't proper for people to be suggesting putting their competitors out of business. But I thought it the right thing to do. Not long after I was

Re: question about DNS CAA and S/MIME certificates

On Wednesday, May 16, 2018 at 2:16:14 AM UTC-4, Tim Hollebeek wrote: > This is the point I most strongly agree with. > > I do not think it's at odds with the LAMPS charter for 6844-bis, because I do > not think it's at odds with 6844. Updating 6844 is easy. Just define the tag and specify scope

Re: question about DNS CAA and S/MIME certificates

When I wrote CAA, my intention was for it to apply to SSL/TLS certs only. I did not consider S/MIME certs to be relevant precisely because of the al...@gmail.com problem. I now realize that was entirely wrong and that there is in fact great utility in allowing domain owners to control their

Re: Logotype extensions

On Wed, Jul 10, 2019 at 4:54 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Russ, > > > > Perhaps one of us is confused because I think we're saying the same thing - > that rules around inclusion of Logotype extensions in publicly-trusted > certs should

Re: Logotype extensions

On Wed, Jul 10, 2019 at 6:11 PM Wayne Thayer wrote: > On Wed, Jul 10, 2019 at 2:31 PM Phillip Hallam-Baker < > ph...@hallambaker.com> wrote: > >> On Wed, Jul 10, 2019 at 4:54 PM Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.m

Re: Logotype extensions

On Wed, Jul 10, 2019 at 2:41 PM housley--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, July 5, 2019 at 7:53:45 PM UTC-4, Wayne Thayer wrote: > > Based on this discussion, I propose adding the following statement to the > > Mozilla Forbidden Practices wiki

Logotype extensions

[Fixing the From] n Wed, Jul 10, 2019 at 6:11 PM Wayne Thayer wrote: > On Wed, Jul 10, 2019 at 2:31 PM Phillip Hallam-Baker < > ph...@hallambaker.com> wrote: > >> On Wed, Jul 10, 2019 at 4:54 PM Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.m

Fwd: Logotype extensions

[Fixing the From to match list membership] On Wed, Jul 10, 2019 at 2:41 PM housley--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, July 5, 2019 at 7:53:45 PM UTC-4, Wayne Thayer wrote: > > Based on this discussion, I propose adding the following statement

Fwd: Logotype extensions

On Wed, Jul 10, 2019 at 4:54 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Russ, > > > > Perhaps one of us is confused because I think we're saying the same thing - > that rules around inclusion of Logotype extensions in publicly-trusted > certs should

Re: Logotype extensions

On Thu, Jul 11, 2019 at 12:19 PM Wayne Thayer wrote: > On Wed, Jul 10, 2019 at 7:26 PM Phillip Hallam-Baker < > ph...@hallambaker.com> wrote: > >> Because then the Mozilla ban will be used to prevent any work on >> logotypes in CABForum and the lack of CABForum rules

Re: Logotype extensions

Like I said, expect to defend this in House and Senate hearings. This is a restraint of trade. You are using your market power to impede development of the market. Mozilla corp made no complaint when VeriSign deployed Issuer LogoTypes. On Tue, Jul 16, 2019 at 8:17 PM Wayne Thayer via

Re: Firefox removes UI for site identity

On Thu, Oct 24, 2019 at 5:31 PM Paul Walsh wrote: > So, the next time a person says “EV is broken” or “website identity can’t > work” please think about what I just said and imagine actual browser > designers and developers who were/are responsible for that work. They were > never given a chance

Re: Firefox removes UI for site identity

operations. > > On Wed, Oct 23, 2019 at 10:33 AM Phillip Hallam-Baker via > dev-security-policy wrote: > >> On Tue, Oct 22, 2019 at 7:49 PM Matt Palmer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >> > On Tue, Oct 2

Re: [FORGED] Re: Firefox removes UI for site identity

On Thu, Oct 24, 2019 at 9:54 PM Peter Gutmann via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Paul Walsh via dev-security-policy > writes: > > >we conducted the same research with 85,000 active users over a period of > >12 months > > As I've already pointed out weeks

Re: Firefox removes UI for site identity

On Tue, Oct 22, 2019 at 7:49 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, Oct 22, 2019 at 03:35:52PM -0700, Kirk Hall via > dev-security-policy wrote: > > I also have a question for Mozilla on the removal of the EV UI. > > This is a

Re: [FORGED] Re: Firefox removes UI for site identity

On Fri, Oct 25, 2019 at 4:21 AM James Burton wrote: > Extended validation was introduced at a time when mostly everyone browsed > the internet using low/medium resolution large screen devices that provided > the room for an extended validation style visual security indicator . > Everything has