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
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
I was digging through the NSS source code, and I ran across two
undocumented trust flags: CERTDB_INVISIBLE_CA and CERTDB_GOVT_APPROVED_CA .
As far as I can tell, CERTDB_INVISIBLE_CA seems to indicate that the UI
should hide the existence of the CA from the user, while
CERTDB_GOVT_APPROVED_CA
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/
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
In mozilla.dev.security, Jeremy Rand wrote:
> I was digging through the NSS source code, and I ran across two
> undocumented trust flags: CERTDB_INVISIBLE_CA and CERTDB_GOVT_APPROVED_CA .
>
> As far as I can tell, CERTDB_INVISIBLE_CA seems to indicate that the UI
> should hide the existence of
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
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
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 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
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 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
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!
13 matches
Mail list logo
