Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

I see both sides on this matter. On the one hand, certlint/cablint catches lots of obvious problems, mostly with ridiculous certificate profiles or manual special purpose issuances. Certainly, there's a lot of bad issuance that having it in the blocking path might help with... but... If one

Re: Misissued certificates

I don't know whether it was noticed or if it matters to anyone, but I did note that for at least one of these certificates, particularly the one at https://crt.sh/?id=92235996 , that the sole SAN dnsName for the certificate is ev-expired.identrustssl.com. The cert also had a whopping 24 hours

Re: Certificates with common names not present in their SANs

Didn't someone recently float the argument that the native u-label was required by local regulation / custom (in China) to be included and so they stuffed it into the CN? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Certificates with less than 64 bits of entropy

On Thursday, August 10, 2017 at 11:27:53 AM UTC-5, Nick Lamb wrote: > The truth is that there is no positive test for randomness, any work in this > area is going to end up needing a judgement call, so I think inconveniencing > the CAs even a small amount with such a policy change just to make

Re: Misissued certificates

Similarly, the cert at https://crt.sh/?id=92235998 has SAN dnsName of ev-valid.identrustssl.com It has a normal 2 year validity period. Which again sounds like a certificate administratively created to serve as a test point certificate for the root programs.

Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

Hi all, I was just reading through the baseline requirements -- specifically 3.2.2.4 and its children -- and noted that while there are particular standards as to the blessed methods of validation of authority & control for domain names (and host names within domain names), there is nothing

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

> Yes, however I don't think Matthew's concern was about systems owned by the > CA but rather systems proximate to them in the network. For example if the CA > purchases Internet service from a single local Internet Service Provider, the > BRs obviously don't require that this ISP have all the

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

