This prompted me to dig up more information of this old issue. Here is the
issue in our tracker:
https://jira.primekey.se/browse/ECA-3149
Looking back in my records it's not only a local jurisdiction auditor that
enforced SHA-256. We also received several request from Web PKI CAs to
implement
Speaking from a personal perspective -
This all makes sense, and, to be honest, the spectrum/grade idea isn’t a good
or robust. Implementing something like that requires too many judgment
questions about whether a CA belongs in box x vs. box y and what is the
difference between those two boxes.
On Mon, Oct 7, 2019 at 7:06 PM Jeremy Rowley
wrote:
> Interesting. I can't tell with the Netlock certificate, but the other
> three non-EKU intermediates look like replacements for intermediates that
> were issued before the policy date and then reissued after the compliance
> date. The industry
Interesting. I can't tell with the Netlock certificate, but the other three
non-EKU intermediates look like replacements for intermediates that were issued
before the policy date and then reissued after the compliance date. The
industry has established that renewal and new issuance are identica
In light of Wayne's many planned updates as part of version 2.7 of the
Mozilla Root Store Policy, and prompted by some folks looking at adding
linters, I recently went through and spot-checked some of the Mozilla
Policy-specific requirements to see how well CAs are doing at following
these.
I disc
Hi
This is an incident report for one certificate issued by Buypass on September
23rd 2019 noncompliant with BR 7.1. The certificate, issued to a Swedish
organization, has an error in the subject:postalCode field. The postalCode
value is set to 2153 while the correct value should be 21532.
===
On Mon, Oct 7, 2019 at 12:20 PM Jeremy Rowley
wrote:
> For example, suppose a root was created before a rule went into place and
> the root needs to be renewed for some reason. If the root was compliant
> before creation and modifying the profile would break something with the
> root, then there'
For this particular incident, I would like to know why the CA didn’t review the
profile before signing the root. It seems like a flaw in the process in the key
ceremony process not to go through a checklist with the profile and ensure each
field complies with the current version of BRs.
Questi
Yeah - I like the visibility here since I know I often forget to post the
incident to the Mozilla list as well as post the bug.
IMO - it's up to the CA to decide if they want to sign something in violation
of the BRs and then it's up the browsers on what the action taken in response
is. I ackn
On 07/10/2019 17:35, Ryan Sleevi wrote:
> On Mon, Oct 7, 2019 at 11:26 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 07/10/2019 16:52, Ryan Sleevi wrote:
>>> I'm curious how folks feel about the following practice:
>>>
>>> Imagine a CA, "Foo", that
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
https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190930-versi
On Mon, Oct 7, 2019 at 11:54 AM Jeremy Rowley
wrote:
> Are both roots trusted in the Mozilla root store? If so, could you say
> that Mozilla has approved of the root not-withstanding the non-compliance?
> If root 2 did go through the public review process and had the public look
> at the certific
Are both roots trusted in the Mozilla root store? If so, could you say that
Mozilla has approved of the root not-withstanding the non-compliance? If root 2
did go through the public review process and had the public look at the
certificate and still got embedded, then Mozilla perhaps signed off
On Mon, Oct 7, 2019 at 11:26 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 07/10/2019 16:52, Ryan Sleevi wrote:
> > I'm curious how folks feel about the following practice:
> >
> > Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). The
On 07/10/2019 16:52, Ryan Sleevi wrote:
I'm curious how folks feel about the following practice:
Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). They
create this Root Certificate after the effective date of the Baseline
Requirements, but prior to Root Programs consistently r
I'm curious how folks feel about the following practice:
Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). They
create this Root Certificate after the effective date of the Baseline
Requirements, but prior to Root Programs consistently requiring compliance
with the Baseline Requ
16 matches
Mail list logo
