Generic Security Service Application Programming Interface (GSS-API) Naming Extensions
draft-ietf-kitten-gssapi-naming-exts-15

[Ballot comment]
In section 5:

  Another aspect of context is encoding of the attribute information.
  An attribute containing an ASCII or UTF-8 version of an e-mail
  address could not be interpreted the same as a ASN.1 Distinguished
  Encoding Rules e-mail address in a certificate.

  All of these contextual aspects of a name attribute affect whether
  two attributes can be treated the same by an application and thus
  whether they should be considered the same name attribute.  In the
  GSS-API naming extensions, attributes that have different contexts
  MUST have different names so they can be distinguished by
  applications.  As an unfortunate consequence of this requirement,
  multiple attribute names will exist for the same basic information.
  That is, there is no single attribute name for the e-mail address of
  an initiator.

I don't have the expertise to evaluate this document thorougly, but something in the above seems weird, if not incorrect. It is certainly the case that an email address encoded in ASCII or UTF-8 cannot be byte-for-byte compared to the same email address encoded as an ASN.1 Distinguished Encoding Rules e-mail address. But the words "could not be interpreted the same as" strike me as incorrect. You *can* interpret the two e-mail address as the same if, after doing the decoding, you compare the addresses to eachother. And it would, indeed, be very unfortunate for something that happens to use a different encoding to get a different name for each encoding and therefore have multiple non-comparable occurances of the item. It seems like you would want only one occurance of each item, marked with the encoding, and implementations would be responsible for the decoding.

Maybe this is just a language issue. But something seems wrong about the above.

[Ballot comment]
I have no objection to the publication of this document, and just
three minor nits you may want to look at.

Section 2

  This document proposes concrete GSS-API
  extensions.

Should feel free to be more positive! s/proposes/defines/

---

Section 3

I suspect the RFC editor will ask you to expand "iff"
             
---

Please consider replacing the reference text used here for
[OASIS.saml-core-2.0-os] with the text used in RFC 6595 to include the
stable URL.

[Ballot comment]

  Please consider the editorial comments from the Gen-ART Review by
  Pete McCann on 24-Apr-2012.  The review can be found at:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07387.html

[Ballot comment]
Only nits:

s2: r/(eg an X509/(e.g., an X.509
s3/s5/s7.5/s7.6: r/iff/if  X3
s5: Consider Kerberos PKINIT (RFC 4556).  Isn't this an informative reference? so: Consider Kerberos PKINIT [RFC4556].
s5: r/certificate authority/certification authority X2
s5: references for ASCII/UTF-8/ASN.1?

IESG:

IANA has reviewed draft-ietf-kitten-gssapi-naming-exts-14.txt, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need to be completed.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (GSS-API Naming Extensions) to Proposed Standard





The IESG has received a request from the Common Authentication Technology

Next Generation WG (kitten) to consider the following document:

- 'GSS-API Naming Extensions'

  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@ietf.org mailing lists by 2012-04-10. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





  The Generic Security Services API (GSS-API) provides a simple naming

  architecture that supports name-based authorization.  This document

  introduces new APIs that extend the GSS-API naming model to support

  name attribute transfer between GSS-API peers.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-kitten-gssapi-naming-exts/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-kitten-gssapi-naming-exts/ballot/





No IPR declarations have been submitted directly on this I-D.

Here's the PROTO write up I got.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard.
This draft defines standard interfaces.
Yes.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

The Generic Security Services API (GSS-API) provides a simple naming
architecture that supports name-based authorization.  This document
introduces new APIs that extend the GSS-API naming model to support
name attribute transfer between GSS-API peers.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Nothing worth noting regarding WG process.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

This protocol has been implemented in the MIT 1.8 release.  At least one other
vendor has plans on implementing this in the future as well.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

This document is going back to the working group to address issues raised by Sam Hartman and confirmed in wg discussions.  See wg emails:
http://www.ietf.org/mail-archive/web/kitten/current/msg01872.html
http://www.ietf.org/mail-archive/web/kitten/current/msg01892.html
and
http://www.ietf.org/mail-archive/web/kitten/current/msg01895.html
and the kitten meeting summary for IETF 78:
http://www.ietf.org/mail-archive/web/saag/current/msg02858.html

IANA comments:

IANA understands that this document creates a standardized namespace for
GSS-API attributes. IANA understands that no registration is required
now, but that a registry may be required in the future.

IANA understands that this document does not require any IANA actions
upon approval.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Shawn Emery , yes, yes

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document had adequate review from the WG members.  The shepherd doesn't
know of reviews by non WG members.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No concerns. No IPR disclosure is known to the author or the shepherd.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

There is WG consensus to publish the document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

Nobody threatened to appeal.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

idnits 2.12.04 found one error in regards to a downward reference, but this was
expected.  See section 1.h.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

There is a downward reference made to RFC3061.  This does not set a precedence
as other RFCs with standards track make references to this informational RFC,
e.g.: RFC4088.  However, this draft makes an informational reference to 3061
as a MUST.  I believe that this should make a normative reference 3061.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists, but reservations are not required
as this document does not, nor should attempt to allocate name attribute URIs.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

There is no specification of ABNF, MIB, XML, or ASN.1 in this document.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

This document provides an extension to the Generic Security Services Application
Programming Interface (GSS-API) to include the exchange of name attributes
between peers.  These attributes could be intern used for authorization by
applications.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

Nothing worth noting regarding WG process.

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

This protocol has been implemented in the MIT 1.8 release.  At least one other
vendor has plans on implementing this in the future as well.