One (Hypothetical) Concrete Example of a Practical DNS Validation Attack: (Author's note: I've chosen for this example to utilize the Let's Encrypt CA as the Certificate Authority involved and I have chosen as a target for improper validation the domain eff.org. Neither of these is in any way

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

On Thursday, July 20, 2017 at 8:13:23 PM UTC-5, Nick Lamb wrote: > On Friday, 21 July 2017 01:13:15 UTC+1, Matthew Hardeman wrote: > > As easily as that, one could definitely get a certificate issued without > > breaking most of the internet, without leaving much of a trace, and without > >

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

On Thursday, July 20, 2017 at 3:32:29 PM UTC-5, Ryan Sleevi wrote: > Broadly, yes, but there's unfortunately a shade of IP issues that make it > more difficult to contribute as directly as Gerv proposed. Gerv may accept > any changes to the Mozilla side, but if the goal is to modify the Baseline

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

It seems that a group of Princeton researchers just presented a live theoretical* misissuance by Let's Encrypt. They did a sub-prefix hijack via a technique other than those I described here and achieved issuance while passing-through traffic for other destination within the IP space of the

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

On Monday, July 24, 2017 at 2:49:20 AM UTC-5, Gervase Markham wrote: > On 20/07/17 21:31, Ryan Sleevi wrote: > > Broadly, yes, but there's unfortunately a shade of IP issues that make it > > more difficult to contribute as directly as Gerv proposed. Gerv may accept > > any changes to the Mozilla

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

On Thursday, July 20, 2017 at 9:39:40 AM UTC-5, Gervase Markham wrote: > Your point, in the abstract, is a reasonable one, but so is your further > point about trade-offs. The only way we can really make progress is for > you to propose specific changes to the language, and we can then discuss >

Re: Certificates with invalidly long serial numbers

It seems this thread has diverged a bit from its stated purpose, the determination of the question of mis-issuance of a set of certificates which have (possibly) longer than allowed serial numbers. I raised a question as to the history of the selection of the 20 bytes limit for serial numbers

Re: StartCom cross-signs disclosed by Certinomis

To play the devil's advocate... If everything is as Mr. Leroy of Certinomis points out, I don't see the problem with the cross-sign. In that version of events, the vast majority of the issues in the new PKI (test certs, etc) had already been revoked and measures put in place to prevent that

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

> Do we really want the CA community to be filled with bureaucratic > enforcement of harsh punishments for every slight misstep? This is the > important question that any organization (in this case this community) > needs to ask itself whenever new surveillance abilities make it possible > to

Re: Certificates with invalidly long serial numbers

On Monday, August 7, 2017 at 5:20:13 PM UTC-5, Ryan Sleevi wrote: > This is entirely unnecessary and would present serious stability issues due > to backwards compatibility. > > It may not be appropriate for this thread - discussing specific misissuances > - but there is zero benefit from

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

On Tuesday, July 25, 2017 at 1:00:39 PM UTC-5, birg...@princeton.edu wrote: > We have been considering research in this direction. PEERING controls several > ASNs and may let us use them more liberally with some convincing. We also > have the ASN from Princeton that could be used with

Re: Certificates with invalidly long serial numbers

It is what it is, I'm sure, but that definition in RFC5280 is rather tortured and leads to ambiguity as to whether or not the leading 0x00 is. In fact, I would say that it is not part of the integer value but rather an explicit sign flag required by the encoding mechanism. Wouldn't it have

Re: PROCERT issuing certificates with non-random serial numbers

Just from the posted serial numbers, it looks almost like the high order bits may represent 32 bits of random, which is still far short of the requirement. Perhaps they intended a 48 bit sequential counter after a 32 bit random, or intended a 64 bit random followed by a 16 bit sequential

Re: New undisclosed intermediates

On Thursday, June 8, 2017 at 7:44:08 PM UTC-5, Ben Wilson wrote: > I don't believe that disclosure of root certificates is the responsibility > of a CA that has cross-certified a key. For instance, the CCADB interface > talks in terms of "Intermediate CAs". Root CAs are the responsibility of >

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Tuesday, June 20, 2017 at 2:15:57 PM UTC-5, annie nguyen wrote: > Dropbox, GitHub, Spotify and Discord (among others) have done the same > thing for years: they embed SSL certificates and private keys into their > applications so that, for example, open.spotify.com can talk to a local >

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

On Monday, June 19, 2017 at 11:40:22 PM UTC-5, Tom Ritter wrote: > So at what point does the CA become culpable to misissuance in a case > like this? Is it okay that we let them turn a blind eye to issuing or > reissuing certificates where they have a strong reason to believe the > private key

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Wednesday, June 21, 2017 at 1:43:18 AM UTC-5, jacob.hoff...@gmail.com wrote: > > It's been an on-going question for me, since the use case (as a software > > developer) is quite real: if you serve a site over HTTPS and it needs to > > communicate with a local client application then you need

On GitHub, Leaked Keys, and getting practical about revocation

Hi all, I'm sure questions of certificates leaked to the public via GitHub and other file sharing / code sharing / deployment repository hosting and sharing sites have come up before, but last night I spent a couple of hours constructing various search criteria which I don't think were even

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Wednesday, June 21, 2017 at 12:41:53 PM UTC-5, andre...@gmail.com wrote: > I feel like this is getting sort of off-topic. Web pages can communicate > directly with applications on the local machine regardless of whether they > abuse certificates in this way or not. (Such as, for example, by

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

I wonder if the device intercepts DNS queries within the LAN for that address and substitutes in the IP of the appliance instead of 127.0.0.1. Is it often deployed as the customer premise NAT/router in addition to serving video purposes? I'm thinking they probably wanted some other devices or

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Wednesday, June 21, 2017 at 4:59:01 AM UTC-5, Ryan Sleevi wrote: > > There are several distinct issues: > 127.0.0.0/8 (and the associated IPv6 reservations ::1/128) > "localhost" (as a single host) > "localhost" (as a TLD) > > The issues with localhost are (briefly) caught in >

Re: Mozilla Policy and CCADB Disclosure scope

Thanks, Nick, for the comment on the scope difference in the dnsName constraints vs. SAN wildcard. I hadn't contemplated that. As you note, the real risk isn't dissimilar. (I would presume that this is because a CA willing to issue a SAN dnsName of *.example.com would also presumably issue a

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 11:50:59 AM UTC-5, Gervase Markham wrote: > So your proposal is that technical requirements should be enforced > in-product rather than in-policy, and so effectively there's no need for > policy for the EE certs under a TCSC. > > This is not an unreasonable position. >

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 2:43:14 PM UTC-5, Peter Bowen wrote: > > I would say that any CA-certificate signed by a CA that does not have > name constraints and not constrained to things outside the set > {id-kp-serverAuth, id-kp-emailProtection, anyEKU} should be disclosed. > This would mean

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 2:14:57 PM UTC-5, Ryan Sleevi wrote: > Another approach is to make an argument that such validations are already > accounted for in the EV Guidelines, in which a certificate may be issued > for 27 months, but for which the domain must be revalidated at 13 months. > In

Re: Mozilla Policy and CCADB Disclosure scope

> > Right now the list excludes anything with a certain set of name > constraints and anything that has EKU constraints outside the in-scope > set. I'm suggesting that the first "layer" of CA certs always should > be disclosed. > I understand now. In that, I fully concur.

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 2:21:41 PM UTC-5, Ryan Sleevi wrote: > > > Regarding specifically the risk of the holder of a technically > > > constrained subCA issuing a certificate with an SHA-1 signature or > > > other improper signature / algorithm, my belief at this time is that > > > with

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 3:50:30 PM UTC-5, Ryan Sleevi wrote: > Right, but I reject that :) > I hope to better understand your position. In transitioning from a long time lurker to actively commenting on this list, it is my hope to contribute what that I usefully can, bow out gracefully

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 7:24:42 PM UTC-5, Ryan Sleevi wrote: > https://groups.google.com/d/msg/mozilla.dev.security.policy/yS_L_OgI5qk/OhLX9iyZBAAJ > specifically proposed > > "For example, no requirement of audit by the enterprise holding the > technically constrained intermediate, and no

Re: Mozilla Policy and CCADB Disclosure scope

On Tuesday, May 23, 2017 at 10:53:03 AM UTC-5, Jakob Bohm wrote: > > Or could this be solved by require such "TCSC light" SubCA certs to > carry a specific CAB/F policy OID with CT-based community enforcement > that all SubCA certs with this policy OID comply with the more stringent >

Re: Mozilla Policy and CCADB Disclosure scope

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 would not have been able to effectively curtail and > sunset SHA-1. We would not have been able to deploy and require Certificate >

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 3:41:50 AM UTC-5, Gervase Markham wrote: > On 19/05/17 20:40, Matthew Hardeman wrote: > > Not speaking as to the status quo, but rather in terms of > > updates/changes which might be considered for incorporation into > > policy would be to recognize the benefit of name

Re: Mozilla Policy and CCADB Disclosure scope

Not speaking as to the status quo, but rather in terms of updates/changes which might be considered for incorporation into policy would be to recognize the benefit of name constrained intermediates and allow a reduction in burden to entities holding and utilizing name constrained intermediates,

Re: StartCom issuing bogus certificates

Wow. That is disheartening. Those are issued from their newly cut intermediates issued descending from their G3 root, which I had assumed was the infrastructure that they intend to get audited for inclusion into the various root programs again. It would seem an issuance like that on that

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

On Wednesday, May 31, 2017 at 11:04:53 AM UTC-5, Gervase Markham wrote: > > If you have suggestions on how to improve this definition, let's keep > brevity in mind :-) Perhaps some reference to technologically incorrect syntax (i.e. an incorrectly encoded certificate) being a mis-issuance? How

Re: StartCom issuing bogus certificates

On Wednesday, May 31, 2017 at 12:10:36 PM UTC-5, Yuhong Bao wrote: > The point is that "misissuance" of example.com is harmless as they are > reserved by IANA. Except that having a trusted root CA in the major root programs is a privileged club with a lot of non-obvious rules. One of those

Re: Mozilla Policy and CCADB Disclosure scope

On Wednesday, May 31, 2017 at 10:34:34 AM UTC-5, Gervase Markham wrote: > However, that discussion suggests to me that we should do the following: > > * Given CT, and the need within it to disclose TCSCs, the privacy > argument seems to have been abandoned. So I think it's reasonable to > also

On remedies for CAs behaving badly

Hi all, I thought it prudent in light of the recent response from Symantec regarding the Google Chrome proposal for remediation to raise the question of the possible remedies the community and the root programs have against a CA behaving badly (mis-issuances, etc.) Symantec makes a number of

Re: New undisclosed intermediates

On Wednesday, June 7, 2017 at 6:45:25 PM UTC-5, Jonathan Rudenberg wrote: > Yet another batch of undisclosed intermediates has shown up in CT: > > - > https://crt.sh/?sha256=f01c1aca392882af152e9f01ecccd0afddd8aa35bf895b003198b1e8c752ddb8 > - >

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

On Thursday, June 1, 2017 at 8:03:33 AM UTC-5, Gervase Markham wrote: > > My point is not that we are entirely indifferent to such problems, but > that perhaps the category of "mis-issuance" is the wrong one for such > errors. I guess it depends what we mean by "mis-issuance" - which is the >

Re: New undisclosed intermediates

For these self-signed roots which have a certificate subject and key which match to a different certificate which is in a trusted path (like an intermediate to a trusted root), the concern is that the mere existence of the certificate speaks to a signature produced by a private key which DOES

Re: New undisclosed intermediates

On Friday, June 9, 2017 at 11:52:53 AM UTC-5, Ryan Sleevi wrote: > So that would be an arguement for disclosing both self-signed and > self-issued certificates, and align with the "Disclose what the key does" > mentality. That was essentially the point I was trying to make. Of all the things to

Re: Symantec response to Google proposal

I broadly echo many of the comments and thoughts of Martin Heaps earlier in this thread. Much of Symantec's response is disheartening, especially in the "inaccuracies": (the apparent dichotomy between how they have acted and their statement that they only employ the best people implementing

Re: Symantec response to Google proposal

On Tuesday, June 6, 2017 at 9:03:29 AM UTC-5, Gervase Markham wrote: > I'm slightly surprised to see no engagement here. Perhaps it would be > help to break it down. Symantec's specific requests for modification are > as follows (my interpretation): > > 1) Scope of Distrust > > Google proposal:

Re: New undisclosed intermediates

On Tuesday, June 6, 2017 at 4:14:00 AM UTC-5, Gervase Markham 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 how often > this happens per CA, and impose a

Re: On remedies for CAs behaving badly

On Monday, June 5, 2017 at 11:17:17 AM UTC-5, Ryan Sleevi wrote: > While on paper the idea sounds quite good, it turns out to simply trade > technical complexity for complexity of the non-technical sort. As such, > it's best to focus on meaningful and actionable technical solutions. Ryan, I

Re: CAA Certificate Problem Report

On Tuesday, September 19, 2017 at 10:37:20 AM UTC-5, Gervase Markham wrote: > On 19/09/17 14:58, Nick Lamb wrote: > > An attacker only has to _prefer_ one particular CA for any reason, > > > Yep, fair. > > Gerv Quite true. In the example scenario that I have just posted, such preference

Re: Public trust of VISA's CA

On Tuesday, September 19, 2017 at 10:13:26 AM UTC-5, Gervase Markham wrote: > >From the above, we see that Visa only issues certificates to their own > customers/clients, and not to the public. They believe that this permits > them to keep confidential details of the certificates which they wish

Re: CAA Certificate Problem Report

I concur in full with Nick Lamb's comments and positions on this matter. There is no reasonable short cut to actually doing the DNSSEC thing if we want to usefully intertwine those technologies at all. There IS significant benefit in enforcing complete DNSSEC validation for (all) the domain

Re: PROCERT issues

On Wednesday, September 27, 2017 at 11:56:27 AM UTC-5, Kathleen Wilson wrote: > What action items do you all think PROCERT should complete before they can be > re-included in Mozilla's root store? > What do you think should happen if PROCERT completes those action items > before their

Re: CAA reporting support and tests?

Has there been any serious discussion of the potential benefit of CAA reporting for certificate issuance attempts? I'm aware of what the spec says and the SHOULD language, etc... I'm not a CA and don't represent one. I do, however, think that it's easier to get buy-in for changes to CA

Re: ROCA fingerprints found on crt.sh (was Re: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards)

On Wednesday, October 18, 2017 at 4:15:03 AM UTC-5, Rob Stradling wrote: > The list is at https://misissued.com/batch/28/ > > Many of these are Qualified/EUTL certs rather than anything to do with > the WebPKI. Only about half of them chain to roots that are trusted by NSS. > It's really

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

The position that WoTrus (and apparently QiHoo 360) take(s) here does seem to clarify a matter involving the reinclusion. It sounds like they are insisting that Richard Wang would be part of the plan and would, in fact, retain a position of material control and responsibility in the

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

On Mon, Nov 27, 2017 at 3:07 PM, adisor19--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > After seeing the forced shutdown of StartCom, I see no reason to allow > them back in. Richard Wang is back in his role as CEO and everything is > back to square one except all

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

On Friday, November 24, 2017 at 5:36:20 PM UTC-6, Tom wrote: > For information, WoSign/WoTrus can already sells WoSign-branded EV > certificates accepted by major trusts stores, Mozilla's included. > > The intermediate certificate "WoSign EV SSL Pro CA" ( > https://crt.sh/?id=146206939 ) is

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

On Friday, November 24, 2017 at 6:07:44 AM UTC-6, Gervase Markham wrote: > While I do not want to make this discussion entirely about specific > people, as Mozilla's investigator of the issues at the time I am > satisfied that WoSign's actions at the time were taken with full > knowledge - that

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

Hi, I touched on my thoughts on this matter a bit before. This is really about trust. I think several factors must be weighed here: 1. Is "trust" really required of a CA in a soon-to-be post-mandatory-CT-log world? If some level of trust is required, then: 2. Can we say that the QiHoo 360

Re: On the value of EV

On Friday, December 15, 2017 at 5:39:37 PM UTC-6, Ryan Sleevi wrote: > That is not what is required. There is no special enrollment dance - that > is simply straight up misrepresenting it. Your vision is not aligned with > the reality of it. I've never been to a banking website where there

Beyond EV: Thoughts on trust and actionable trust signals

All, Recent events and a body of historical research have of late been causing questions among a great many respected security researchers and browser UI guys about the benefits of browser UI signal for EV certificates. I'd like to start a discussion tangent to that ongoing dialogue. Regardless

Re: On the value of EV

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 Langley made of revocation checking: > https://www.imperialviolet.org/2012/02/05/crlsets.html > > "So [EV identity is] like a

Re: On the value of EV

That is, indeed, a good question. I've also questioned simultaneously questioning users' reliance on the UI while suggesting that no user looks to the UI. If the user does not see or make decisions on the basis of the UI, it seems leaving it present is no harder a conclusion to arrive at than

Re: On the value of EV

IDN abuses are far more hostile, to my mind, than EV positive indicators. At least within certain locales. Why is IDN even displayed in styled form if the client locale belongs to a jurisdiction or language for which non-roman characters would be abnormal? Additionally, many vehicles provide

Re: On the value of EV

On Monday, December 18, 2017 at 3:54:24 PM UTC-6, Andrew wrote: > On Monday, December 18, 2017 at 3:09:31 PM UTC-6, 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

Re: On the value of EV

On Thursday, December 14, 2017 at 5:50:40 PM UTC-6, Matthew Hardeman wrote: > Route hijacking your way to what would appear as a proper domain validation > is practical for even a modestly resourceful adversary. I suspect that the > only reason more spectacular demonstration of certs issuing

Re: On the value of EV

That attack was by hacking the target's domain registrar account. Others have done that as well, including against a Brazilian bank. The right attacker would not even need that - they could just hijack traffic headed to the IP address of the real DNS server in question.

Re: CA generated keys

On Friday, December 15, 2017 at 3:21:54 PM UTC-6, Ryan Hurst wrote: > Unfortunately, the PKCS#12 format, as supported by UAs and Operating Systems > is not a great candidate for the role of carrying keys anymore. You can see > my blog post on this topic here: http://unmitigatedrisk.com/?p=543

Re: Investigating validations & issuances - The high value IP space BGP Hijacks on 2017-12-12

require responses within a certain time period.) > > -tom > > On 14 December 2017 at 22:16, Matthew Hardeman via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > Has anyone started looking into CA issuances -- or even more importantly > -- CA d

