Subject: [Uri-review] URI Scheme "ves:"

From: Jim Zubov <[email-masked]>
Date: Fri, 17 Dec 2021 23:46:42 -0500

Please consider the following provisional URI scheme for registration,
any comments are welcome:

    Scheme name:
      ves

    Status:
      Provisional

    Applications/protocols that use this scheme name:
      A unique identifier of an end-to-end encrypted object stored
      in VES Repository (https://ves.host/docs/repo).
      The passphrases that unlock the VES keychains are managed
      locally on the user devices by VESvault (https://vesvault.com),
      applications can use open source libVES or an equivalent tool
      to access VES Repository.

    Contact:
      Jim Zubov<[email-masked]>  VESvault Corp

    Change controller:
      Jim Zubov<[email-masked]>  VESvault Corp

    References:
      https://ves.host/assets/download/VES%20URI%20Scheme.pdf
      https://ves.host/docs/repo
      https://vesvault.com

---

From: Tim Bray <[email-masked]>
Date: Sat, 18 Dec 2021 10:15:42 -0800

- Should you also register content-types for these things?
- Assuming you do, one wonders why you couldn't use regular old https URLs,
if these things are located on a DNS-addressable server.

On Fri, Dec 17, 2021 at 11:06 PM Jim Zubov <[email-masked]> wrote:

>      Jim Zubov <[email-masked]> <[email-masked]> VESvault Corp
>
>    Change controller:
>      Jim Zubov <[email-masked]> <[email-masked]> VESvault Corp
>
>    References:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: Jim Zubov <[email-masked]>
Date: Sat, 18 Dec 2021 14:15:21 -0500

Thanks for the comments -

> - Should you also register content-types for these things?

If fact there's already one registered - application/vnd.ves.encrypted

This is not a type VES URI is pointing to, but rather encrypted content 
stored by external means, the item encryption key for this content is 
identified by a VaultItem VES URI. There are no specific content types 
for objects identified by VES URIs, because those are handled by libVES 
or an equivalent tool, and are communicated in an e2ee form with the low 
level VES REST API as JSON objects.

> - Assuming you do, one wonders why you couldn't use regular old https 
> URLs, if these things are located on a DNS-addressable server.
>
The API server is DNS addressable, it's api.ves.host, however I see a 
few reasons to not use http uri -

- There are forms of VES URI that use an implicit app domain, which 
comes from the current context of libVES, or other VES API tool. An http 
uri wouldn't have the means to use the current context;

- I purposely specified some permitted violations of URI syntax that VES 
URI should tolerate, because it simplifies interactions between the 
client software and libVES, without causing any ambiguity;

- The ability to decrypt the object identified by VES URI, and even the 
ability to access the encrypted content and metadata, depends on the 
current context of libVES. Again, a stateless http uri wouldn't be good 
for it.

>           Jim Zubov<[email-masked]>  <mailto:[email-masked]>  VESvault Corp
>
>         Change controller:
>           Jim Zubov<[email-masked]>  <mailto:[email-masked]>  VESvault Corp
>
>         References:

---

From: Julian Reschke <[email-masked]>
Date: Sat, 18 Dec 2021 21:53:27 +0100

Am 18.12.2021 um 20:15 schrieb Jim Zubov:
> ...

"I purposely specified some permitted violations of URI syntax" -
seriously? That makes it a non-starter for URI registration, IMHO.

Best regards, Julian

---

From: Jim Zubov <[email-masked]>
Date: Sat, 18 Dec 2021 16:10:37 -0500

On December 18, 2021 3:53:27 PM EST, Julian Reschke <[email-masked]> wrote:

Best regards, Julian

I specified the violations, specifically stripped url encoding, that the software SHOULD understand, and libVES is fact DOES understand. The uri parts is still recommended to be properly url encoded to comply with the standards.

Uri-review mailing list
[email-masked]

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Dec 2021 13:26:19 +0100

Am 18.12.2021 um 22:10 schrieb Jim Zubov:
> I specified the violations, specifically stripped url encoding, that the
> software SHOULD understand, and libVES is fact DOES understand. The uri
> parts is still recommended to be properly url encoded to comply with the
> standards.
> ...

I believe this is an incredibly bad decision, because it means that
consumers of the URIs can't simply use conforming URI parsers.

Best regards, Julian

---

From: Michael Wojcik <[email-masked]>
Date: Mon, 20 Dec 2021 14:24:24 +0000

> From: Uri-review <[email-masked]> On Behalf Of Julian Reschke
> Sent: Monday, 20 December, 2021 05:26
> 

Historically, this sort of thing has also led to security vulnerabilities, due to mismatches in the tolerances of filters and end servers. Non-canonical UTF-8 sequences are one example.

The Postel Interoperability Principle was useful in the early days of internets (and then of *the* Internet) to get things off the ground. These days it's a liability. Be strict in what you accept.

-- 
Michael Wojcik

---

From: Jim Zubov <[email-masked]>
Date: Mon, 20 Dec 2021 12:20:27 -0500

Julian & Michael -
I must agree. It will be cleaner to keep the scheme specifications strictly compliant, while individual libraries and clients may allow some leeway that's not documented in the scheme, covered by their own security assessment.
I revised the specs pdf (same link as before) to reflect this.