[Uri-review] Re: [saag] Re: Fwd: [IANA #1449893 ] Registration of URI scheme 'cttps'

--===============6453815924715492492==
Content-Type: multipart/alternative; boundary="00000000000089869906519f91d6"

--00000000000089869906519f91d6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Paul,

If you read section 7.1 of RFC 7595, you will see that the provisional
registrations are provided on a first come, first served basis.  This
serves the primary goal of the registry, which is to avoid collision among
different uses of what might appear to be the same URI scheme.  The
guidelines in section 4 do have requirements, but only at the SHOULD level
and they are intended to be guidelines to the registrant.  The process for
updated a registration to permanent or making a new permanent registration
directly is the one in which the invited expert's approval is required.

regards,

Ted Hardie

On Tue, May 12, 2026 at 2:41=E2=80=AFPM Paul Wouters <paul.wouters=3D
[email protected]> wrote:

>
> On Tue, May 12, 2026 at 7:06=E2=80=AFAM Salz, Rich <rsalz=3D
> [email protected]> wrote:
>
>> It=E2=80=99s a naive protocol and unlikely to get any uptake. An adversa=
ry
>> sitting along the network path can modify, or read, the initial messages
>> and completely decrypt or modify the content. Thanks for posting!
>>
>
> I agree. It is severely underspecified. Even the acronym "cttps" is
> expanded to both  "Crypto Transfer Protocol Secure" and "Ciphered Text
> Transfer Protocol over SSL/Stream".
>
> The request does not comply with RFC 7595 Section 3.1 which states:
>
>     New schemes ought to have utility to the Internet community beyond
> that available with already registered schemes.
>
> As it provides no security against active attacks, it provides nothing
> that https:// doesn't already supply.
>
> The request does not comply with RFC 7595 Section 3.3 which states:
>
>    a scheme definition itself MUST be clear as to how it is expected to
>    function.  Schemes that are not intended to be used as locators
>    SHOULD describe how the resource identified can be determined or
>    accessed by software that obtains a URI of that scheme.
>
> I believe the specification is completely unclear and unimplementable.
>
> The requestion does not comply with RFC 7595 Section 3.4 which states:
>
>    As part of the definition of how a URI identifies a resource, a
>    scheme definition SHOULD define the applicable set of operations that
>    can be performed on a resource using the URI as its identifier.
>
> This is completely missing from the request.
>
> Finally, RFC 7595 Section 3.7, "Clear Security and Privacy Considerations=
"
> is clearly missing in its entirely,
> and the scheme seems to be completely insecure against active attackers.
>
>
> This provisional registration should be rejected by the Designated Expert=
s.
>
> Paul
> _______________________________________________
> Uri-review mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

--00000000000089869906519f91d6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">Hi =
Paul,</div><div class=3D"gmail_default" style=3D"font-size:small"><br></div=
><div class=3D"gmail_default" style=3D"font-size:small">If you read section=
 7.1 of RFC 7595, you will see that the provisional registrations are provi=
ded on a first come, first served basis.=C2=A0 This serves the primary goal=
 of the registry, which is to avoid collision among different uses of what =
might appear to be the same URI scheme.=C2=A0 The guidelines in section 4 d=
o have requirements, but only at the SHOULD level and they are intended to =
be guidelines to the registrant.=C2=A0 The process for updated a registrati=
on to permanent or making a new permanent registration directly is the one =
in which the invited expert&#39;s approval is required.</div><div class=3D"=
gmail_default" style=3D"font-size:small"><br></div><div class=3D"gmail_defa=
ult" style=3D"font-size:small">regards,</div><div class=3D"gmail_default" s=
tyle=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"fo=
nt-size:small">Ted Hardie</div></div><br><div class=3D"gmail_quote gmail_qu=
ote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 12, 2026 a=
t 2:41=E2=80=AFPM Paul Wouters &lt;paul.wouters=3D<a href=3D"mailto:40aiven=
[email protected]">[email protected]</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"l=
tr"><br></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Tue, May 12, 2026 at 7:06=E2=80=AFAM Salz, Rich &lt;rsalz=3D<a href=
=3D"mailto:[email protected]" target=3D"_blank">40akamai.com@dmar=
c.ietf.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">



<div>
<div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo=
nt-size:12pt;color:rgb(0,0,0)">
It=E2=80=99s a naive protocol and unlikely to get any uptake. An adversary =
sitting along the network path can modify, or read, the initial messages an=
d completely decrypt or modify the content. Thanks for posting!</div></div>=
</blockquote><div><br></div><div>I agree. It is severely underspecified. Ev=
en the acronym &quot;cttps&quot; is expanded to both=C2=A0 &quot;Crypto Tra=
nsfer Protocol Secure&quot; and &quot;Ciphered Text Transfer Protocol over =
SSL/Stream&quot;.=C2=A0</div><div><br></div><div>The request does not compl=
y with RFC 7595 Section 3.1 which states:</div><div><br></div><div>=C2=A0 =
=C2=A0 New schemes ought to have utility to the Internet community beyond t=
hat available with already registered schemes.</div><div><br></div>As it pr=
ovides no security against active attacks, it provides nothing that https:/=
/ doesn&#39;t already supply.</div><div class=3D"gmail_quote"><br></div><di=
v class=3D"gmail_quote">The request does not comply with RFC 7595 Section 3=
.3 which states:</div><div class=3D"gmail_quote"><br></div><div class=3D"gm=
ail_quote">=C2=A0 =C2=A0a scheme definition itself MUST be clear as to how =
it is expected to<br>=C2=A0 =C2=A0function.=C2=A0 Schemes that are not inte=
nded to be used as locators<br>=C2=A0 =C2=A0SHOULD describe how the resourc=
e identified can be determined or<br>=C2=A0 =C2=A0accessed by software that=
 obtains a URI of that scheme.</div><div class=3D"gmail_quote"><br></div><d=
iv class=3D"gmail_quote">I believe the specification is completely unclear =
and unimplementable.</div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">The requestion does not comply with RFC 7595 Section 3.4 w=
hich states:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_=
quote">=C2=A0 =C2=A0As part of the definition of how a URI identifies a res=
ource, a<br>=C2=A0 =C2=A0scheme definition SHOULD define the applicable set=
 of operations that<br>=C2=A0 =C2=A0can be performed on a resource using th=
e URI as its identifier. </div><div class=3D"gmail_quote"><br></div><div cl=
ass=3D"gmail_quote">This is completely missing from the request.</div><div =
class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Finally, RFC 759=
5 Section=C2=A03.7, &quot;Clear Security and Privacy Considerations&quot; i=
s clearly missing in its entirely,</div><div class=3D"gmail_quote">and the =
scheme seems to be completely insecure against active attackers.</div><div =
class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><br></div><div c=
lass=3D"gmail_quote">This provisional registration should be rejected by th=
e Designated Experts.</div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">Paul</div></div>
_______________________________________________<br>
Uri-review mailing list -- <a href=3D"mailto:[email protected]" target=3D=
"_blank">[email protected]</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]=
" target=3D"_blank">[email protected]</a><br>
</blockquote></div>

--00000000000089869906519f91d6--


--===============6453815924715492492==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVXJpLXJldmll
dyBtYWlsaW5nIGxpc3QgLS0gdXJpLXJldmlld0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5k
IGFuIGVtYWlsIHRvIHVyaS1yZXZpZXctbGVhdmVAaWV0Zi5vcmcK

--===============6453815924715492492==--