Re: On the value of EV

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, therefore, we should keep telling users they need > tiger-repelling rocks. And oh, by the way, they take away attention from > solutions

Re: On the value of EV

On Friday, December 15, 2017 at 1:50:38 PM UTC-6, Ryan Sleevi wrote: > I'm not sure I made those statements, but would be happy to clarify the > confusion. Indeed, as I tried to call out, there are a subset of users who > are looking at it and relying on it - although it cannot be relied upon - >

Re: On the value of EV

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 checking it (again, user hostile), and > misleading both users and site operators into EV as a phishing mitigation, > when

Re: On the value of EV

On Friday, December 15, 2017 at 3:51:48 PM UTC-6, Ryan Sleevi wrote: > Yes, we can say correlated variables are correlated. > No, we cannot imply or infer from correlated variables that there is a > causal relationship. > There exists a not insignificant school of actuarial thought that there

Re: On the value of EV

On Wednesday, December 13, 2017 at 5:08:05 PM UTC-6, Matt Palmer wrote: > > There is a "curatorship", if you will, engaged by the site author. If > > there are sub-resources loaded in, whether they are EV or not, it is the > > root page author's place to "take responsibility" for the contents of

Re: On the value of EV

On Wednesday, December 13, 2017 at 11:09:44 PM UTC-6, Matt Palmer wrote: > > Before that, though, a quick word from our sponsor, Elephant-Be-Gone Amulets > of America, Inc. No elephants in America, you say? See, they're 100% > effective! Get yours today! Of relevance on this point, I'm quite

