On Fri, May 10, 2019 at 09:59:48AM -0700, Wayne Thayer via dev-security-policy
wrote:
> > On Tue, May 7, 2019 at 7:48 PM Wayne Thayer via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >> To continue to participate in the Mozilla CA program, I recommend that we
> >>
I've attempted to update section 6 to incorporate revocation requirements
for S/MIME certificates:
https://github.com/mozilla/pkipolicy/commit/15ad5b9180903b92b8f638c219740c0fb6ba0637
Note: since much of this language is copied directly from the BRs, if we
decide to adopt it, the policy will
First off, I would like to remind everyone that participation in this forum
is subject to Mozilla's Community Participation Guidelines [1].
The arguments that have been made for adding an exception to our policy for
Policy CAs have not, in my opinion, made a clear and compelling case for
the
On Mon, Apr 29, 2019 at 7:31 AM Peter Bowen wrote:
> I support this, as long as Policy CAs meet the same operations standards
> and have the same issuance restrictions as root CAs. This would result in
> no real change to policy, as I assume roots not directly included in the
> Mozilla root
I have drafted the change as proposed, moving the exact "Required Practice"
language into section 3.3 of the policy:
https://github.com/mozilla/pkipolicy/commit/803ec1a1414318a69491854a867dc69889442b7b
On Sat, Apr 27, 2019 at 11:36 AM Pedro Fuentes via dev-security-policy <
Having received no comments on these proposed changes, I plan to include
them in version 2.7 of our policy.
- Wayne
On Fri, Apr 19, 2019 at 11:55 AM Wayne Thayer wrote:
> Ryan Sleevi made the following proposal:
>
> Issue #122 [1] previously discussed Section 8 in the context of
>> subordinate
The difference is we actually have the data at time of issuance. It just wasn’t
correctly relied on for these specific certs. I think this means there is an
open question on whether the issuance even was a mis-issuance since the CAA
information was collected…even if it wasn’t perfect.
This
On Fri, May 10, 2019 at 3:55 PM Jeremy Rowley
wrote:
> The analysis was basically that all the verification documents are still
> good, which means if we issued the cert today, the issuance would pass
> without further checks (since the data itself is good for 825 days).
> Because of this,
The analysis was basically that all the verification documents are still good,
which means if we issued the cert today, the issuance would pass without
further checks (since the data itself is good for 825 days). Because of this,
customers with domains that didn’t prohibit Digicert in their CAA
Hey Tim,
The issue was a call between the CA and CAA checker. The CAA checker would
check the DNS and verify the DNSSEC chain. However, when retrieving the
information from the CAA checker, the CA had the error, which means the CAA
check was not evaluated correctly. Under normal operation the
Okay. I'm working on something and will post it soon.
From: Ryan Sleevi
Sent: Friday, May 10, 2019 11:54:14 AM
To: Jeremy Rowley
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA record checking issue
On Thu, May 9, 2019 at 10:05 PM Jeremy
On Thu, May 9, 2019 at 10:05 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> We checked all the applicable CAA records and found 16 where the CAA record
> would not permit us to issue if we were issuing a new cert today. What we
> are proposing is to
On Wed, May 8, 2019 at 10:32 AM Ryan Sleevi wrote:
>
> On Tue, May 7, 2019 at 7:48 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> To continue to participate in the Mozilla CA program, I recommend that we
>> require Certinomis to create a new
On Fri, May 10, 2019 at 8:09 AM fchassery--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Dear Wayne,
>
> I’m not arguing that signing the new Startom root was a mistake.In fact,
> as soon as we were told, we backed off.
> Our understanding at that time was that the
Le vendredi 10 mai 2019 06:37:11 UTC+2, Wayne Thayer a écrit :
> On Thu, May 9, 2019 at 8:56 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On 10/05/2019 02:22, Wayne Thayer wrote:
> > > Thank you for this response Francois. I have added it to the
Jeremy,
Thanks for sharing this. After reading your description, I'm curious how your
system was previously (or is now) satisfying the third criteria needed to issue
in the face of a record lookup failure: confirming that the domain's zone does
not have a DNSSEC validation chain to the ICANN
16 matches
Mail list logo
