On Friday, 1 December 2017 17:11:56 CET Ryan Sleevi wrote:
> On Fri, Dec 1, 2017 at 10:23 AM, Hubert Kario <hka...@redhat.com> wrote:
> > and fine for NSS too, if that changes don't have to be implemented in next
> > month or two, but have to be implemented before N
On Friday, 1 December 2017 16:33:10 CET Jakob Bohm via dev-security-policy
wrote:
> On 01/12/2017 16:23, Hubert Kario wrote:
> > On Friday, 1 December 2017 15:33:30 CET Ryan Sleevi wrote:
> >> On Fri, Dec 1, 2017 at 7:34 AM, Hubert Kario <hka...@redhat.com> wrote:
> &
On Friday, 1 December 2017 15:33:30 CET Ryan Sleevi wrote:
> On Fri, Dec 1, 2017 at 7:34 AM, Hubert Kario <hka...@redhat.com> wrote:
> > > It does feel like again the argument is The CA/EE should say 'I won't do
> >
> > X'
> >
> > > so that a cli
On Thursday, 30 November 2017 21:49:42 CET Ryan Sleevi wrote:
> On Thu, Nov 30, 2017 at 3:23 PM, Hubert Kario <hka...@redhat.com> wrote:
> > On Thursday, 30 November 2017 18:46:12 CET Ryan Sleevi wrote:
> > > On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario <hka...
On Thursday, 30 November 2017 18:46:12 CET Ryan Sleevi wrote:
> On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario <hka...@redhat.com> wrote:
> > if the certificate is usable with PKCS#1 v1.5 signatures, it makes it
> > vulnerable to attacks like the Bleichenbacher, if it is not u
On Wednesday, 29 November 2017 21:59:39 CET Ryan Sleevi wrote:
> On Wed, Nov 29, 2017 at 1:09 PM, Hubert Kario <hka...@redhat.com> wrote:
> > > So are you stating you do not believe cross-algorithm attacks are
> >
> > relevant?
> >
> > No, I don't bel
On Wednesday, 29 November 2017 17:00:58 CET Ryan Sleevi wrote:
> On Wed, Nov 29, 2017 at 7:55 AM, Hubert Kario via dev-security-policy <
>
> dev-security-policy@lists.mozilla.org> wrote:
> > Because I do not consider making the salt length rigid (one value allowed
&
On Monday, 27 November 2017 23:37:59 CET Ryan Sleevi wrote:
> On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario <hka...@redhat.com> wrote:
> > > So no, we should not assume well-meaning actors, and we should be
> >
> > explicit
> >
> > > about wha
On Monday, 27 November 2017 20:31:53 CET Ryan Sleevi wrote:
> On Mon, Nov 27, 2017 at 12:54 PM, Hubert Kario <hka...@redhat.com> wrote:
> > > On the realm of CA policy, we're discussing two matters:
> > > 1) What should the certificates a CA issue be encoded as
> &g
On Monday, 27 November 2017 17:28:02 CET Ryan Sleevi wrote:
> On Thu, Nov 23, 2017 at 7:07 AM, Hubert Kario via dev-security-policy <
>
> dev-security-policy@lists.mozilla.org> wrote:
> > In response to comment made by Gervase Markham[1], pointing out that
> > Mozilla
&
On Tuesday, 31 January 2017 09:27:30 CET Peter Bowen wrote:
> On Tue, Jan 31, 2017 at 5:50 AM, Hubert Kario <hka...@redhat.com> wrote:
> > On Monday, 30 January 2017 23:48:51 CET Peter Bowen wrote:
> >> See notes inline about known cities with numbers in their name.
> &g
asonable for a CA to rely upon ISO
> 3166.
No, they still exist:
https://en.wikipedia.org/wiki/Prague_1
http://www.praha1.cz/cps/index.html
(note the address at the bottom of the page)
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.
structure in the actual signature.
1 -
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-certificate-verify-malformed-sig.py
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45,
y, point 1 doesn't really need HTTPS, you could just slap a
> padlock into the UI and not bother with encryption. So it's mostly
> point 2.
I don't think that this level of cynicism is helping...
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat
ntity, always had, and unless they themselves start
hosting those websites, they have no way to certify trustworthiness of
the data served.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech R
tificates[1] does use Mozilla Root list and it does encompass Java
trust stores so Code Signing bits at the very least _should_ be used, if
not already are used.
1 - https://fedoraproject.org/wiki/Features/SharedSystemCertificates
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security
On Tuesday 09 June 2015 11:57:40 Rick Andrews wrote:
On Tuesday, June 9, 2015 at 3:05:30 AM UTC-7, Hubert Kario wrote:
True, OTOH, if a third party says that there was a misissuance, that means
there was one.
I disagree. Only the domain owner knows for sure what is a misissuance, and
what
On Tuesday 09 June 2015 10:53:37 Rob Stradling wrote:
On 08/06/15 15:09, Rob Stradling wrote:
On 08/06/15 14:54, Hubert Kario wrote:
On Wednesday 03 June 2015 09:43:23 Eric Mill wrote:
This is outstanding - simple, but totally what people need to start
getting
the idea and benefit of CT
is also trusted. Independent of your trust of the
third party.
-Rick
On Jun 10, 2015, at 4:01 AM, Hubert Kario hka...@redhat.com wrote:
On Tuesday 09 June 2015 11:57:40 Rick Andrews wrote:
On Tuesday, June 9, 2015 at 3:05:30 AM UTC-7, Hubert Kario wrote:
True, OTOH
-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
be more appropriate for dev.tech.crypto.)
This is doubly problematic, as some people may want to preserve roots that
were removed (see the recent removals of 1024 bit roots)...
It's a big can of worms no matter how you approach it.
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security
on your local coffee
shop wifi.
--
Regards,
Hubert Kario
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
is
About 2% of sites advertise HSTS, see
https://www.trustworthyinternet.org/ssl-pulse/
--
Regards,
Hubert Kario
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
debatable if the 2016 date is good. NIST doesn't agree
but yes, as far as Internet certs go, mozilla one is not so bad
--
Regards,
Hubert Kario
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org
everything and require 128 bit security through and
through for high-sec indication, then yes, 3DES needs to get cut.
--
Regards,
Hubert Kario
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev
for popular libraries, etc.
--
Regards,
Hubert Kario
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
to use different
roots,
they will still be counted towards the 107000 total even when their current
configuration
uses good roots (and was detected as such in their most recent scan)!
So yes, the numbers were artificially inflated a bit.
Hubert Kario stats posted here are way more useful
- Original Message -
From: Phillip Hallam-Baker ph...@hallambaker.com
To: Gervase Markham g...@mozilla.org
Cc: Rob Stradling rob.stradl...@comodo.com,
mozilla-dev-security-pol...@lists.mozilla.org, Hubert Kario
hka...@redhat.com
Sent: Friday, September 5, 2014 2:11:09 PM
Subject
, say 2 days,
then inclusion or exclusion of AIA extension is secondary.
There's also the must-staple extension in the works, which can be part of
the plan: you either get short lived certs or you get a long lived with
must-staple. They would provide the same security guarantees.
--
Regards,
Hubert
- Original Message -
From: Gervase Markham g...@mozilla.org
To: mozilla-dev-security-pol...@lists.mozilla.org
Sent: Thursday, September 4, 2014 3:04:33 PM
Subject: Re: Short-lived certs
On 04/09/14 12:52, Hubert Kario wrote:
It all depends on the exact definition of short-lived
- Original Message -
From: Kathleen Wilson kwil...@mozilla.com
To: mozilla-dev-security-pol...@lists.mozilla.org
Sent: Tuesday, September 2, 2014 10:43:56 PM
Subject: Re: Removal of 1024 bit roots - Thawte and GTE CyberTrust
On 9/2/14, 10:53 AM, Hubert Kario wrote:
Removing
be quoting it here.
As such, I'd say that removing those roots now would be premature.
1 - https://bugzilla.mozilla.org/show_bug.cgi?id=986014
2 - https://bugzilla.mozilla.org/show_bug.cgi?id=1047011
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: hka...@redhat.comg
Web
- Original Message -
From: Kurt Roeckx k...@roeckx.be
To: Hubert Kario hka...@redhat.com
Cc: Kathleen Wilson kwil...@mozilla.com,
mozilla-dev-security-pol...@lists.mozilla.org
Sent: Tuesday, August 5, 2014 12:44:13 AM
Subject: Re: Removal of 1024 bit CA roots - interoperability
hours
http://ocsp.verisign.com 20 days 21 hours
How often did they provide responses valid for over a week?
--
Regards,
Hubert Kario
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org
- Original Message -
From: Hubert Kario hka...@redhat.com
- Original Message -
From: Kathleen Wilson kwil...@mozilla.com
== For this batch of root changes ==
We are still investigating if we should use this possible solution for
this batch of root changes. Please
an error that the packets were tampered with?
Because until you parse the certificates and validate the signatures you
have no way of knowing if the packets you receive are coming from the
server or the MitM box at the ISP.
--
Regards,
Hubert Kario
___
dev
- Original Message -
From: Chris Palmer pal...@google.com
To: Hubert Kario hka...@redhat.com
Cc: David E. Ross nobody@nowhere.invalid,
mozilla-dev-security-pol...@lists.mozilla.org
Sent: Tuesday, 22 July, 2014 1:08:57 AM
Subject: Re: Proposal: Switch generic icon to negative
is one proposal. What are some
others?
This is actually what most Linux distributions do by default, so I'd say that
any other
solutions should be *in addition* to accepting self signed certs.
--
Regards,
Hubert Kario
___
dev-security-policy mailing
for sites with previously waived cert problems!)
so let's not treat them worse than HTTP connections
--
Regards,
Hubert Kario
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
certificate, but others too, if they
exist.
1 - https://bugzilla.mozilla.org/show_bug.cgi?id=1021967
2 - https://bugzilla.mozilla.org/show_bug.cgi?id=936304
3 - https://www.ssllabs.com/ssltest/analyze.html?d=groupon.my
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: hka
40 matches
Mail list logo
