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
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 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
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.
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 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
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
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
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
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 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
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
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
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
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
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
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
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 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
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 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 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
(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, 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
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 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 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 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
> 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
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
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
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 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
> >
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
(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
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
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
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
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
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
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,
>
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
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 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 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
(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
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
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
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 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 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 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 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
(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 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
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
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
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
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 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 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
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 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'
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 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
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
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
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
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
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 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 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 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 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 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 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 Fri, Sep 20, 2019 at 4:20 PM Curt Spann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> This is a great discussion and I want to thank everyone for their
> continued input. Let me try and summarize my interpretation based on the
> input from this thread and related RFC
I'll share this publicly, so that there's no suggestion that personally or
professionally Google Trust Services is treated any differently than any
other CA. As a publicly trusted CA, I personally find this a deeply
disappointing post towards positive engagement. It's disappointing because
it lacks
On Fri, Sep 20, 2019 at 9:58 AM Rob Stradling wrote:
> On 19/09/2019 21:01, Ryan Sleevi wrote:
>
> > It would be helpful for one of the relevant documents, or another
> > document, or even an errata, to clarify that OCSP services can be
> > offered for pre-certificates. It’s merely
On Thu, Sep 19, 2019 at 2:55 PM Tim Hollebeek
wrote:
> I also don’t think it’s helpful to try to redefine long-standing and
> well-understood terminology like what it means to issue a certificate. In
> fact, I just checked, and using a definition like “reserving a serial
> number” causes many of
On Thu, Sep 19, 2019 at 1:52 PM Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I think that's fine as Mozilla and/or the CABF can and should override
> RFCs when it makes sense to do so, but I think it would also be helpful in
> the long term to fix the dis
Thanks for raising this!
There some some slight past discussion in the CA/B Forum on this -
https://cabforum.org/pipermail/public/2013-November/002440.html - as well
as a little during the SHA-1 deprecation discussions (
https://cabforum.org/pipermail/public/2016-November/008979.html ) and
crypto
On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
>
> > On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > Hi Kurt. I agree, hence why I proposed:
> >
> >
On Mon, Sep 16, 2019 at 6:59 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling wrote:
>
> > On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
> >
> >
> > If a certificate (with embedded SCTs and n
On Mon, Sep 16, 2019 at 3:25 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 16/09/2019 19:08, Andrew Ayer wrote:
> > On Fri, 13 Sep 2019 08:22:21 +
> > Rob Stradling via dev-security-policy
> > wrote:
> >
> >> Thinking aloud...
> >> Does anything ne
a could add a policy to require exactly that, as the
> proposed addition does. But I'm struggling to see the practical value in
> doing so.
>
> Regards,
> Tim
>
> -Original Message-
> From: dev-security-policy
> On Behalf Of Ryan Sleevi via dev-security-pol
Without wanting to be antagonistic, I've come to learn I can count on you
to suggest that X deserves clarification because it's ambiguous, but I've
also learned I have trouble learning where the ambiguity exists or why.
Recall that part of this confusion, regrettably, came from an earnest
attempt t
On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > This means, for example, that (i) a CA must provide OC
Thanks Jeremy,
This is great. I filed https://github.com/mozilla/pkipolicy/issues/188
because this seems like something that can be reused and perhaps even
required by policy.
On Wed, Sep 11, 2019 at 5:59 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
On Wed, Sep 4, 2019 at 11:06 AM Ben Wilson wrote:
> I thought that the EKU "id-kp-OCSPSigning" was for the OCSP responder
> certificate itself (not the CA that issues the OCSP responder certificate).
> I don't think I've encountered a problem before, but I guess it would
> depend
> on the impleme
On Wed, Sep 4, 2019 at 9:47 AM Peter Mate, Erdosi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> My question is the following: is it allowed to issue an OCSP Responder
> certificate with "id-kp-OCSPSigning" EKU from a technically constrained CA
> if the "id-kp-OCSPSignin
On Tue, Sep 3, 2019 at 2:18 PM Santhan via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thursday, August 29, 2019 at 4:37:04 PM UTC-7, Jacob Hoffman-Andrews
> wrote:
> > Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652
> >
> > On 2019.08.28 we read App
On Mon, Sep 2, 2019 at 2:14 PM Alex Cohn via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > If an OCSP server supports returning (or always returns) pro
On Fri, Aug 30, 2019 at 12:06 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> This is super easy, and doesn't even require you to do any work, like
> contacting Google Safe Browsing and asking them to participate in this
> conversation.
>
> Here's the questio
On Fri, Aug 30, 2019 at 11:26 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Is our answer right though? I wasn't sure. I said "Good" because "a
> promise to issue a cert" could be considered the same issued. In that case
> the BRs say you must respond g
On Thu, Aug 29, 2019 at 8:54 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> What the heck does it mean when sometimes you say you are posting "in a
> personal capacity" and sometimes you don't?
It sounds like you were very prescient in your inability to re
On Thu, Aug 29, 2019 at 8:23 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thursday, August 29, 2019 at 5:07:03 PM UTC-7, Ryan Sleevi wrote:
> > On Thu, Aug 29, 2019 at 6:26 PM Kirk Hall via dev-security-policy <
> > dev-security-policy@lists.mozilla.org
On Thu, Aug 29, 2019 at 6:26 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > Could you point to the browsing phishing filters and anti-phishing
> services
> > that do? It might be an opportunity for you to find out how they deal
> with
> > this, and report
On Thu, Aug 29, 2019 at 5:18 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > In this case, the use of EV certificates, and the presumption of
> > reputation, would lead to actively worse security.
> >
> > Did I misunderstand the scenario?
>
> Don't argue wi
On Thu, Aug 29, 2019 at 2:49 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Sure, I’m happy to explain, using Bank of America as an example.
Kirk,
Thanks for providing this example. Could you help me understand how it
helps determine that things are safe?
201 - 300 of 1146 matches
Mail list logo
