On Friday, June 16, 2017 at 1:05:37 AM UTC-4, Tavis Ormandy wrote:
> Hello, I was crawling the pkcs7 blobs in public pdf files and found some
> intermediate certificates that don't appear in crt.sh.
>
> I forwarded them to Rob, I don't know if this is useful to anyone else, but
> they're
On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote:
> I think we have settled on the following resolution to this issue:
>
> Add the following to section 5.2 (Forbidden and Required Practices):
>
> CAs MUST NOT generate the key pairs for end-entity certificates that have
> > an
On Wednesday, January 10, 2018 at 4:24:54 PM UTC-5, Tim Hollebeek wrote:
> As you know, BR 3.2.5 requires CAs to verify the authenticity of a request
> for an OV certificate through a Reliable Method of Communication (RMOC).
> Email can be a RMOC, but in these cases, the email address was a
On Monday, July 16, 2018 at 7:25:09 PM UTC-4, Wayne Thayer wrote:
> On Fri, Jul 13, 2018 at 3:50 PM Tim Hollebeek via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Yeah, I agree I don’t think it was intended. But now that I am aware of
> > the issue, I think the
On Thursday, September 6, 2018 at 7:44:15 PM UTC-4, Wayne Thayer wrote:
> All,
>
> I've drafted a new email and survey that I hope to send to all CAs in the
> Mozilla program next week. it focuses on compliance with the new (2.6.1)
> version of our Root Store Policy. I would appreciate your
t; From: dev-security-policy [mailto:dev-security-policy-
> > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Bruce via
> > dev-security-policy
> > Sent: Thursday, July 12, 2018 10:28 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re
Note the BRs define Cross Certificate as "a certificate that is used to
establish a trust relationship between two Root CAs."
I think the intent was to technically restrict subordinate CAs or rather CAs
which are online and issue end entity certificates. My assumption is that we
want to 1) not
Entrust does the following:
- Each subCA certificate is created through a audited ceremony. The auditor
creates a report indicating the key ID and the CPS which was used for key
generation.
- When it is time for the subCA to go into production, an intermediate
certificate is issued from a root.
Entrust issued two certificates where the IP Address was indicated in the
dNSName form. Both certificates have been revoked. The bug has been resolved.
Details of the incident report can be found here,
https://bugzilla.mozilla.org/show_bug.cgi?id=1448986.
Thanks, Bruce.
Hi Wayne, I wanted to get some clarification.
For example, let's say that a Subscriber has a 1 year certificate which expires
on 30 January 2019. On 15 January 2019, the remaining validity period is less
than 30 days; as such, I interpret that the certificate does not have to be
revoked.
On
On January 18, 2019, Entrust discovered that 9 SSL certificates with underscore
characters which were issued for more than 30 days were not revoked before 15
January 2019. All certificates were revoked on 18 January 2019.
Details of the incident report can be found here,
On Wednesday, December 12, 2018 at 7:59:46 PM UTC-5, Jeremy Rowley wrote:
> Some systems look like they verify the email address/domain name at issuance
> and then never again for the same account. Other systems verify the email
> address and domain every 825 days. The last set verifies the email
On November 19, 2018 an SSL certificate was issued with '-' in the ST field of
the subject DN. The certificate has been revoked.
Details of the incident report can be found here,
https://bugzilla.mozilla.org/show_bug.cgi?id=1512018.
Thanks, Bruce.
On March 7, 2019, Entrust Datacard discovered that SSL certificates with the
wrong Organization value were issued to a customer. The investigation was
completed 15 March 2019.
Details of the incident report can be found here,
https://bugzilla.mozilla.org/show_bug.cgi?id=1535735.
All
On Friday, July 26, 2019 at 1:25:13 PM UTC-4, Wayne Thayer wrote:
> ==Bad==
> * The most recent BR audit report lists two additional qualifications
> related to the Network Security requirements:
> ** During the Period, there were instances of some Certificate Systems not
> undergoing a
On Friday, July 26, 2019 at 1:25:13 PM UTC-4, Wayne Thayer wrote:
> ==Meh==
> * BR section 2.2 requires section 4.2 of a CA’s CP and/or CPS to “clearly
> specify the set of Issuer Domain Names that the CA recognises in CAA
> "issue" or "issuewild" records as permitting it to issue.” The Entrust
On Friday, July 26, 2019 at 1:45:06 PM UTC-4, Ryan Sleevi wrote:
> (In a personal capacity, as normally noted but making sure to extra-note it
> here)
>
> Hi Wayne,
>
> It wasn't clear to me from the inclusion request, did Entrust give a reason
> for the requested addition? For example, do they
On Monday, July 29, 2019 at 5:22:19 PM UTC-4, Bruce wrote:
> We will update section 4.2 and 9.12.3 in the next release of the CPS.
The CPS Has been updated to address the above issues, see
On Thursday, March 19, 2020 at 2:02:39 AM UTC-4, Matt Palmer wrote:
> 1. *Are* there explicit prohibitions on issuing a certificate for a private
>key which has been previously submitted *to that CA* as compromised
>(assuming, of course, that the prior submission was valid), and I'm just
n of key
> destruction that would be covered by an audit/auditor's statement.
> On Fri, Mar 5, 2021 at 9:46 AM Bruce via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
One more question for clarification as I want to make sure we understand how to
get ou
On Thursday, February 25, 2021 at 2:30:52 PM UTC-5, bwi...@mozilla.com wrote:
> I haven't seen any response to my question about whether there is still a
> concern over the language "as evidenced by a Qualified Auditor's key
> destruction report".
> I did add "This cradle-to-grave audit
21 matches
Mail list logo
