Jump to content

Recommended Posts

53 minutes ago, Sukrim said:

So AGAIN no way to externally verify that they actually did do this intentionally and this is not just someone who stole their TLS cert...

Someone with enough access to steal their TLS cert would be able to put a ripple.txt in place, although it would increase the risk of detection.

That aside, if your concern is “external verification” then I don’t think that publishing a file helps.

With that said, I’d like to see a ripple.txt up for all validators.

Share this post


Link to post
Share on other sites

It is the current standard for a https://en.wikipedia.org/wiki/Domain-validated_certificate at least.

Edit:

Requiring to purchase a domain to be a verified validator is another issue I have with this in general, but that's a different story. After all, there is support for adding a domain to an account on the ledger and for a while it was recommended by Ripple to use that field as intended (to point to a domain that has a ripple.txt file). This recommendation was changed to the current, much less transparent process (which however is maybe simpler for non-technical people - but then again: They should not operate trusted validators anyways).

Edited by Sukrim

Share this post


Link to post
Share on other sites
20 minutes ago, Sukrim said:

It is the current standard for a https://en.wikipedia.org/wiki/Domain-validated_certificate at least.

Our process does implement domain validation, but I understand that that isn’t something a third party, outside of Ripple can verify.

Ultimately, the question boils down to “should Ripple’s list of validators be run in such a way as to allow a third party to verify, independently of Ripple, the “proof” that a validators’ association with a given domain is real?

It would be nice, but we need to be practical too. What if I told you that pushing a ripple.txt file is a major sticking point for a lot of operators?

It’s not an easy problem to solve and it is something we continue to think about and we are, always, open to ideas.

As other validator registries become available and publish their own list, multiple rule sets about what it takes to verify can exist. For example, one might list only business-operated validators and require a check with D&B. Another may have different criteria. Certainly an “open and externally verifiable” registry would make a lot of sense.

Share this post


Link to post
Share on other sites
27 minutes ago, nikb said:

It’s not an easy problem to solve and it is something we continue to think about and we are, always, open to ideas.

As other validator registries become available and publish their own list, multiple rule sets about what it takes to verify can exist. For example, one might list only business-operated validators and require a check with D&B. Another may have different criteria. Certainly an “open and externally verifiable” registry would make a lot of sense.

I already wrote about why I think validator registries are a bad place to get a UNL from (they re-centralize and take away agency), but they might be useful to get an overview of validators out there to choose from. I have yet to see any incentive or even initiatives to make it easier to run such a registry though. In the end one needs to monitor the validations on the network live, probably also archiving them. This is neither easy nor cheap and nearly not documented.

While building the one at Ripple Labs, please also make sure to include how one can get thrown off your UNL and which proof is required to show that you have a bad player in your midst. Ideally including an automated cryptographic one too so there is no need to trust or even know the reporter.

Share this post


Link to post
Share on other sites
42 minutes ago, nikb said:

What if I told you that pushing a ripple.txt file is a major sticking point for a lot of operators?

What do you mean by "major sticking point for a lot of operators"?

Share this post


Link to post
Share on other sites
2 minutes ago, T8493 said:

What do you mean by "major sticking point for a lot of operators"?

He means that they're resistant to including one. This is an interestong topic. 

Share this post


Link to post
Share on other sites
3 minutes ago, T8493 said:

What do you mean by "major sticking point for a lot of operators"?

They don't want to file an internal ticket and explain to their webmasters why they should publish a text file directly at their domain root. Most likely the ones running a validator in a largish company do NOT have access to the web server. I see this as a positive thing, "companies" are not the ones actually operating a node after all (I could argue that I run a node on behalf of my university, on behalf of myself, on behalf of the company I work at, on behalf of the NGO I'm a member of... so all in all I probably could come up with half a dozen or so completely unrelated companies and organizations where I would manage their rippled deployment and also have access to validation keys).

Share this post


Link to post
Share on other sites

Ok, if putting a ripple.txt on a web server is such a big issue, why don't Ripple require that when Ripple account claims it is associated with some domain, that:

- this domain (text "domain.com") is signed with some private key and

- that Ripple account also contains (e.g. domain validated) certificate for this domain

Basically, each Ripple account would have three fields:

- domain name (example.com),

- signature 

- certificate (signed by some reasonable CA)

Site operators could use the same private keys/certificates that they already use for TLS.

 

 

 

Share this post


Link to post
Share on other sites

Signing the public key of the account with the private key of the TLS certificate used on the domain and publishing that signature definitely would be useful. Ideally this (or at least a pointer to the actual data) would be available at some predefined location.

Storing certs or signatures on the ledger seems a bit overkill, on the other hand it could have other uses besides verifying validators, also some fields for encryption keys etc. are also already in place.

Share this post


Link to post
Share on other sites

I vaguely call @nikb saying we are free to write a best practice guideline (not saying it would be adopted).

As a exercise what would you like to see @T8493@Sukrim and others? Some basic guidelines- it has to be reasonable that a business/ operator would adopt, adhere to industry best practices, be certifiable by others, etc.

One thing I would like would be perhaps some sort of multi sign key signature (could be used in the signed domain @T8493 talks about). The reason is it limits the risk while keeping authorship verifiable (and can help recovery of the eventual tech screw ups). The other party in the multi signature could be Ripple itself (logical extension of the UNL), or perhaps the oft talked about resurrected IRBA successor- giving some oversights, verification and another sustainable income feed.  

Share this post


Link to post
Share on other sites
2 hours ago, Sukrim said:

They don't want to file an internal ticket and explain to their webmasters why they should publish a text file directly at their domain root. Most likely the ones running a validator in a largish company do NOT have access to the web server. I see this as a positive thing, "companies" are not the ones actually operating a node after all (I could argue that I run a node on behalf of my university, on behalf of myself, on behalf of the company I work at, on behalf of the NGO I'm a member of... so all in all I probably could come up with half a dozen or so completely unrelated companies and organizations where I would manage their rippled deployment and also have access to validation keys).

Spot on. It surprised me as well... if an org makes a commitment to run a validator, I’d imagine that adding a file a thing the root of their website would be a non-issue.

But in practice it’s turned out to be an issue. I know that’s a bummer, but it is what it is. We have to work with it.

There are some great ideas in this thread on how to enable better transparency.

Share this post


Link to post
Share on other sites
2 hours ago, Mercury said:

As a exercise what would you like to see @T8493@Sukrim and others? Some basic guidelines- it has to be reasonable that a business/ operator would adopt, adhere to industry best practices, be certifiable by others, etc.

The IRBA also had standards for its members and they were not met by them as well, with no real consequences. See the stuff at http://www.xrpga.org - Bitstamp still has no EV cert, not even Ripple Labs themselves have one!

A ripple.txt file is already very reasonable, the alternative would have been DNS TXT entries. Associating a validator with a company is anyways a wrong action imho, large companies have so many subcontractors etc. that it doesn't really make sense to attribute a validator to one anyways (just for the brand value I guess) and smaller ones are not well known and thus mistrusted.

Share this post


Link to post
Share on other sites

Wouldn't having a validator associated with a company, regardless if that company operates the validator directly or via a subsidiary/ contract, still place ultimate responsibility with that company?

Share this post


Link to post
Share on other sites

I would like to think having some sort of verification third party like the former IRBA directly involved would give both it and it's partners more credibility, and allow the third party a bigger constructive role

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...