Re: [mile] Working group last call for ROLIE

["Banghart, Stephen A. (Fed)" <[e-mail]>]

Panos,

Thanks for the review! Comments inline.

Your suggestions and other small fixes are being added in our Github repo for the document, if you or anyone else would like to follow along or provide feedback here is the URL: https://github.com/CISecurity/ROLIE

Thanks,
Stephen Banghart

From: mile [mailto:[e-mail]] On Behalf Of Panos Kampanakis (pkampana)
Sent: Wednesday, April 05, 2017 10:31 AM
To: Nancy Cam-Winget (ncamwing) <[e-mail]>; [e-mail]
Subject: Re: [mile] Working group last call for ROLIE

Hello,

I did a final pass. The doc looks good. I think it is almost ready for publication.

I had some last minor suggestions, nits below:

·         s/MUST publish an Category Document that/MUST publish a Category Document that
Changed.


·         s/URL of the appropriate RID endpoint /URL of the appropriate ROLIE endpoint
I believe that this line is actually referring to a RID endpoint correctly. If a client sends a request to “/” they may be redirected to a RID endpoint.


·         Section 7.4 mentions “In order to provide a global reference for these properties, this document establishes an IANA registry in Section 7.4<https://tools.ietf.org/html/draft-ietf-mile-rolie-06#section-7.4>”. So you are referring to the section in the section itself.
Fixed.

·         We should have caught this earlier, but there is something that came up in the ACE group multiple times: When using fixed URIs we should put them under the .well-known directory according to https://tools.ietf.org/html/rfc5785. So for every https://{host:port}/rollie/<https://%7bhost:port%7d/rollie/>... it should be https://{host:port}/.well-known/rolie/<https://%7bhost:port%7d/.well-known/rolie/>...
Agreed, we’ve made this change and updated the examples to reflect it. We’ll also add an IANA registration for the .well-known location.

·         “for use in a ROLIE Any element not specified here inherits its definition and requirements” does not read well. I think it should be two sentences.
Fixed.

·         “An atom:feed may include additional atom:category elements using a” should be a “MAY” instead of  “may” right?]
Fixed

·         In 6.2.3, the paragraph “or example, the nominal element <rolie:format ns="urn:ietf:params:xml:ns:iodef-2.0"…” should be moved one paragraph above with the paragraph that talks about schema-location
I changed the example to better fit at the end of the section, does that resolve your concern?

·         About “The server MUST support certificate-based client authentication.” and the last paragraph n section 5.3, I can see usecases where the client does not need to be authenticated when the security information to be shared is public and does not contain any confidential info. Would it be worth to state “In usecases where client authentication is required to access the shared information use TLS client certs”? Also, mandating client cert auth is slightly aggressive. There might be usecases where HTTP Basic or Digest authentication/authorization (described in Section 5.4) would be sufficient. Would it be worth to make TLS client certs a SHOULD.
The intention of the requirement is that implementations MUST support the authentication, but that any given repo may use it as they see fit. Publicly shared repos wouldn’t require this, but the implementation they use MUST have support for it if that repo desired authentication. To help avoid confusion, we’ve added a section in the front matter that clarifies that all requirements in the document pertain to implementations, not usage.

·         In section 5.3, RFC5280 is referenced. Section 6.3 explains how CRL revocation checks are performed. Even though the draft deals with CRLs it explains that the revocation status can be checked with other methodologies. I am suggesting to spell out in section 5.3 that CRL or OCSP/OCSP stapling are both acceptable for verification of revocation status.
Changed the wording to make it clear that any functionally equivalent method is acceptable.

·         In section 5.4, “Implementations MUST support user authentication.  User authentication MAY be enabled for specific Feeds.” Is slightly confusing. User auth is mandatory and the it is a MAY for Feeds? It is worth to rephrase it more clearly.

·         Make sure to remove the paragraph with “[TO BE REMOVED:” in section 8.3.
The “TO BE REMOVED” is an IANA action that should be processed during publication without our interference (hopefully).

·         In section 9, “public education may choose to rely upon HTTP Authentication or similar”, I would suggest to reconsider, as I mention above, if authentication is necessary for public information that can be shared openly.
To help avoid confusion, we’ve added a section in the front matter that clarifies that all requirements in the document pertain to implementations, not usage.

Rgs,
Panos