Re: On GitHub, Leaked Keys, and getting practical about revocation

On Thu, Jun 22, 2017 at 1:59 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Please note that Apache and NGINX are by far not the only TLS servers > that will need working OCSP stapling code before must-staple can become > default or the only method checked

Re: On GitHub, Leaked Keys, and getting practical about revocation

On Thu, Jun 22, 2017 at 3:53 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 22/06/2017 15:02, Ryan Sleevi wrote: > > On Thu, Jun 22, 2017 at 1:59 PM Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > (Snip

Re: Machine- and human-readable format for root store information?

On Mon, Jun 26, 2017 at 9:50 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > A few root store operators at the recent CAB Forum meeting informally > discussed the idea of a common format for root store information, and > that this would be a good

Re: Machine- and human-readable format for root store information?

On Tue, Jun 27, 2017 at 9:58 AM Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 27/06/17 04:16, Rob Stradling wrote: > > If the aim is to replace certdata.txt, authroot.stl, etc, with this new > > format, then I'm more interested. > > I can't speak for

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 1:41 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, May 22, 2017 at 11:50:59 AM UTC-5, Gervase Markham wrote: > > > How do the various validation routines in the field today validate a > > > scenario in which a

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 12:50 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 22/05/17 16:43, Matthew Hardeman wrote: > > Regarding specifically the risk of the holder of a technically > > constrained subCA issuing a certificate with an SHA-1

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 4:34 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I'm not certain that I accept the premise that TCSCs fundamentally or > substantively change that dynamic. Particularly if the validity period of > the TCSC is limited in

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 5:35 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > It is within the above that I can see a real problem in making more broad > use of TCSCs problematic. If the browser community does not effectively > move in the fashion

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 7:58 PM, Peter Bowen wrote: > > Why do you need to add 10,000 communication points? A TCSC is, by > definition, a subordinate CA. The WebPKI is not a single PKi, is a > set of parallel PKIs which do not share a common anchor. The browser > to CA

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 9:34 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I even concede that that alone does create a potential for compatibility > issues should a need arise to make a global web pki-wide change to > certificate issuance (say,

Re: Mozilla Policy and CCADB Disclosure scope

On Tue, May 23, 2017 at 9:45 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > * TCSCs can, by their existing definition, be programmatically > recognized by certificate validation code e.g. in browsers and other > clients. > In theory, true. In practice,

Re: Mozilla Policy and CCADB Disclosure scope

On Tue, May 23, 2017 at 11:52 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Note as this is about a proposed future policy, this is about validation > code updated if and when such a policy is enacted. Current validation > code has no reason to check a

Re: Google Plan for Symantec posted

On Mon, May 22, 2017 at 12:33 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 19/05/17 21:04, Kathleen Wilson wrote: > > - I'm not sold on the idea of requiring Symantec to use third-party > > CAs to perform validation/issuance on Symantec's

Re: Mozilla Policy and CCADB Disclosure scope

On Tue, May 23, 2017 at 12:33 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I just think there's no need to concern themselves if someone quite clever > (whatever that means) decides to ASN.1 encode a Trollface GIF and roll that > into an EE cert

Re: Google Plan for Symantec posted

On Sat, May 20, 2017 at 11:12 AM, Michael Casadevall via dev-security-policy wrote: > On 05/19/2017 05:43 PM, Kurt Roeckx wrote: > >>From the mail about Chrome's plan, I understand that Chrome's plan > > is to only allow certificates from the old PKI if

Re: Mozilla Policy and CCADB Disclosure scope

On Tue, May 23, 2017 at 3:45 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tuesday, May 23, 2017 at 12:39:05 PM UTC-5, Ryan Sleevi wrote: > > > Setting aside even the 'damage' aspect, consider the ecosystem impact. > > Assume a wildwest - we

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On Fri, May 19, 2017 at 11:04 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 19/05/2017 16:15, Gervase Markham wrote: > >> On 19/05/17 14:58, Jakob Bohm wrote: >> >>> Because the O and other dirname attributes may be shown in an e-mail >>> client

Re: Configuring Graduated Trust for Non-Browser Consumption

On Tue, May 16, 2017 at 9:54 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 16/05/2017 15:23, Alex Gaynor wrote: > >> That's not an appropriate way to participate in a mailing list, please >> communicate civilly. >> >> > Sorry about the flaming, but he

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

On Tue, May 16, 2017 at 11:12 AM, Alex Gaynor via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Fewer round trips, if you can include everything in a single response. > So fewer round-trips if same-size, or bigger data set if you're anything newer than 6 years

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Thu, Jun 1, 2017 at 10:19 PM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, Jun 1, 2017 at 5:49 AM, Ryan Sleevi via dev-security-policy > > So I would definitely encourage that improper application of the > protocols &g

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

I liked your previous version better, if it had to be updated. It would sound like you're suggesting "Enterprise RA" accounts should not use multi-factor authentication, but given that they're part of the scope of audited activities (that the CA must directly oversee), the use of multi-factor

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen wrote: > On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi wrote: > Yes, my concern is that this could make SIGNED{ToBeSigned} considered > misissuance if ToBeSigned is not a TBSCertificate. For example, if I > could

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Fri, Jun 2, 2017 at 10:09 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 02/06/2017 15:54, Ryan Sleevi wrote: > > On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen wrote: > > > >> On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi

Re: On remedies for CAs behaving badly

On Mon, Jun 5, 2017 at 11:52 AM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Has there ever been an effort by the root programs to directly assess > monetary penalties to the CAs -- never for inclusion -- but rather as part > of a remediation

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Wed, Jun 7, 2017 at 11:25 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Note that I also had a second, related, point: The possibility that such > a new piece of infrastructure was, for other reasons, not endorsed by > Mozilla, but of great interest

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

On Thu, Jun 1, 2017 at 6:52 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Doug, > > On 01/06/17 10:54, Doug Beattie wrote: > > Can you give some examples of validation functions that need to be > enforced by multifactor authentication? There are

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Thu, Jun 1, 2017 at 4:35 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 31/05/17 18:02, Matthew Hardeman wrote: > > Perhaps some reference to technologically incorrect syntax (i.e. an > incorrectly encoded certificate) being a mis-issuance? > >

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Mon, Jun 5, 2017 at 6:21 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > If you read the paper, it contains a proposal for the CAs to countersign > the computed super-crl to confirm that all entries for that CA match the > actual revocations and

Re: New undisclosed intermediates

On Tue, Jun 6, 2017 at 5:13 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 05/06/17 14:29, Alex Gaynor wrote: > > As I've expressed before, I find it baffling that this still happens. > > I am also disappointed. I have half a mind to keep track of

Re: New undisclosed intermediates

On Thu, Jun 8, 2017 at 10:16 PM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > There are two important things about self-issued certificates: > > 1) They cannot expand the scope of what is allowed. > Cross-certificates can create alternative paths with

Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

On Mon, May 1, 2017 at 1:53 PM, Lee via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 5/1/17, Gervase Markham via dev-security-policy > wrote: > > The last CA Communication laid down our policy of only permitting the 10 > >

Re: Symantec: Draft Proposal

Gerv, Regarding your understanding of the “First Chrome Proposal”, which seems to have influenced your “Alternative” suggestions, some quick clarifications: (Wearing a Chrome/Google hat here) The first Chrome proposal was operating on the concern that a complete and total removal of trust

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Tue, Jun 6, 2017 at 2:28 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I am saying that setting an administrative policy for inclusion in a > root program is not the place to do technical reviews of security > protocols. Of course it is. It is the

Re: CAA Certificate Problem Report

On Mon, Sep 11, 2017 at 3:09 PM Jonathan Rudenberg via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > >

Re: Old roots to new roots best practice?

m: dev-security-policy > [mailto:dev-security-policy-bounces+ben=digicert....@lists.mozilla.org] On > Behalf Of Ryan Sleevi via dev-security-policy > Sent: Sunday, September 17, 2017 7:57 PM > To: userwithuid <userwith...@gmail.com> > Cc: mozilla-dev-security-policy > <

Re: FW: StartCom inclusion request: next steps

On Mon, Sep 18, 2017 at 8:12 AM, Inigo Barreira wrote: > > We are not seeking to identify personal blame. We are seeking to > understand what, if any, improvements have been made to address such > issues. In reading this thread, I have difficulty finding any discussion >

Re: FW: StartCom inclusion request: next steps

On Fri, Sep 15, 2017 at 12:30 PM, Inigo Barreira via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > > Hi Inigo, > > > > On 14/09/17 16:05, Inigo Barreira wrote: > > > Those tests were done to check the CT behaviour, there was any other > > testing of the new systems,

Re: Old roots to new roots best practice?

Hi there, I agree, Gerv's remarks are a bit confusing with respect to the concern. You are correct that the process of establishing a new root generally involves the creation of a self-signed certificate, and then any cross-signing that happens conceptually creates an 'intermediate' - so you have

Re: DigiCert-Symantec Announcement

On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi everyone, > > > > Today, DigiCert and Symantec announced that DigiCert is acquiring the > Symantec CA assets, including the infrastructure, personnel, roots, and > platforms.

Re: DigiCert-Symantec Announcement

Jeremy, Thanks for attaching the diagrams - this is very useful in helping visualize out the graph! Special thanks for detailing out the validation flow DigiCert both practices and plans to practice - this level of transparency goes a long way to helping assess and understand both risks and

Re: PROCERT issues

On Mon, Oct 2, 2017 at 10:42 AM, Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, September 29, 2017 at 2:52:49 PM UTC-7, Eric Mill wrote: > > That dynamic is natural, but accepting that this dynamic exists is > > different than giving into it

Re: PROCERT issues

Hi Kathleen, With respect to providing a list - is there any requirement to ensure Mozilla accepts that as a reasonable remediation? For example, would "We plan to not do the same in the future" be an acceptable remediation plan? As currently worded, it would seem to meet the letter of this

Re: PROCERT issues

On Fri, Sep 8, 2017 at 2:39 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 07/09/2017 17:17, Gervase Markham wrote: > >> Mozilla has decided that there is sufficient concern about the >> activities and operations of the CA "PROCERT" to collect together

Re: Violations of Baseline Requirements 4.9.10

On Tue, Aug 29, 2017 at 8:47 AM, Paul Kehrer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Symantec / GeoTrust > > CCADB does not list an email address. Not CC'd. > > DN: C=IT, O=UniCredit S.p.A., CN=UniCredit Subordinate External > Example cert: >

Re: Idea for a stricter name constraint interpretation

On Thu, Sep 7, 2017 at 1:20 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All but one of your suggestions would require the revocation of existing > SubCA certificates, essentially invalidating all existing uses of > certificates issued by those SubCAs

Re: PROCERT issues

On Thu, Sep 7, 2017 at 11:17 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Mozilla has decided that there is sufficient concern about the > activities and operations of the CA "PROCERT" to collect together our > list of current concerns. That list

Re: Idea for a stricter name constraint interpretation

On Thu, Sep 7, 2017 at 5:22 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 07/09/2017 21:00, Ryan Sleevi wrote: > Then there is your suggestion of requiring technically constrained >> >>> SubCAs (that were constrained under a previous set of relevant

Re: CAA Certificate Problem Report

That seems like very poor logic and justification. Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for literally years now, perhaps it's worth asking why CAs are only now discovering issues. That is, is the only reason we're discovering issues because CAs waited for the last

Re: Idea for a stricter name constraint interpretation

On Fri, Sep 1, 2017 at 2:07 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > RFC2818 postdates real world https by several years. The original de > facto standard by Netscape/Mozilla used the commonName semantics, which > survived for more than a decade in

Re: Idea for a stricter name constraint interpretation

On Thu, Aug 31, 2017 at 8:18 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Would it be beneficial to Mozilla in particular and the larger PKI > community in general if the following was added to implementations: > Hi Jakob, This was rather extensively

Re: Idea for a stricter name constraint interpretation

On Thu, Aug 31, 2017 at 4:13 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I am aware that this was the original specification. However like many > other parts of PKIX it may not be as good in 20/20 hindsight. Agreed. But in general, in order to

Re: Idea for a stricter name constraint interpretation

On Thu, Aug 31, 2017 at 5:21 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 31/08/2017 22:26, Ryan Sleevi wrote: > >> Agreed. But in general, in order to maintain interoperability, there's a >> process for building consensus, and repurposing extensions

Re: Mozilla RSA-PSS policy

On Thu, Nov 23, 2017 at 7:07 AM, Hubert Kario via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > In response to comment made by Gervase Markham[1], pointing out that > Mozilla > doesn't have an official RSA-PSS usage policy. > > This is the thread to discuss it and make a

Re: Mozilla RSA-PSS policy

On Mon, Nov 27, 2017 at 12:54 PM, Hubert Kario wrote: > > > On the realm of CA policy, we're discussing two matters: > > 1) What should the certificates a CA issue be encoded as > > 2) How should the CA protect and use its private key. > > > > While it may not be immediately

Re: Mozilla RSA-PSS policy

On Tue, Nov 28, 2017 at 8:04 AM, Hubert Kario wrote: > On Monday, 27 November 2017 23:37:59 CET Ryan Sleevi wrote: > > On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario wrote: > > > > So no, we should not assume well-meaning actors, and we should be > > > > > >

Re: Mozilla RSA-PSS policy

On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario wrote: > > > First, I absolutely disagree with your assumption - we need to assume > > hostility, and design our code and policies to be robust against that. I > > should hope that was uncontroversial, but it doesn't seem to be. > >

Re: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names

On Mon, Nov 27, 2017 at 8:29 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 27/11/2017 19:37, Nick Lamb wrote: > >> On Fri, 24 Nov 2017 12:25:40 + >> Gervase Markham via dev-security-policy >> wrote: >> >>

Re: Possible future re-application from WoSign (now WoTrus)

On Wed, Nov 22, 2017 at 11:16 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Mozilla did not formally require this, but it is true that as far as we >> can see, Richard Wang is still effectively in charge of WoSign/WoTrus. >> >> > I think assessing and

Re: Mozilla RSA-PSS policy

On Wed, Nov 29, 2017 at 7:55 AM, Hubert Kario via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > > The fact that this new NSS implementation does not properly validate the > > well-formedness of these signatures is somewhat in conflict with your > > statement: > > ""it

Re: Mozilla RSA-PSS policy

On Wed, Nov 29, 2017 at 1:09 PM, Hubert Kario wrote: > > The extent of the argument for flexibility, so far, has been OpenSSL's > > behaviour to produce RSA-PSS signatures with a maximal salt length. These > > same clients are also incapable of parsing RSA-PSS SPKIs (that only

Re: Mozilla RSA-PSS policy

On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario wrote: > if the certificate is usable with PKCS#1 v1.5 signatures, it makes it > vulnerable to attacks like the Bleichenbacher, if it is not usable with > PKCS#1 > v1.5 it's not vulnerable in practice to such attacks > A

Re: Anomalous Certificate Issuances based on historic CAA records

On Thu, Nov 30, 2017 at 3:12 PM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The problem DNSSEC checks for CAA was intended to solve was the fact that > it > is certainly possible that a well-resourced attacker can manipulate the DNS > responses that

Re: Mozilla RSA-PSS policy

On Thu, Nov 30, 2017 at 3:23 PM, Hubert Kario wrote: > On Thursday, 30 November 2017 18:46:12 CET Ryan Sleevi wrote: > > On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario > wrote: > > > if the certificate is usable with PKCS#1 v1.5 signatures, it makes it > >

Re: Anomalous Certificate Issuances based on historic CAA records

Right, and to my point: Each transparency mechanism has to be specific to the problem it's trying to solve. CT is not a magic cureall for transparency - it's specific to, well, certificates, and more generally, TLS web certificates. For things like S/MIME, you have "Key Transparency" (based on

Re: Anomalous Certificate Issuances based on historic CAA records

On Thu, Nov 30, 2017 at 4:02 AM, Quirin Scheitle via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Similar to the GlobalSign discussion, it is well possible that the domain > briefly disabled their CAA records when you did the check — and re-enabled > them later. > I

Re: Ampersands in intermediates' PrintableString

On Mon, Dec 4, 2017 at 8:37 PM, J.C. Jones via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All, > > Just an interesting heads up: > > While we were doing some maintenance on the CCADB, Chris Henderson found > Golang could not process several of Wells Fargo's intermediate

Re: Mozilla RSA-PSS policy

On Fri, Dec 1, 2017 at 12:34 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 01/12/2017 17:06, Ryan Sleevi wrote: > >> On Fri, Dec 1, 2017 at 10:33 AM, Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> >>>

Re: Mozilla RSA-PSS policy

On Fri, Dec 1, 2017 at 11:20 AM, Hubert Kario wrote: > On Friday, 1 December 2017 17:11:56 CET Ryan Sleevi wrote: > > On Fri, Dec 1, 2017 at 10:23 AM, Hubert Kario wrote: > > > and fine for NSS too, if that changes don't have to be implemented in > next > >

Re: On the value of EV

On Fri, Dec 15, 2017 at 5:38 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, December 15, 2017 at 4:06:02 PM UTC-6, Ryan Sleevi wrote: > > > It also perpetuates the myopic and flawed view as a phishing mitigation, > > whose reliance is upon

Re: Mississuance of EV Certificates

On Tue, Dec 12, 2017 at 10:18 AM, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > The implemented controls detected the misconfiguration within 24 > > hours. The incorrect configuration was nevertheless recorded as a > > security incident. The handling of

Re: On the value of EV

On Tue, Dec 12, 2017 at 8:36 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 12/12/2017 01:08, Adam Caudill wrote: > >> Even if it is, someone filed the paperwork. Court houses have clerks, > guards, video cameras, etc... It still may present a

Re: On the value of EV

On Tue, Dec 12, 2017 at 1:11 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > The overall thing is that the current thread seems to be a major case of > throwing the baby out with the bathwater. > That is overly reductive and may demonstrate a lack of

Re: CABF Recommendations (was: On the value of EV)

On Sun, Dec 17, 2017 at 6:38 PM, Peter Kurrasch via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Again I will state that it's in the best interests of CA's to improve > their EV issuing guidelines and practices. While CA's no doubt enjoy > charging a premium for EV

Re: Mississuance of EV Certificates

On Mon, Dec 18, 2017 at 9:30 AM, cornelia.enke66--- via dev-security-policy wrote: > > Update on the long-term countermeasures: > At the first point - sorry for the delay. I missed to post my answer on > Fryday. > > We The occurred error caused by a human

Re: On the value of EV

On Sun, Dec 17, 2017 at 4:45 PM, Peter Kurrasch via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Second, the actual value in EV as far as I can see is in having that human > readable name in addition to the domain name. A successful plan of attack > will need convincing

Re: On the value of EV

On Mon, Dec 18, 2017 at 1:26 PM, Andrew via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, December 15, 2017 at 4:06:02 PM UTC-6, Ryan Sleevi wrote: > > It also perpetuates the myopic and flawed view as a phishing mitigation, > > whose reliance is upon users

Re: On the value of EV

On Mon, Dec 18, 2017 at 4:09 PM, Wayne Thayer wrote: > Thank you Ryan for raising this question, and to everyone who has been > contributing in a constructive manner to the discussion. A number of > excellent points have been raised on the effectiveness of EV in general and

Re: On the value of EV

arly encourage better ecommerce behaviors? > > > On Mon, Dec 18, 2017 at 1:27 PM, Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Mon, Dec 18, 2017 at 1:26 PM, Andrew via dev-security-policy < >> dev-security-policy@li

Re: On the value of EV

On Thu, Dec 14, 2017 at 5:01 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 14/12/2017 00:23, Peter Gutmann wrote: > > Tim Shirley via dev-security-policy < > dev-security-policy@lists.mozilla.org> writes: > > > >> But regardless of which (or neither)

Re: On the value of EV

On Fri, Dec 15, 2017 at 2:34 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 15/12/2017 02:30, Ryan Sleevi wrote: > > Some participants have pointed out correlation is not causation - that > you > > can’t infer that never being attacked by a tiger while

Re: On the value of EV

On Fri, Dec 15, 2017 at 4:26 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, December 15, 2017 at 3:08:32 PM UTC-6, Ryan Sleevi wrote: > > > Respectfully, this is the tiger-repelling rock. We can't show that any > > tigers attacked,

Re: On the value of EV

On Fri, Dec 15, 2017 at 4:50 PM, Tim Shirley wrote: > I don’t see how you can argue that the EV “seatbelt” breaks 100% of the > time. I know my bank uses an EV cert. Any time I come across a site > claiming to be my bank but lacking an EV cert, and my browser shows me

Re: On the value of EV

On Fri, Dec 15, 2017 at 2:34 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, December 15, 2017 at 8:08:44 AM UTC-6, Ryan Sleevi wrote: > > > James’ research has showed the ease at which it is possible to use the UI > > afforded EV to

Re: On the value of EV

If the signal can be spoofed, it does not actually help keep you safe. On Fri, Dec 15, 2017 at 5:21 PM, Tim Shirley wrote: > Yeah we’re definitely talking past each other. I’m not claiming the extra > signal CAN’T be spoofed, nor am I claiming that EV prevents phishing

Re: CAA records checked against immediate issuer or root?

On Fri, Dec 15, 2017 at 5:05 PM, Jan Schaumann via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hello, > > I'm seeking clarification on the meaning of the CAA records: > > RFC6844 notes that the 'issue' property entry "authorizes the holder of > the domain name *or a

Re: On the value of EV

I agree. Just like "could" repel tigers is different than "does" repel tigers. On Fri, Dec 15, 2017 at 5:30 PM, Tim Shirley wrote: > I’m saying “can” be spoofed is different than “is” being spoofed. > > > > *From: *Ryan Sleevi > *Reply-To:

Re: On the value of EV

Of course not - facetious or not, it’s similarly logically and empirically flawed. On Wed, Dec 13, 2017 at 7:29 PM Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I don't want to spend too much time digressing into a discussion of the > same > origin

Re: On the value of EV

On Wed, Dec 13, 2017 at 6:23 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I realize I'm doing a poor job at articulating the profound risks, > perhaps > > because they're best not for e-mail discussions, but these problems are > not > > unique

Re: CA generated keys

On Wed, Dec 13, 2017 at 11:06 AM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Wayne, > > For TLS/SSL certificates, I think PKCS #12 delivery of the key and > certificate > at the same time should be allowed, and I have no problem with a > requirement

Re: CA generated keys

Tim, I appreciate your reply, but that seems to be backwards looking rather than forwards looking. That is, it looks and assumes static-RSA ciphersuites are acceptable, and thus the entropy risk to TLS is mitigated by client-random to this terrible TLS-server devices, and the issue to mitigate is

Re: On the value of EV

On Wed, Dec 13, 2017 at 1:19 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I would be sorely disappointed Prepare to be sorely disappointed > and consider it a security bug It is not a bug. It is not part of the security boundary of the Web, thus

Re: On the value of EV

On Wed, Dec 13, 2017 at 12:58 PM, Tim Shirley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > As an employee of a CA, I’m sure many here will dismiss my point of view > as self-serving. But when I am making trust decisions on the internet, I > absolutely rely on both

Re: CA generated keys

On Wed, Dec 13, 2017 at 1:24 PM, Matthew Hardeman wrote: > As I pointed out, it can be demonstrated that quality ECDHE exchanges can > happen assuming a stateful DPRNG with a decent starting entropy corpus. > Agreed - but that's also true for the devices Tim is mentioning.

Re: On the value of EV

Right, but both Ian and James' research show that it's an unreliable guarantee for those attacks - you may be relying on it, but it's not safe for it. Further, the costs to support your use case - well-intentioned but perhaps not aligning with the pragmatic reality - affect users who don't do so

Re: On the value of EV

On Wed, Dec 13, 2017 at 3:50 PM, Tim Shirley wrote: > I’m not looking for a guarantee. Nothing is ever going to meet that > standard. What I’m looking for is something that’s going to improve my > odds. What I see in Ian’s and James’s research is some ways that it’s >

Re: On the value of EV

On Tue, Dec 12, 2017 at 3:44 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > What you are writing below, with far too many words is that you think > that URLs are the only identities that matter in this world, and > therefore DV certificates are enough

Re: On the value of EV

On Wed, Dec 13, 2017 at 6:29 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > Yes. This is the foundation and limit of Web Security. > > > > https://en.wikipedia.org/wiki/Same-origin_policy > > > > This is what is programatically enforced. Anything else

Re: On the value of EV

On Wed, Dec 13, 2017 at 4:14 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, December 11, 2017 at 6:01:25 PM UTC-6, Ryan Sleevi wrote: > > > > Not really - what matters is that the user insists they got had via a > > > phishing link or

Re: On the value of EV

On Wed, Dec 13, 2017 at 4:28 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, December 13, 2017 at 2:46:10 PM UTC-6, Gervase Markham wrote: > > > My concern with this argument is that it's susceptible to the criticism > > that Adam

Re: On the value of EV

On Wed, Dec 13, 2017 at 4:40 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tuesday, December 12, 2017 at 3:52:40 PM UTC-6, Ryan Sleevi wrote: > > > Yes. This is the foundation and limit of Web Security. > > > >

<    1   2   3   4   5   6   7   8   9   10   >