Re: [Uri-review] Requesting review for 'dvx' provisional registration draft

["C. Bastian | ORGAPLAN" <[e-mail]>]

Hello Ted,

thanks again. Your thoughts are very appreciated and helpful.
Here's our third version of the draft:

Regarding the obligations for "key=value" pairs your idea helped us to
shrink our specification and make more use of existing documentation.
It now says:
    * value MUST consist of unreserved and pct-encoded characters
defined in RFC3986 (see the RFC3986 Appendix A. for the collected
ABNF)
    * The unreserved characters MAY be pct-encoded, but SHOULD NOT be encoded
    * The reserved characters MUST be encoded using pct-encoding
    * value MAY be empty, but it's not recommended

And the updated security considerations:
    A full security analysis and considerations are not yet available
since the application which this scheme is part of is still under
development. At the current state the scheme inherits the general
security considerations of RFC 3986 Section 7.. We highly recommend:
    Sensitive data SHOULD NOT be used in key=value pairs in forms
accessible to observers
    Implementations of this scheme SHOULD NOT trust a dvx-URI from an
untrusted source
    Security considerations will be updated as soon as the threat
model becomes clearer.

Published as the versions before at
https://api.orgaplan.org/articles/uri-dvx-scheme-specification.html

Looking forward on your feedback, Clemens

Mit freundlichen Gruessen | Best regards


Clemens Bastian | Technical Development & Integrations

ORGAPLAN business solutions GmbH


[e-mail]
T (Global) +49 | 511 | 999 71 0 73


Office UK: HG4 Ripon (Harrogate, Northern Yorkshire)

Office DE: 30926 Seelze / Velber (Hannover)

Office DE: 06618 Naumburg (Saale)


Firmensitz (nur: Verwaltung)

bisher: Hanomaghof 2 | 30449 Hannover

seit 15. Juni 2021: Gustav-Bratke-Str. 71 | DE - 30629 Hannover

www.orgaplan.org


ORGAPLAN business solutions entwickelt funktionsstarke Software für
die kaufmännische und betriebliche Organisation und Information.



Seit über 30 Jahren vertrauen namhafte Unternehmen im technischen
Großhandel, der Fertigungs- und Lebensmittelindustrie sowie dem
Sondermaschinenbau unseren Softwarelösungen.




Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss...



