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). > > 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. Best Regards, Alexey _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
