Hi James, (Top post)
Your changes look good to me. Best Regards, Alexey On Mon, Jan 27, 2020, at 4:40 PM, Gould, James wrote: > Alexey, > > My responses are embedded below. > > -- > > JG > > > > James Gould > Distinguished Engineer > [email protected] > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > On 1/27/20, 9:02 AM, "Alexey Melnikov" <[email protected]> wrote: > > Hi James, > > On Thu, Jan 23, 2020, at 9:29 PM, Gould, James wrote: > > Alexey, > > [snip] > > > > > Thank you for this document. I have several small comments similar > > to what was > > raised by Roman and Ben: > > > > 1) In 4.1: > > > > <loginSec:userAgent>: OPTIONAL client user agent that identifies the > > client application software, technology, and operating system > > used by the server to identify functional or security > > constraints, current security issues, and potential future > > functional or security issues for the client. The > > <loginSec:userAgent> element MUST contain at least one of the > > following child elements: > > > > <loginSec:app>: OPTIONAL name of the client application software > > with version if available, such as the name of the client SDK > > "EPP SDK 1.0.0". > > <loginSec:tech>: OPTIONAL technology used for the client > > software with version if available, such as "Java 11.0.2". > > <loginSec:os>: OPTIONAL client operating system used with > > version if available, such as "x86_64 Mac OS X 10.11.6". > > > > Is there a registry of allowed values or at least some instructions how to > > construct these values? There are probably several existing IETF registries > > that can be reused. > > > > JG - I'm not aware of any registries that exist that describes how to > > construct these values. I believe to address Roman's, Ben's and your > > feedback, I will provide an example of how to construct these values. > > I am not insisting that you should use these, but some examples: > > > https://www.iana.org/assignments/operating-system-names/operating-system-names.xhtml#operating-system-names-1 > > and probably more interesting: > > https://www.iana.org/assignments/iodef2/iodef2.xhtml#softwarereference-dtype > > The latter points to NIST's Common Platform Enumeration and ISO 19770 > software identification (SWID). > > JG - I believe inclusion of the example ABNF for constructing the > <loginSec:userAgent> child element values will provide the needed > clarification. It looks like you feel the same way based on your response to > Roman's thread. I'll address the usage of the information. > > > > > > If these values are not supposed to be used by servers for anything > > other than > > logging (i.e. if they can't be used to work around bugs), then the > > document > > needs to say that. > > > > JG - The servers can leverage this information for more than logging; > > although logging is the most common use case. The most useful element > > for identification is the <loginSec:app>, where if there is a known > > client application such as an EPP SDK, the server can key off of the > > EPP SDK version to proactively identify potential security issues to > > report back to the client. The server may already know the client > > application patterns or can identify the client application patterns > > using the logs to create rules for specific clients applications. The > > additional <loginSec:tech> and <loginSec:os> elements are useful to > > identify future security policy issues, such as deprecating or removing > > TLS cipher suites or TLS protocols. The short answer to your question > > is that the server can utilize the elements for logging and for driving > > security event rules, but this is beyond the scope of the extension > > specification. > > I think saying something along these lines would be helpful. > > JG - To address this, I can update the description of the > <loginSec:userAgent> as: > > OPTIONAL client user agent information that identifies the client application > software, technology, and operating system used by the server to identify > functional or security constraints, current security issues, and potential > future functional or security issues for the client. *The server may use the > information for real-time identification and client notification of security > issues, such as keying off of the client application software for executing > security rule checks. The server may capture the information to identify > future security policy issues, such as deprecating or removing TLS cipher > suites or TLS protocols.* The <loginSec:userAgent> element MUST contain at > least one of the following child elements: > > > Best Regards, > Alexey >
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