Re: [FORGED] Re: CA generated keys

On Wednesday, December 13, 2017 at 5:52:16 PM UTC-6, Peter Gutmann wrote: > >Sitting on my desk are not less than 3 reference designs. At least two of > >them have decent hardware RNG capabilities. > > My code runs on a lot (and I mean a *lot*) of embedded, virtually none of > which has

Re: CA generated keys

In principle, I support Mr. Sleevi's position, practically I lean toward Mr. Thayer's and Mr. Hollebeek's position. Sitting on my desk are not less than 3 reference designs. At least two of them have decent hardware RNG capabilities. What's noteworthy is the garbage software stack, kernel

Re: CA generated keys

> 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

Re: CA generated keys

> As an unrelated but funny aside, I once heard about a expensive, high > assurance device with a embedded bi-stable circuit for producing high quality > hardware random numbers. As part of a rigorous validation and review process > in order to guarantee product quality, the instability was

Re: CA generated keys

On Wednesday, December 13, 2017 at 12:50:38 PM UTC-6, Ryan Sleevi wrote: > 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

Re: On the value of EV

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 other process - that can certainly be verified after the > > fact > > > No. Why's that? This is how investigations begin. > > -

Re: On the value of EV

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 Langley made of revocation checking: > https://www.imperialviolet.org/2012/02/05/crlsets.html > > "So [EV identity is] like a

