Hi James, On Mon, Jan 27, 2020, at 1:12 PM, Gould, James wrote: > Roman,
> > In thinking about a little bit more, I believe the ABNF for the > <loginSec:app> element value needs to be simplified and made more consistent > with the other ABNF with: > > app = name SP version > name = 1*VCHAR > version = 1*VCHAR > > Does the use of the ABNF help to clarify how to create the > <loginSec:userAgent> child element values? Your suggested ABNF for 3 elements certainly helps. I think you should also clarify any expected uses of this information, if you can. Best Regards, Alexey > > Thanks, > > -- > > JG > > cid:[email protected] > > *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/> > > *From: *James Gould <[email protected]> > *Date: *Friday, January 24, 2020 at 6:04 PM > *To: *Roman Danyliw <[email protected]>, "Gould, James" > <[email protected]>, The IESG <[email protected]> > *Cc: *"[email protected]" > <[email protected]>, Joseph Yee <[email protected]>, > "[email protected]" <[email protected]>, "[email protected]" > <[email protected]> > *Subject: *Re: [EXTERNAL] RE: Roman Danyliw's Discuss on > draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT) > > Roman, > > I provide proposed updates below with the JG2 prefix. > > -- > > JG > > cid:[email protected] > > *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/> > > *From: *Roman Danyliw <[email protected]> > *Date: *Thursday, January 23, 2020 at 8:36 AM > *To: *"Gould, James" <[email protected]>, The IESG > <[email protected]> > *Cc: *"[email protected]" > <[email protected]>, Joseph Yee <[email protected]>, > "[email protected]" <[email protected]>, "[email protected]" > <[email protected]> > *Subject: *[EXTERNAL] RE: Roman Danyliw's Discuss on > draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT) > *Resent-From: *<[email protected]> > *Resent-To: *James Gould <[email protected]>, <[email protected]> > *Resent-Date: *Thursday, January 23, 2020 at 8:36 AM > > Hi JG! > > Thanks for the quick response. See details inline … > > *From:* iesg <[email protected]> *On Behalf Of *Gould, James > *Sent:* Wednesday, January 22, 2020 4:42 PM > *To:* Roman Danyliw <[email protected]>; The IESG <[email protected]> > *Cc:* [email protected]; Joseph Yee > <[email protected]>; [email protected]; [email protected] > *Subject:* Re: Roman Danyliw's Discuss on > draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT) > > Roman, > > Thank you for your review and feedback. I include my comments 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/22/20, 12:52 PM, "Roman Danyliw via Datatracker" <[email protected]> > wrote: > > Roman Danyliw has entered the following ballot position for > draft-ietf-regext-login-security-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria..html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > ** Section 3.1. When @type=”stat” and the name of the stat is set in @name, > how does a client know the semantics of this stat? Is that negotiated out of > band? > > JG - The possible set of "stat" type security event "name" values can be > discovered / negotiated out of band or in band via a separate policy EPP > extension, such as draft-gould-regext-login-security-policy. > > [Roman] Understood. Can you include a sentence to that effect. > > JG2 – I believe the best way to handle this is to add the following to the > description of the “name” attribute, which will cover both the use of the > “name” attribute for the “stat” and “custom” types: > > *The possible set of "name" values, by event type, can be discovered / > negotiated out of band to EPP or using a separate EPP extension designed to > provide server policy information to the client.* > > ** Section 4.1. Per <loginSec:userAgent>, how are the clients supposed to > generate the app, tech or os strings in a way that the server will > understand? > If this is out of scope, please just say so. > > JG - Yes, that is out of scope, but there is a concrete example available in > the Verisign EPP SDK, which is referenced in section 7.1 of > draft-ietf-regext-login-security. > > [Roman] Understood. Can you add a sentence to that effect here too. These > would address my concerns. > > JG2 – To address your, Alexey’s, and Benjamin’s concern, I will add the > following bolded text to the draft: > > <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". *The <loginSec:app> element value can be* > * created by appending the version number to the name of the* > * application software, such as the Augmented Backus-Naur Form* > * (ABNF) grammar [RFC5234] format:* > * * > * app = name SP version* > * name = 1*ALPHA *(ALPHA / SP) 1*ALPHA* > * version = 1*DIGIT "." 1*DIGIT "." 1*DIGIT* > <loginSec:tech>: OPTIONAL technology used for the client > software with version if available, such as "Vendor Java > 11.0.2". *The <loginSec:tech> element value can be created by* > * including the technology vendor, technology name, and* > * technology version, such as the Augmented Backus-Naur Form* > * (ABNF) grammar [RFC5234] format:* > * * > * tech = vendor SP name SP version* > * vendor = 1*VCHAR* > * name = 1*VCHAR* > * version = 1*VCHAR* > <loginSec:os>: OPTIONAL client operating system used with > version if available, such as "x86_64 Mac OS X 10.14.6". *The* > * <loginSec:os> element value can be created by including the* > * operating system architecture, operating system name, and* > * operating system version, such as the Augmented Backus-Naur* > * Form (ABNF) grammar [RFC5234] format:* > * * > * os = arch SP name SP version* > * arch = 1*VCHAR* > * name = 1*VCHAR* > * version = 1*VCHAR* > > JG2 – Is this what you were looking for? > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Alissa Cooper’s DISCUSS position. > > ** Section 3.1. Is a @value required when @type=”cipher” or > @type=”tlsProtocol”? The examples in Section 4 show the use of @value. Also, > what format should be used to express the cipher or tlsProtocol? > > JG – There is no normative language that requires the “value” for > @type=”cipher” or @type=”tlsProtocol”. It is reasonable to expect an > implementer to populate the “value” attribute based on: > · the description of the “cipher” and “tlsProtocol” types with “Identifies…”; > · the description of the “value” attribute with “Identifies the value that > resulted in the login security event”; > · the example EPP response where there is a set of login security events. > > JG – The format of the “cipher” or “tlsProtocol” is dependent on the > server-side TLS library, where the server would return the “cipher” or > “tlsProtocol” value provided by the TLS library upon a successful TLS > handshake. The format is left free-form based on this dependency. > > [Roman] No problem. Thanks for the clarification. > > ** Section 3.1. Per the description of event@lang, please cite the language > format as coming from Section 3.4.3[W3C.REC-xmlschema-2-20041028] > > JG – Yes, I can add the reference to section > 3.3.3[W3C.REC-xmlschema-2-20041028] for the “lang” attribute. I believe that > section 3.3.3 is the correct section. > > [Roman] Thanks. > > ** Section 4.1. Per the children of <loginSec:userAgent>, would supporting a > more formal approach also be useful -- using SWID (ISO/IEC 19770-2:2015) or > COSWID (draft-ietf-sacm-coswid)? > > JG – I’ll review SWID and COSWID, but I believe the <loginSec:userAgent> > children currently meet the needs. > > [Roman] No problem. I wanted to ensure there was awareness of related work on > an XML approach to what seemed like the same approach. > > ** Section 4.1. Per pw and newPW’s descriptions of “all internal continuous > whitepaces … is replaced with a single #x20” – is this intentionally > precluding > a password with a double space? > > JG – The intention is to describe how the XML schema “token” type is handled. > The XML schema “token” type is used in EPP RFC 5730, which > draft-ietf-regext-login-security is extending to remove the 16 character > constraint. There is no intention to implicitly or explicitly change the > handling of whitespace from what is defined in EPP RFC5730. > > [Roman] I understand the thinking – just read it as a token type (which it > would be anyway per the schema). Thanks for clarifying. > > ** Section 4.1. Per “If non-ASCII characters are supported with the plain > text > password, then use a standard for passwords with international characters, > such > as the OpaqueString PRECIS profile in [RFC8265].”, if non-ASCII characters > are > supported, how does a client know which approach to take with a given server > in > an interoperable. RFC8265 is a helpful reference but the current text seems > to > provide no guidance. > > JG – This language was added based on a discussion with the Area Director to > address a concern raised on the mailing list. The server policy can be > communicated out of band or in band using a policy extension such as > draft-gould-regext-login-security-policy. > > [Roman] Understood. IMO, noting that this kind of policy should/could be > communicated out of band would be a helpful clarification. > > ** Section 5. Please note in the Section 5 introduction that the blob between > the BEGIN and END tags in Section 5.1 are formally specified by XML Schema. > > JG – I can add “XML” prior to each “schema” reference in the introduction of > section 5. > > [Roman] Thanks. This is really a reference nit – if you use a formal > language, just cite it. > > ** Section 8. Please note that the Security Considerations of RFC5730 apply > and that this document enhances these security services. > > JG – I can add a leading sentence to section 8 stating that, “The Security > Considerations of [RFC5730] apply in this document, and this document > enhances these considerations.” > > [Roman] Thanks. Works for me. > > ** Editorial Nits > -- Section 1. Typo. s/pssword/password/ > > JG – I believe the nit is s/pasword/password/ in section 1, which will be > fixed. > > [Roman] Right – with some irony, that’s the typo I was referencing with my > own typo. Thanks. > > Thanks, > Roman > > *Attachments:* > * image001.png > * image002.png
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
