Opened 14 years ago

#98 new editorial

Editorial suggestions from Alfred

Reported by: pasi.eronen@… Owned by:
Priority: minor Milestone:
Component: draft-ietf-tls-rfc4366-bis Version: 02
Severity: Keywords:
Cc:

Description

Alfred Hoenes, 2008-03-05

Hello,
after studying the Internet-Draft authored/edited by you,
                draft-ietf-tls-rfc4366-bis-02,
I'd like to submit a few comments.

(2)  General:  STD 66 terminology

I suggest to reconsider the use of "URI" vs. "URL" throughout
this draft, for conformance with Section 1.1.3 of RFC 3986.
In particular, the use of "URL scheme" should be avoided in
favor of "URI scheme".

Also, section 4 of STD 66 should be taken into account.

I'll give some detailed change proposals below to exemplify that.

(3)  Section 5

(3b)  clarification of "URL"

To clarify the intended restrictions (as indicated above), I suggest
to amend the first paragraph below the syntax as follows:

   Here "url_and_hash_list" contains a sequence of URLs and optional
   hashes.
---
   Here "url_and_hash_list" contains a sequence of URLs and optional
   hashes.  Each "url" MUST be an absolute URI reference according to
   [RFC3986] that can be immediately used to fetch the certificate(s).

This change is intended to explicitely exclude relative URI references
and the use of URI schemes that do not lead to "immediate access",
e.g., the 'mailto', 'cid', 'go', or 'tel' URI schemes.

(3c)  ordering of URLs

The paragraph starting,

   Note that when a list of URLs for X.509 certificates is used, the
   ordering of URLs is the same ...

should preferably be more explicit and precisely state the order
required, to improve the readability and not urging the reader
to refer to other documents for this information.
(If deemed necessary, a 'salvatory clause' could be added to the end
of Section 1, for instance:

|  For the ease of the reader, some normative text from [RFCTLS] is
|  restated below.  Any possible deviation from [RFCTLS] has not been
|  intended, and [RFCTLS] shall remain the normative document in such
|  cases.

(3d)  notation of URI schemes

In the second-to-next paragraph in Section 5, I suggest to harmonize
the spelling of, and emphasis (quoting) applied to, URI schemes;
for instance:
                                                       vvvvvvvvvv
|  Servers that support this extension MUST support the http: URL scheme
   for certificate URLs, and MAY support other schemes. Use of other
|  schemes than "http", "https", or "ftp" may create unexpected
   problems.
---             ^    ^  ^     ^     ^   ^
|  Servers that support this extension MUST support the 'http' URI
                                                        ^    ^   ^
   scheme for certificate URLs, and MAY support other schemes.  Use of
|  other schemes than 'http', 'https', or 'ftp' may create unexpected
                      ^    ^  ^     ^     ^   ^
   problems.


(4)  Section 8

Near the end of section 8, two Notes specify the preconditions for
using the Certificate Status Request extension, but unfortunately,
the conditions apparently are incomplete.
I propose to change:

   Note that a server MAY also choose not to send a "CertificateStatus"
|  message, even if it receives a "status_request" extension in the
|  client hello message.

|  Note in addition that servers MUST NOT send the "CertificateStatus"
|  message unless it received a "status_request" extension in the client
|  hello message.
---
   Note that a server MAY also choose not to send a "CertificateStatus"
|  message, even if has received a "status_request" extension in the
|  client hello message and has sent a "status_request" extension in the
|  server hello message.

|  Note in addition that a server MUST NOT send the "CertificateStatus"
   message unless it received a "status_request" extension in the client
|  hello message and sent a "status_request" extension in the server
|  hello message.




(6)  Section 11.3 -- "URI" related clarifications

(6a)  5th paragraph

   The second major issue is that support for client_certificate_url
|  involves the server's acting as a client in another URL protocol.
   The server therefore becomes subject to many of the same security
|  concerns that clients of the URL scheme are subject to, with the
   added concern that the client can attempt to prompt the server to
   connect to some (possibly weird-looking) URL.
---
   The second major issue is that support for client_certificate_url
|  involves the server's acting as a client in another URI scheme
   vvvvvvvvvv                                            ^^^^^^^^
|  dependent protocol.  The server therefore becomes subject to many of
|  the same security concerns that clients of the URI scheme are subject
                                                    ^
   to, with the added concern that the client can attempt to prompt the
   server to connect to some (possibly weird-looking) URL.

(6b)  9th paragraph

-    s/URI protocols/URI schemes/

-    s/set of protocols/set of schemes/

Change History (0)

Note: See TracTickets for help on using tickets.