On Sat, Sep 21, 2019 at 7:52 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> To remedy this, Entrust Datacard surveyed all of its TLS/SSL web server
> certificate customers over three days (19-21 September 2019) concerning
> website identity in browsers, brow
On Mon, Sep 23, 2019 at 9:31 AM Dimitris Zacharopoulos via
dev-security-policy wrote:
> On 20/9/2019 11:00 μ.μ., Wayne Thayer wrote:
> > On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos
> > mailto:ji...@it.auth.gr>> wrote:
> >
> >
> >
> > Using the following practice as described i
On Mon, Sep 23, 2019 at 12:50 PM Dimitris Zacharopoulos
wrote:
>
>
> On 2019-09-23 1:37 μ.μ., Ryan Sleevi via dev-security-policy wrote:
> > On Mon, Sep 23, 2019 at 9:31 AM Dimitris Zacharopoulos via
> > dev-security-policy wrote:
> >
> >> On 20/9/2019 11:0
On Mon, Sep 23, 2019 at 8:50 AM Dimitris Zacharopoulos
wrote:
>
>
> On 2019-09-23 3:02 μ.μ., Ryan Sleevi wrote:
>
> It would be useful to identify whether there’s an objective to the
> questions, since that might help us cut down things quicker:
> - Are you running a 5019 responder or a 6960 resp
On Mon, Sep 23, 2019 at 11:53 PM Andy Warner via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> The practice of revoking non-issued certificates would therefore lead to
> CRL growth which would further make reliable revocation checking on
> bandwidth constrained clients more
On Tue, Sep 24, 2019 at 2:36 AM Clint Wilson wrote:
> On Mon, Sep 23, 2019 at 6:29 PM Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Yup. And it’s been repeatedly acknowledged that is perfectly fine. The
>> proposed language
On Thu, Oct 3, 2019 at 3:45 PM Ronald Crane via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 10/2/2019 9:44 PM, Peter Gutmann via dev-security-policy wrote:
> > Ronald Crane via dev-security-policy <
> dev-security-policy@lists.mozilla.org> writes:
> >
> >> Please cite
On Fri, Oct 4, 2019 at 4:37 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> One thing that might help to resolve this is a more detailed description of
> the weaknesses that are present in the process described by Ryan Hurst. If
> we can all agree that the
Jeremy:
Could you describe a bit more who the actors are?
Basically, it seems that the actual issuance is going to fall into one of
several buckets:
1) Root CA controls Issuing CAs key
2) Issuing CA controls its own key, but is technically constrained
3) Issuing CA controls its own key, and is no
Thanks Jeremy, Dimitris,
It does help clarify. I think we're all on the same page: namely, in all
cases, the CA does the validation of (at minimum) the domain portion.
I think it might be useful to think of this like the split between
Authorization Domain Name and Fully Qualified Domain Name. A C
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
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 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
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'
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
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
On Tue, Oct 8, 2019 at 10:04 AM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Unless I found a root that Ryan isn’t referring to, Mozilla Policy 2.1 (
> https://wiki.mozilla.org/CA:CertificatePolicyV2.1) would have been in
> force when the root was first i
On the topic of root causes, there's also
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3425554 that was
recently published. I'm not sure if that was peer reviewed, but it does
provide an analysis of m.d.s.p and Bugzilla. I have some concerns about the
study methodology (for example, when inc
On Tue, Oct 8, 2019 at 2:44 PM Paul Walsh wrote:
> Dear Ryan,
>
> It would help a great deal, if you tone down your constant insults towards
> the entire CA world. Questioning whether you should trust any CA is a
> bridge too far.
> Instead, why don’t you try to focus on specific issues with sp
Paul,
If you'd like to continue this conversation, might I respectfully ask you
take it elsewhere from this thread? It does not seem you're interested in
finding solutions for the issues, and you've continued to shift your
message, so perhaps it might be better to continue that discussion
elsewher
To try and minimize some of the tone-policing ad hominem, arguments from
authority, and thread-jacking, especially on-list, let's circle back to the
subject of this thread, and hopefully you can offer constructive solutions
there.
Is my understanding correct that your concern is you don't believe
On Tue, Oct 8, 2019 at 6:42 PM Jeremy Rowley
wrote:
> Tackling Sub CA renewals/issuance from a compliance perspective is
> difficult because of the number of manual components involved. You have the
> key ceremony, the scripting, and all of the formal process involved.
> Because the root is store
(Sorry for the second e-mail, Erwann still having some Groups issues - this
will be the one that shows up on the list)
On Tue, Oct 8, 2019 at 6:43 PM Erwann Abalea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> If this is to be read as an exclusive choice, then how do y
On Tue, Oct 8, 2019 at 8:16 PM Jeremy Rowley
wrote:
> I think requiring publication of profiles for certs is a good idea. It’s
> part of what I’ve wanted to publish as part of our CPS. You can see most of
> our profiles here:
> https://content.digicert.com/wp-content/uploads/2019/07/Digicert-Cert
On Wed, Oct 9, 2019 at 6:06 PM Paul Walsh via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I believe an alternative icon to the encryption lock would make a massive
> difference to combating the security threats that involve dangerous links
> and websites. I provided data
On Wed, Oct 9, 2019 at 7:17 PM Paul Walsh wrote:
> We can all agree that almost no user knows the difference between a site
> with a DV cert and a site with an EV cert. I personally came to that
> conclusion years ago. I wanted data, so I asked more than 3,000 people.
> Almost everyone assumed th
On Thu, Oct 10, 2019 at 11:42 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Question, is there any prohibition against demonstration of domain control
> being delegated to a third party or even the CA itself? I don't think so,
> but figured we've discus
On Fri, Oct 11, 2019 at 2:10 PM Clint Wilson wrote:
> Apologies, but this isn't entirely clear to me. I'm guessing (hoping) my
> misunderstanding centers around a difference between the Applicant fully
> delegating DNS to the CA vs the Applicant only configuring a single CNAME
> record? If the Ap
On Fri, Oct 11, 2019 at 3:14 PM Doug Beattie
wrote:
> Ryan,
>
> Are you recommending that:
> a) we need a new domain validation method that describes this, or
> b) those CAs that want to play with fire can go ahead and do that based on
> their own individual security analysis, or
> c) we need a
In the spirit of improving transparency, I've gone and filed
https://github.com/mozilla/pkipolicy/issues/192 , which is specific to
auditors.
However, I want to highlight this model (the model used by the US Federal
PKI), because it may also provide a roadmap for dealing with issues like
this / th
(Replying for the correct address this time)
On Fri, Aug 16, 2019 at 4:28 PM Jason via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi All,
>
> This is Jason from the Microsoft PKI Services team. I’d like to add some
> context to the note about the certs issued from the M
On Mon, Oct 21, 2019 at 7:58 PM Wayne Thayer wrote:
> The CA MUST verify all e-mail addresses using a process that is
>> substantially similar to the process used to verify domain names, as
>> described in the Baseline Requirements.
>>
>
> This seems problematic because it could be interpreted as
On Tue, Oct 22, 2019 at 6:31 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > I'm also not sure if I understand the wording correctly. Let's assume, an
> > internal CA of company "mycompany" gets successfully validated for
> > mycompany.example and receiv
On Tue, Oct 22, 2019 at 9:51 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I have added this proposal to the 2.7 branch:
>
> https://github.com/mozilla/pkipolicy/commit/fa843039285b10030490c7eb54d1b754edae1fbc
>
> I will greatly appreciate everyone's fee
On Fri, Oct 25, 2019 at 6:44 PM Buschart, Rufus
wrote:
> Your statement is, in my opinion, totally correct for external CAs. But
> the scenario I have in my mind is a little bit different: In my scenario,
> there is
> a Root CA that is included in the Root stores serving the general public
> and
Some comparisons, from the Browser/Root Program Alignment proposal
circulated at
https://github.com/cabforum/documents/compare/master...sleevi:2019-10-Browser_Alignment
On Wed, Oct 30, 2019 at 1:52 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> All,
>
Thanks, Kathleen. Snipped the other changes (which sound good), and a few
replies inline below.
On Thu, Oct 31, 2019 at 4:39 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> >> 2. Full name of the CA that was audited;
> >> 3. SHA-256 fingerprint of each
On Thu, Oct 31, 2019 at 7:20 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 2) Summarized: ALV tries to find a match in the Audit Letter for the
> SHA256 thumbprint that is sent by CCADB. Listing thumbprints that were
> out of scope within an audit let
Is your view that the OU is not Subject Identity Information, despite that
being the Identity Information that appears in the Subject? Are there other
fields and values that you believe are not SII? This seems inconsistent
with 7.1.4.2, the section in which this is placed.
As to the .com in the OU
Yes. I'm concerned about an interpretation that says the Subject field
doesn't identify the Subject, while also being sensitive to past
discussions (e.g. dnQualifier) that are explicitly specified not to
identify the Subject. The OU, as specified both in the BRs and within the
relevant ITU-T standa
On Fri, Nov 8, 2019 at 1:54 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> A few more questions have come up about this change:
>
> * Since mozilla::pkix doesn't currently support the RSA-PSS encodings, why
> would we include them in our policy?
>
They w
(Writing in an official capacity for the Google/Chrome Root Program)
There are still a remarkable number of CAs that have not filed incident
reports and not yet remediated this issue.
A reminder, the Baseline Requirements, Section 8.1, states:
> Certificates that are capable of being used to iss
In https://bugzilla.mozilla.org/show_bug.cgi?id=1593814 , Rob Stradling,
Jeremy Rowley, and I started discussing possible steps that might be taken
to prevent misencoding strings in certificates, and it seemed appropriate
to shift this to a more general m.d.s.p. discussion, rather than solely on
th
On Wed, Nov 20, 2019 at 9:48 PM Peter Gutmann
wrote:
> Ryan Sleevi via dev-security-policy
> writes:
>
> >In https://bugzilla.mozilla.org/show_bug.cgi?id=1593814 , Rob Stradling,
> >Jeremy Rowley, and I started discussing possible steps that might be
> taken to
> >
On Wed, Nov 20, 2019 at 10:54 PM Peter Gutmann
wrote:
> Ryan Sleevi writes:
>
> >Do you believe it’s still applicable in the Web PKI of the past decade?
>
> Yes, the specific cert I referenced is current valid and passed WebTrust
> and
> EV audits.
>
"Passed" is... a bit misleading as to the (l
On Thu, Nov 21, 2019 at 10:54 AM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> During the recent CA/Browser Forum meeting, I was asked to provide better
> guidance on Mozilla's expectations for incident reporting. We're adding a
> requirement for incident r
Yes, I am one of the ones who actively disputes the notion that AIA
considered harmful.
I'm (plesantly) surprised that any CA would be opposed to AIA (i.e.
supportive of "considered harmful", since it's inherently what gives them
the flexibility to make their many design mistakes in their PKI and
> One could easily do it with wildcard DNS and a per-end-entity cert host
> label for the AIA distribution point.
>
>
> On Wed, Dec 4, 2019 at 4:13 PM Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Yes, I am one of the ones
On Thu, Dec 5, 2019 at 10:42 AM Nick Lamb wrote:
> On Wed, 4 Dec 2019 17:12:50 -0500
> Ryan Sleevi via dev-security-policy
> wrote:
>
> > Yes, I am one of the ones who actively disputes the notion that AIA
> > considered harmful.
>
> As not infrequently happens I c
On Sun, Dec 8, 2019 at 7:14 PM Eric Mill wrote:
> On Thu, Dec 5, 2019 at 12:34 PM Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> From looking at better security, the 'ideal' path is that modern clients
>> are on
On Thu, Dec 19, 2019 at 12:10 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> All,
>
> I've drafted a new email and survey that I plan to send to all CAs in the
> Mozilla program in early January. it focuses on compliance with the new
> (2.7) version of ou
On Fri, Dec 20, 2019 at 6:16 AM Evangelos Karatsiolis via
dev-security-policy wrote:
> Dear all,
>
> I have a question about an issue regarding the new Mozilla Root Store
> Policy. Would it be possible to help me? The question regards the
> encoding of the parameters of the hash algorithm used in
On Tue, Jan 14, 2020 at 5:46 AM ekaratsiolis--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > The canonical usage is the explicit NULL, but other __new__ uses in an
> > AlgorithmIdentifier (i.e. that don't use the HashAlgorithm or
> > MaskGenAlgorithm types) can and s
(Replying from the correct e-mail)
On Thu, Feb 6, 2020 at 3:55 PM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> We should clarify the Mozilla policy to more clearly define list of fields
> containing email address (those 3 listed above) must be validated i
On Tue, Feb 4, 2020 at 6:59 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> All,
>
> https://wiki.mozilla.org/CA/Audit_Letter_Validation
> currently says:
> ""
> Acceptable remediation for an intermediate certificate missing BR audits
> may include one
On Fri, Feb 7, 2020 at 7:55 AM douglas.beattie--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thursday, February 6, 2020 at 6:05:20 PM UTC-5, Ryan Sleevi wrote:
> > (Replying from the correct e-mail)
> >
> > On Thu, Feb 6, 2020 at 3:55 PM Doug Beattie via dev-secur
On Fri, Feb 7, 2020 at 11:00 AM Wayne Thayer wrote:
> I'd like to see Mozilla require an incident report from CAs that can't or
> won't follow the existing guidance (by either supplying a revised audit
> statement, revoking the certificate, or adding it to OneCRL). A number of
> CAs have resolved
On Fri, Feb 7, 2020 at 12:27 PM Dimitris Zacharopoulos via
dev-security-policy wrote:
> Finally, I don't think auditor professional ethics have anything to do
> with this discussion. Both audit schemes allow for reports to be updated
> otherwise we wouldn't even have this option on the table. Cha
What would/should be the expected response if a natural disaster/act of God
happened and the security of the key material could not be assured by an
independent third party?
For example, an earthquake, typhoon, or military coup disrupting travel to
location(s) with the key material?
Similarly, wh
On Thu, Feb 20, 2020 at 4:58 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> We will continue to follow our standard process to adjudicate the issue
> regarding failures to provide CA audit statements [1] and we will work
> with the impacted CAs through
Hi Arvid,
I wanted to follow-up, and see if you had suggestions or ideas here for
appropriate next steps. Understandably, as more countries are affected,
this will no doubt continue to be an issue. I think you're spot on for
asking early, as you did, and I'm hoping GlobalSign (and others!) might
h
Yes, this is known as a gap.
This was discussed in the CA/Browser Forum in 2015, but there did not seem
to be support from CAs to adopt.
You can look in the following minutes available at CABForum.org
- 2014-12-12
- 2015-01-08
- 2015-02-19
- 2015-03-05
As well as the 2016-05-25
You can find som
On Sun, Mar 1, 2020 at 9:49 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> The BRs, in s4.9.1.1, say:
>
> > The CA SHALL revoke a Certificate within 24 hours if one or more of the
> > following occurs:
> >
> > [...]
> > 3. The CA obtains evidence that the
On Mon, Mar 2, 2020 at 2:07 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > However, I get the feeling that you don’t put much stock into incident
> > reports and browsers dim view of shenanigans. That might be worth
> expanding
> > upon, if you believe t
Thanks. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1619359 to
track this
On Mon, Mar 2, 2020 at 2:59 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Between 26 Feb 2020 00:48:11 UTC and 26 Feb 2020 21:10:18 UTC, I sent three
> Certificate Problem
Thanks Arvid! I think these are good starting points for discussion!
On Wed, Mar 4, 2020 at 8:48 AM Arvid Vermote
wrote:
> When I initially raised the topic I had two things in mind:
>
> -What if a facility can’t be audited?
>
> -If main key management facilities are down can Web
On Thu, Mar 5, 2020 at 8:09 AM Malcolm Doody via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tuesday, 3 March 2020 15:37:00 UTC, Jacob Hoffman-Andrews wrote:
> > We've posted our Incident Report at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1619047#c1.
>
> In ligh
Thanks Jeff,
This is incredibly helpful to understand the approach (and limitations)
that are relevant in the context of a WebTrust report. I'm hoping our ETSI
colleagues might provide a similar level of detail, as I suspect this is
hardly "just" a WebTrust problem at this point.
On Fri, Mar 6, 2
Thanks. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1620772
On Fri, Mar 6, 2020 at 9:48 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> (Pre) Certificate https://crt.sh/?id=2531502044 has been issued with a
> known
> weak key, specifically Debian
On Fri, Mar 6, 2020 at 10:05 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Therefore, the question I'm asking is: should Mozilla (aka the community
> and
> CA module owner and peers) make a policy decision to treat certificates
> issued with a known Debia
On Fri, Mar 6, 2020 at 9:03 PM jwardcpa--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Great follow on questions Ryan. As far as the detailed report, whether
> the end product is in the current form, or in the detailed version, the
> lead auditor is taking full respo
Comments inline and snipped
On Mon, Mar 9, 2020 at 2:48 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> ==Meh==
>
* Microsec issued two certificates in 2018 with 3-year validity periods [1].
>
That bug, and the related discussion, discussions Microsec
On Tue, Mar 10, 2020 at 4:25 PM bif via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Matt,
>
> Voluntarily providing CSR is not an ideal way to prove key compromise,
> because you could've simply found this CSR somewhere (I know, I know, super
> unlikely with your Subject.
On Tue, Mar 10, 2020 at 5:56 PM Piotr Kucharski wrote:
> I'm sympathetic to CAs wanting to filter out the noise of shoddy reports
>> and shenanigans, but I'm also highly suspicious of CAs that put too
>> unreasonable an onus on reporters. It seems, in the key compromise case,
>> the benefit of th
Matthias,
I took a lot of care to address precisely that concern, so I hope that
message was not directed in response to me. If it was, then I think it
highlights a fundamental misunderstanding of the concern.
I think everything you said is consistent with the response I offered. I am
would be fa
On Wed, Mar 11, 2020 at 1:46 PM Chris Kemmerer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> You are correct, each compliance violation is considered an incident.
> However in our opinion we have not violated our CP/CPS or the current
> Baseline Requirements. Although
The Baseline Requirements allow a number of methods that aren’t easily
automated, such as validation via email. As a result, CAs don’t pursue
automation, or when they support it, neither promote nor require it. This
leads CAs to be opposed to efforts to shorten the reuse time, as they have
historic
On Thu, Mar 12, 2020 at 10:58 AM Jeremy Rowley
wrote:
> I think this statement is not accurate: "As a result, CAs don’t pursue
> automation, or when they support it, neither promote nor require it." I
> know very few CAs who want to spend extra resources on manual validations
> and just as few wh
On Thu, Mar 12, 2020 at 12:46 PM Sándor dr. Szőke via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> So according to the RFC3647 the chapter 1.5.2 shall contain the contact
> person information who is responsible for the management of the CPS,
> but the BR requires, that the
Responses inline.
On Thu, Mar 12, 2020 at 12:46 PM Sándor dr. Szőke via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > * Microsec issued two certificates in 2018 with 3-year validity periods
> [1].
>
> The certificates were issued for CISCO VPN servers. After receiving th
On Fri, Mar 13, 2020 at 2:38 PM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> When we moved to SHA2 knew of security risks so the timeline could be
> justified, however, I don’t see the same pressing need to move to annual
> domain revalidation and 1 year m
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.8.pdf
4.10.2. Service Availability
The CA SHALL operate and maintain its CRL and OCSP capability with
resources sufficient to provide a
response time of ten seconds or less under normal operating conditions.
On Fri, Mar 13, 2020 at 6
On Sat, Mar 14, 2020 at 2:54 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thu, 5 Mar 2020 14:15:17 +
> Nick Lamb via dev-security-policy
> wrote:
>
> > There is some value in policy alone but there's also substantial
> > independent value in writin
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 val
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
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 some
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? While
Suggestions:
1) Rename "Audit Delay" to [audit-delay] and rename "Audit Delay COVID-19"
to [audit-delay] [covid-19] or [audit-delay-covid-19], depending
Rationale: In general, our filters work on word searches, so the brackets
brackets help distinguish the two. To search for "Audit Delay" without
c
On Thu, Mar 19, 2020 at 1:02 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Since I started requesting revocation for certificates with
> known-compromised private keys, I've noticed a rather disturbing pattern
> emerging in a few cases:
>
> 1. I find a pr
On Thu, Mar 19, 2020 at 9:58 AM Wojtek Porczyk
wrote:
> On Thu, Mar 19, 2020 at 05:30:31AM -0500, Ryan Sleevi via
> dev-security-policy wrote:
> > [...] but given that some negligent and
> > irresponsible CAs kept agitating to reduce revocation requirements than
> > prote
Matt,
I'm not sure an incident report is necessary. The CCADB policy allows both
to be provided, and the mechanisms that CCADB uses (both for CAs and for
Root Stores) permit a host of expressiveness (and further changes are being
made).
While there is certainly benefit in highlighting the English
On Thu, Mar 19, 2020 at 7:06 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thu, Mar 19, 2020 at 12:33:29PM -0400, Ryan Sleevi wrote:
> > I'm not sure an incident report is necessary. The CCADB policy allows
> both
> > to be provided, and the mechanisms
On Fri, Mar 20, 2020 at 4:07 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> My question: What should "location" mean in the above requirement?
>
The WebTrust Practitioner Guidance offers a reasonable definition:
https://www.cpacanada.ca/en/business-an
On Fri, Mar 20, 2020 at 4:15 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> What about issues other than audits? For example, with certain locations
> closing, key ceremonies may become impossible, leading to downed CRLs/OCSP
> for intermediates. There's
On Mon, Mar 23, 2020 at 11:01 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hey Matt,
>
> Ryan's post was the part I thought was relevant, but I understood it
> differently. The cert was issued, but we should have now revoked it (24
> hours after receiv
On Sun, Mar 22, 2020 at 10:03 PM Stephen Davidson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hello:
> (Apologies if multiple copies of this are received. The initial send was
> bounced by mdsp.)
>
> Summary: The certificates noted in Matt Palmer's email below were
On Mon, Mar 23, 2020 at 2:43 PM Bruce via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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 previous
On Mon, Mar 23, 2020 at 3:13 PM Burton via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> CAs,
>
> Please can you give a brief statement regarding these questions below:
>
> a) What’s your operational status at this time?
>
> b) Do you expect in the next six months to mainta
On Mon, Mar 23, 2020 at 6:18 PM Burton wrote:
> Hi Ryan,
>
> I’m in the believe that CAs are a public service and as such they should
> provide public information regarding their operational status. The
> questions outlined below were open ended to provide CAs flexibility in the
> way they approa
On Thu, Mar 26, 2020 at 4:45 PM Ian Carroll via dev-security-policy
wrote:
>
> Hi all,
>
> A recent thread on CAs using contractual terms to revoke certificates has
> made me want to bring up a topic that I am surprised does not come up more:
> removing the control of revocation from CAs and mov
1 - 100 of 1146 matches
Mail list logo
