A customer should able have the choice to change their CA provider without
threats of revocation by the CA. It’s definitely an abuse of the revocation
function.
I do understand terms and conditions are in normal circumstances legally
binding once signed by a customer but this practice is abuse of
On Mon, Mar 16, 2020 at 12:11:57PM -0700, Chris Kemmerer via
dev-security-policy wrote:
> On Wednesday, March 11, 2020 at 5:41:00 PM UTC-5, Matt Palmer wrote:
> > On Wed, Mar 11, 2020 at 10:46:05AM -0700, Chris Kemmerer via
> > dev-security-policy wrote:
> > > On Tuesday, March 10, 2020 at
On Mon, Mar 16, 2020 at 09:06:17PM +, Tim Hollebeek via dev-security-policy
wrote:
> I'd like to start a discussion about some practices among other commercial
> CAs that have recently come to my attention, which I personally find
> disturbing. While it's perfectly appropriate to have Terms
Hello,
I'd like to start a discussion about some practices among other commercial
CAs that have recently come to my attention, which I personally find
disturbing. While it's perfectly appropriate to have Terms and Conditions
associated with digital certificates, in some circumstances,
On Monday, March 16, 2020 at 2:46:46 PM UTC-5, Ryan Sleevi wrote:
> On Mon, Mar 16, 2020 at 3:12 PM Chris Kemmerer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > > It would appear that SSL.com is a member in good standing of the CA/B
> > Forum.
> > > Is there any
On Mon, Mar 16, 2020 at 3:12 PM Chris Kemmerer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > It would appear that SSL.com is a member in good standing of the CA/B
> Forum.
> > Is there any intention on the part of SSL.com to propose this change as a
> > ballot?
On Wednesday, March 11, 2020 at 5:41:00 PM UTC-5, Matt Palmer wrote:
> On Wed, Mar 11, 2020 at 10:46:05AM -0700, Chris Kemmerer via
> dev-security-policy wrote:
> > On Tuesday, March 10, 2020 at 8:44:49 PM UTC-5, Matt Palmer wrote:
> > > On Tue, Mar 10, 2020 at 01:48:49PM -0700, Chris Kemmerer
On Mon, Mar 16, 2020 at 11:13 AM Doug Beattie
wrote:
> For clarity, I think we need to discuss all the knobs along with proposed
> effective dates and usage periods so we get the whole picture.
>
I disagree with this framing, as I have pointed out it's been repeatedly
used disingenuously by
For clarity, I think we need to discuss all the knobs along with proposed
effective dates and usage periods so we get the whole picture. The max
validity period of the certificate has been the one receiving the most
discussion recently, yet that’s missing from your counter proposal. Don’t you
No, I don't think we should assume anything, since it doesn't say anything
about lifetime :)
The value of reduced certificate lifetimes is only fully realized with a
corresponding reduction in data reuse.
If you think about a certificate, there are three main pieces of
information that come from
Are we to assume that the maximum certificate validity remains at 398 days?
From: Ryan Sleevi
Sent: Monday, March 16, 2020 10:02 AM
To: Doug Beattie
Cc: r...@sleevi.com; Kathleen Wilson ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: About upcoming limits on trusted
Hi Doug,
Perhaps it got mangled by your mail client, but I think I had that covered?
I've pasted it again, below.
Counter proposal:
April 2021: 395 day domain validation max
April 2021: 366 day organization validation max
April 2022: 92 day domain validation max
September 2022: 31 day domain
Ryan,
In your counter proposal, could you list your proposed milestone dates and
then for each one specify the max validity period, domain re-use period and Org
validation associated with those dates?As it stands, Org validation
requires CA to verify that address is the Applicant’s
On 14/03/2020 18:53, Nick Lamb wrote:
my assumption is that at
best such a patch would be in the big pile of volunteer stuff maybe
nobody has time to look at.
Tangential: perhaps there's an aspect of phrasing here that is confusing
me, but this reads to me as suggesting we don't review/work
14 matches
Mail list logo