Re: On the value of EV

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. > > https://en.wikipedia.org/wiki/Same-origin_policy > > This is what is programatically enforced. Anything else either requires new > technology to technically enforce

Re: On the value of EV

That's not clear at all. Someone other than the famous Stripe, Inc. has -- without violating BR rules or requirements -- a proper EV certificate showing (correctly) entity name Stripe, Inc. That this exists suggests that EV is harmful if the target is normal everyday people. Making the abstract

Fwd: On the value of EV

(Reposting as I accidentally replied directly to OP ). Part of this discussion will necessarily have to include who the intended and potential beneficiaries of EV certificate status are: 1. Is it the common web end user? If so, EV either needs to go or be massively changed. 2. Is it for the

Re: On the value of EV

On Mon, Dec 11, 2017 at 1:37 PM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Mon, Dec 11, 2017 at 2:31 PM, Matthew Hardeman via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > >> (Reposting as I accidentally replied directly to OP

Re: On the value of EV

The question that I have is whether the community might consider it in-scope to discuss enhancements (even fixes) to EV to arrive at assurance commensurate to its handling. Matt Hardeman On Mon, Dec 11, 2017 at 2:09 PM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org>

Re: On the value of EV

- If the fundamental certificate does deserve the UI treatment, then > demonstrate why it does. You seem to be in agreement that the present form > of legal identity is insufficient for the presumed use case, so I'm hoping > you can close the gap in my understanding on why something is >

Re: On the value of EV

On Mon, Dec 11, 2017 at 2:53 PM, Ryan Sleevi wrote: > > > It feels like, to some extent, this is a question about whether we should > point out the Emperor has no clothes if we don't have clothes to offer him. > It'd be great if they was wearing some, I agree - the Emperor does

Re: On the value of EV

What I dislike about this particular rationale is that I presupposes we should architect web security such as to avoid enhancements which have value to anyone the least common denominator. Is the average user (actually, the bottom rung of the concentration of values around the average, I suppose)

Re: On the value of EV

While I understand that it may formally be beyond the scope formally to consider this in discussion with EV UI handling, I think some consideration to ecosystem harm is appropriate here. If we eliminate EV UI, we have reduced the scope of WebPKI to domain validated certificates (in any pragmatic

Re: On the value of EV

On Monday, December 11, 2017 at 5:00:14 PM UTC-6, Ryan Sleevi wrote: > > That Kentucky registration for Stripe, Inc. -- Is it completely fraudulent > > as to registered agent, business address, etc? If it's not, then the > > certificate and underlying entity serve as an archived investigative

Re: On the value of EV

On Monday, December 11, 2017 at 5:37:34 PM UTC-6, Ryan Sleevi wrote: > Yes. > > If something is not valuable for billions of users, if it is not > trustworthy for billions of users, it should not occupy the cognitive or > visual model billions of users rely on. > Perish the thought that a UI

Re: question about DNS CAA and S/MIME certificates

For that matter, can whoever is in charge of gmail.com speak to their intent as to CAA for S/MIME? I've certainly held certificates which include my personal gmail address before. At no point did I need or seek Google's blessing to do so. I can not imagine that was an uncommon case. (At least,

Re: question about DNS CAA and S/MIME certificates

Agreed. My point was to query the position of the administration of a large generic email service as to their understanding of the implications of CAA on their domains. Certificates have different types of SANs for good cause: the nuances of the name space differ. For example, SAN rfc822Names

  1   2   3   >