Am Fr., 2. Juli 2021 um 11:30 Uhr schrieb Ted Hardie <[e-mail]>:
>
> Hi Bastian,
>
> Thanks for your message.  I've read the updated document, and I have a few comments, but I believe I understand more fully your intent than with the initial version.  Thanks for the update.
>
> In the text on data within values, you say:
>
> The characters allowed in a value are either reserved or unreserved (or a percent character as part of a percent-encoding, see RFC3986 "Uniform Resource Identifier (URI): Generic Syntax" Section 2.1). Reserved characters are those characters that sometimes have special meaning, while unreserved characters have no such meaning. Using percent-encoding, characters which otherwise would not be allowed are represented using allowed characters
>
> If I understand you correctly, your intent could also be expressed by saying that "value" permits the unreserved and pct-encoded  productions from RFC 3986 (see the Appendix for the collected ABNF).  If you also wanted to permit the sub-delims, ":" , and "@", you could simply reuse the pchar production, which seems fairly close to your intent.  Since those are part of the base spec, either approach would be well understood by implementers.
>
> On the question of security considerations, BCP35 requires either a security consideration section or a statement of why one cannot be made available:
>
>       The scheme definition SHOULD include clear security considerations
>       (Section 3.7) or explain why a full security analysis is not
>       available (e.g., in a third-party scheme registration).
>
> I'd suggest updating the template to note that the system of which this is a part is a work in progress and that a full security consideration is thus not yet available, but that the scheme inherits the general security considerations of RFC 3986 and that sensitive data SHOULD NOT be used in key value pairs in forms accessible to observers.  That would seem to cover the threats you're already aware of, and you can update the security considerations as the threat model becomes clearer.
>
> best regards,
>
> Ted Hardie
>
> On Thu, Jul 1, 2021 at 5:44 PM C. Bastian | ORGAPLAN <[e-mail]> wrote:
>>
>> Hello Ted,
>>
>> first of all: Let me thank you for the precious feedback and all the
>> effort going through my draft.
>>
>> You're absolutely right in terms of the extensible <command> section.
>> To be honest, and as the title indicates, this is a draft and changes
>> can still be made. The scheme design is WiP and your feedback is
>> appreciated. Now there are some more obligations and recommendations
>> regarding the <command>:
>>     * MUST start with a letter (a-z)
>>     * MUST end with a letter (a-z) or a number (0-9)
>>     * MUST have a minimum length of 3 characters and a maximum length
>> of 200 characters
>>     * SHOULD HAVE at least 3 alphanumeric characters between two
>> special characters (`.`,`+`,`-`)
>>
>>
>> The section about encoding of the key=value pairs has been updated as
>> well to make it clearer (hopefully):
>>     All `key=value` pairs MUST use the UTF-8
>> ([RFC3629](https://datatracker.ietf.org/doc/html/rfc3629)) character
>> set. `key` and `value` MUST be separated by an equal sign (`=`).
>>
>>     Naming of `key` has following obligations:
>>     * MUST start with a letter (a-z)
>>     * MUST have a minimum length of 1 character and a maximum length
>> of 200 characters
>>     * MUST consist of alphanumeric characters (a-zA-Z0-9) (lowercase
>> alphabet a-z, uppercase alphabet A-Z, numbers 0-9)
>>     * SHOULD be written in _camelCase_ annotation
>>
>>     Data within `value` has following obligations:
>>     The characters allowed in a `value` are either reserved or
>> unreserved (or a percent character as part of a percent-encoding
>>     [RFC3986 "Uniform Resource Identifier (URI): Generic Syntax"
>> Section 2.1](https://datatracker.ietf.org/doc/html/rfc3986#section-2.1)).
>>     Reserved characters are those characters that sometimes have
>> special meaning, while unreserved characters have no such meaning.
>>     Using percent-encoding, characters which otherwise would not be
>> allowed are represented using allowed characters.
>>
>>     The unreserved characters can be encoded, but SHOULD NOT be
>> encoded. The reserved characters MUST be encoded using
>> percent-encoding.
>>     List of reserved characters: `!*'();:@&=+$,/?%#[] ` (last
>> character is a whitespace).
>>
>>
>> We also updated the interoperability considerations as follows (thanks
>> for the hint):
>>     Currently the only one known context of use is within the software
>> application stack and it's ecosystem provided by ORGAPLAN business
>> solutions. Uses outside of context should be handled with care.
>>
>> Last but not least we updated the security considerations. Since this
>> is a provisional registration and the uri is still WiP we do not have
>> a well qualified security consideration yet. Is this required for a
>> provisional registration?
>>
>> Thanks again for your time Ted, the updated specification is available
>> at https://api.orgaplan.org/articles/uri-dvx-scheme-specification.html
>>
>> Looking forward hearing your thoughts and possible improvements!
>>
>>
>>
>> Am Do., 1. Juli 2021 um 14:24 Uhr schrieb Ted Hardie <[e-mail]>:
>> >
>> > Hi Clemens,
>> >
>> > Thanks for your note.  There appears to be no collision with an existing registered scheme, so that's good news.  In going through the syntax, I did have some questions, if you don't mind.
>> >
>> > My reading is that there are two current commands, open and close, but that you intend for the syntax to be extensible.  The permitted characters for new commands are a-z0-9.+-, and there is no restriction on their ordering.  That would mean 99open, +-7a, even + as a bare operator would be valid; is that your intent, or did you also want to have minimum lengths and require certain patterns?
>> >
>> > For "the interoperability considerations", you might simply mention that there is currently only one known context of use (the ORGAPLAN context, listed below), and that uses of this outside that context may or may not conform.
>> >
>> > For security considerations, I could not quite parse what you meant:
>> >
>> > For security reasons it's prohibited to include sensitive or private information in the uri. This applies in particular to the key=value pairs. The restrictions on a requested resource or command need to be checked by the application which evaluates the uri
>> >
>> > For example, are you indicating that the URI might be carried in a plain text protocol, and thus be observable to an attacker with access to the path?  If that's the threat model, it would appear  the application that evaluates the URI (on receipt), might be acting too late to prevent observation.   In general you might want to reference rFC 3552 for text on how security considerations text is constructed.
>> >
>> > Thanks again for sending this note,
>> >
>> > regards,
>> >
>> > Ted Hardie
>> >
>> >
>> > Your document says "The encoding of the key=value pairs follow the rules defined in RFC3986 "Uniform Resource Identifier (URI): Generic Syntax" Section 2" .  It's not entirely clear to me which part of that section you wish to draw the reader's attention to.  Is it possible you meant section 3.4, which describes path elements and mentions key value pairs?
>> >
>> >
>> >
>> >
>> > On Thu, Jul 1, 2021 at 5:54 AM C. Bastian | ORGAPLAN <[e-mail]> wrote:
>> >>
>> >> Hello! I hope you can provide me some feedback on this draft for a
>> >> provisional registration of the scheme 'dvx'.
>> >> Here's my current draft, any feedback and hints are appreciated. Best
>> >> greetings Clemens
>> >>
>> >> Scheme name:
>> >>       dvx
>> >>
>> >> Status:
>> >>      Provisional
>> >>
>> >> Applications/protocols that use this scheme name:
>> >>      The ERP software solution named "DVX" by ORGAPLAN business
>> >> solutions (www.orgaplan.org)
>> >>
>> >> Contact:
>> >>      Registration applicant: Clemens Bastian <[e-mail]>
>> >>      Scheme creator: ORGAPLAN business solutions GmbH <[e-mail]>
>> >>
>> >> Change controller:
>> >>      Someone who is verified to represent ORGAPLAN business solutions
>> >> GmbH (see 'Contact')
>> >>
>> >> References:
>> >>      Specification:
>> >> https://api.orgaplan.org/articles/uri-dvx-scheme-specification.html
>> >>
>> >> _______________________________________________
>> >> Uri-review mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/uri-review