On Fri, Dec 07, 2018 at 08:13:24AM -0800, pilgrim2223--- via
dev-security-policy wrote:
> As a retail organization we are in a moratorium till 1/2/2019 this happens
> every year. So nothing is being done that may jeopardize selling of
> widgets!
Choosing to not do something is, itself, doing
Paul Wouters via dev-security-policy
writes:
>I'm not sure how that is helpful for those crypto libraries who mistakenly
>believe a certificate is a TLS certificate and thus if the EKU is not empty
>it should have serverAuth or clientAuth.
Sure, it wouldn't help with current libraries that
Fair enough
Impact is this:
As a retail organization we are in a moratorium till 1/2/2019 this happens
every year. So nothing is being done that may jeopardize selling of widgets!
A process was put in place for 2wayssl where we'd name the cert based on what
it does (so
2018. december 6., csütörtök 23:31:42 UTC+1 időpontban Peter Gutmann a
következőt írta:
>
> So just to make sure I've got this right, implementations are needing to add
> dummy TLS EKUs to non-TLS certs in order for them to "work"? In that case why
> not add a signalling EKU or policy value, a
On Fri, Dec 7, 2018 at 4:35 PM Jeremy Rowley
wrote:
> I only ask because telling people to go back to the CA and work something
> out isn’t a great answer when the retort is that the CA will be distrusted
> if they don’t. Either the customer doesn’t replace all their certs and they
> are made
I only ask because telling people to go back to the CA and work something out
isn’t a great answer when the retort is that the CA will be distrusted if they
don’t. Either the customer doesn’t replace all their certs and they are made
non-functional by revocation or the certs are distrusted
That’s not well defined as there are various grades below that. Is the plan to
remove any CA that doesn’t comply with this requirement?
From: Ryan Sleevi
Sent: Friday, December 7, 2018 2:26 PM
To: Jeremy Rowley
Cc: mozilla-dev-security-policy
Subject: Re: CA Communication: Underscores in
On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> This isn't a CA-issue because the risk associated with non-compliance isn't
> defined yet.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
On Thu, 6 Dec 2018, Peter Gutmann via dev-security-policy wrote:
Paul Wouters via dev-security-policy
writes:
Usually X509 is validated using standard libraries that only think of the TLS
usage. So most certificates for VPN usage still add EKUs like serverAuth or
clientAuth, or there will
Personally, i think you should continue the discussion here. Although you can
bring it up to whichever ca you use, the reality is that without the browsers
knowing why the certs cant be replaced and the number, theres no way to gauge
their reaction to a non compliance. The penalties may include
Thank you very much for your response!
So at the end of the day I will not get any relief from the browsers, and will
need to get an exception from my CA?
When I asked the CA they told me to take it here. Feels like the CA is where
I'm going to have to focus!
Thanks again for your time!
11 matches
Mail list logo