On Thursday, April 20, 2017 at 4:03:36 PM UTC+3, Gervase Markham wrote:
> Mozilla also doesn't believe that it's the job of CAs to police phishing
CAs should police as long as the browser gives positive reinforcement to the
end-users when they access a [phishing] site.
There were suggestions in
On 20/04/17 14:02, Gervase Markham wrote:
> I propose this section be removed from the document.
This section has now been removed. Regardless of other points raised,
the issuing of wildcard certs /per se/ is not a Problematic Practice.
Gerv
___
dev-sec
"Incomplete understanding"? That's rich.There is no reliance on certs as a protection mechanism. Rather, the use of certs/encryption help to facilitate my bad acts. If I'm doing malvertising I basically must use a
On Fri, Apr 28, 2017 at 9:48 AM, Peter Kurrasch wrote:
>
> Suppose I want to set up a system to be used for spam, malware
> distribution, and phishing but, naturally, I want to operate undetected.
> First step is to find a (legitimate) server that is already set up and is
> not well secured. Witho
I'll be the first to admit that the example I put together is far from ideal. Perhaps a shortcoming is the lack of any explicit mention regarding the knowledge, skill, competence, etc. of the cert requester--or "s
On Thursday, 27 April 2017 00:42:20 UTC+2, Ryan Sleevi wrote:
> On Wed, Apr 26, 2017 at 5:17 PM, okaphone.elektronika--- via
> dev-security-policy wrote:
> >
> > If this is about the possible consequences of compromise, then I'd say you
> > should try to adres that. But please do come up with som
On Wed, Apr 26, 2017 at 5:17 PM, okaphone.elektronika--- via
dev-security-policy wrote:
>
> If this is about the possible consequences of compromise, then I'd say you
> should try to adres that. But please do come up with something that still
> allows for enough flexibility, so I can arrange the H
On Wednesday, 26 April 2017 22:43:19 UTC+2, Ryan Sleevi wrote:
> On Wed, Apr 26, 2017 at 4:02 PM, okaphone.elektronika wrote:
>
> > I think this is getting weird.
> >
> > At first (some other thread) it get's explained that e.g. LetsEncrypt does
> > not do anything beyond domain validation and po
On Wed, Apr 26, 2017 at 4:02 PM, okaphone.elektronika--- via
dev-security-policy wrote:
> I think this is getting weird.
>
> At first (some other thread) it get's explained that e.g. LetsEncrypt does
> not do anything beyond domain validation and possibly on notification take
> down a few certifi
I think this is getting weird.
At first (some other thread) it get's explained that e.g. LetsEncrypt does not
do anything beyond domain validation and possibly on notification take down a
few certificates of phishing site. And that was "... all OK because we want SSL
to be used everywhere, and
On Wed, Apr 26, 2017 at 3:17 PM, Peter Kurrasch wrote:
> Hi Ryan--
>
> To your first comment, I'm afraid I won't have the time to take a closer
> look at the discussion on 3.2.2.4. Hopefully a path from single domain to
> unlimited domains exists (or will). It makes sense to me (without fully
> c
Hi Ryan--To your first comment, I'm afraid I won't have the time to take a closer look at the discussion on 3.2.2.4. Hopefully a path from single domain to unlimited domains exists (or will). It makes sense to me
On Tue, Apr 25, 2017 at 1:31 AM, Peter Kurrasch via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Wildcard certs present a level of risk that is different (higher?) than
> for other end-entity certs. The risk as I see it is two-fold:
>
> 1) Issuance: Setting aside the mer
Wildcard certs present a level of risk that is different (higher?) than for other end-entity certs. The risk as I see it is two-fold:1) Issuance: Setting aside the merits of the 10 Blessed Methods, there is no cl
On 22/04/17 02:23, Matt Palmer wrote:
> Didn't a CA get caught fairly recently issuing certs with sAN:example.com
> when the validation was for www.example.com, and got a stern talking to as a
> result? I vaguely recall something about that, but not with enough detail
> to trawl the archives looki
On 21/04/17 12:09, Nick Lamb wrote:
> Of the ballot 169 methods, 3.2.2.4.7 is most obviously appropriate
> for verifying that the applicant controls the entire domain and thus
> *.example.com, whereas say 3.2.2.4.6 proves only that the applicant
> controls a web server, it seems quite likely they h
On Sun, Apr 23, 2017 at 7:41 AM, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I was thinking of things like the GoDaddy incident reported in January
> where they had mistakenly been accepting HTTP 404s to validate a domain or
> the 2016 Comodo "re-dressing"
On Saturday, 22 April 2017 02:24:50 UTC+1, Matt Palmer wrote:
> Can you remind me (and the list) what specific instances you're referring
> to?
I was thinking of things like the GoDaddy incident reported in January where
they had mistakenly been accepting HTTP 404s to validate a domain or the 20
On Fri, Apr 21, 2017 at 02:12:51AM -0700, Nick Lamb via dev-security-policy
wrote:
> On Thursday, 20 April 2017 14:03:36 UTC+1, Gervase Markham wrote:
> > I propose this section be removed from the document.
>
> I am not so sure the section ought to be removed. Wildcard DV is
> potentially probl
On Fri, Apr 21, 2017 at 04:09:57AM -0700, Nick Lamb via dev-security-policy
wrote:
> Of the ballot 169 methods, 3.2.2.4.7 is most obviously appropriate for
> verifying that the applicant controls the entire domain and thus
> *.example.com, whereas say 3.2.2.4.6 proves only that the applicant
> con
On Friday, 21 April 2017 11:02:01 UTC+1, Gervase Markham wrote:
> This is all a bit inchoate :-) Can you give me any idea at all of what
> such a policy would look like? Requiring OV is not an option IMO.
Yes, it's inchoate, if I had a fully filled out policy in mind here I'd be
proposing that p
On 21/04/17 10:12, Nick Lamb wrote:
> I'm not so uncomfortable with it that I want Mozilla to try to get it
> stopped, but I think signalling some residual discomfort here is
> worthwhile until somebody has thought through a good policy, and
> preferably at least got the big CAs to go along with it
On Thu, Apr 20, 2017 at 4:02 PM, Gervase Markham via
dev-security-policy wrote:
> I don't believe the issuance of wildcard DV certs is problematic in
> practice. Mozilla is of the view that ubiquitous SSL is the highest
> priority for the Web PKI, and wildcard certs are a part of that. Mozilla
> a
On Thursday, 20 April 2017 14:03:36 UTC+1, Gervase Markham wrote:
> I propose this section be removed from the document.
I am not so sure the section ought to be removed. Wildcard DV is potentially
problematic. Historically we have seen problems that wouldn't have happened or
would be much less
Major +1. Removing this language is consonant with Mozilla objectives, with
Web PKI trends, and with the health of the open web.
-- Eric
On Thu, Apr 20, 2017 at 9:02 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> There is an entry on Mozilla's Poten
On Thu, Apr 20, 2017 at 02:02:59PM +0100, Gervase Markham via
dev-security-policy wrote:
> I propose this section be removed from the document.
My name is Matt Palmer, and I endorse this proposal.
- Matt
___
dev-security-policy mailing list
dev-secu
+1 on removal, that paragraph doesn't square with current ideas about
what's problematic in the WebPKI; as you've noted wildcards and DV are
really orthogonal concerns.
Alex
On Thu, Apr 20, 2017 at 9:02 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
27 matches
Mail list logo
