The IESG <iesg-secretary@xxxxxxxx> writes: > The IESG has received a request from the Kitten (GSS-API Next Generation) > WG (kitten) to consider the following document: > > - 'GSS-API Naming Extensions ' > <draft-ietf-kitten-gssapi-naming-exts-08.txt> as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2010-07-23. Exceptionally, > comments may be sent to iesg@xxxxxxxx instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-08.txt Here are my comments: 1) Section 3 says: An attribute is 'authenticated' iff there is a secure association I suggest expanding iff for clarity. 2) Section 7 defines several new APIs, but I cannot find discussion about who is responsible for de-allocating the output buffers: the caller or the GSS-API implementation. For example, in section 7.1 the 'display_name' parameter is defined as: o display_name STRING First, it should probably be OCTET STRING, not STRING, at least I cannot find any type called only STRING in RFC 2743. Secondly, also compare how RFC 2743 clarifies who is responsible for memory de-allocation like this: o interprocess_token OCTET STRING -- caller must release -- with GSS_Release_buffer() Something similar is needed. 3) The C-binding sections are not complete, they need to describe semantics for the function and its parameters. Compare how RFC 2744 defines each function and discusses each parameter. For the interprocess_token above, there is this text: interprocess_token buffer, opaque, modify token to be transferred to target process. Storage associated with this token must be freed by the application after use with a call to gss_release_buffer(). I expect similar text for each C function and its parameters. 4) The mapping of PKIX subjectAltNames to values is fuzzily described in section 6.2: PKIX certificate subjectAltNames MUST be mapped as *authenticated* GSS-API name attributes. The values SHOULD be the values of the subjectAltName represented as OCTET STRINGs if the type of the subjectAltName supports a unique loss-less representation as string values. Specifically dnsName, ipAddress, uniformResourceLocator and emailAddress MUST be returned using the corresponding string representation of those data types. 6.2.2. Other PKIX Certificate Extensions and Attributes Any X.509 certificate extension not covered above SHOULD be represented as GSS-API name attributes with the OID of the X.509 extension and with OCTET STRING values containing the encoded value of the extension. Is "supports a unique loss-less representation" intended to _only_ mean dnsName+ipAddress+uniformResourceLocator+emailAddress or are other types also intended to be covered if they, decided by each implementer, can be uniquely and loss-lessly converted? For good interop, I believe the document should clarify for each supported type exactly how translation should work, and not leave this aspect implementation defined. For example, the ipAddress extension holds binary data (of arbitrary length, for IPv4+IPv6), and there are several data formats permitted (127.0.0.1, 127.1, 127::1, etc). It should specify a unique data format. Further, the text above is not clear how the commonly used XMPP subjectAltName extension is translated because that uses an SubjectAltName otherName type. Again, these problems would be solved if the document contains an explicit list of SAN types that are supported and describe exactly how they are converted to string values. /Simon _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf