draft-igoe-secsh-x509v3-06.txt

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

This is a request for the IESG to approve publication of "X.509v3
Certificates for Secure Shell Authentication",
draft-igoe-secsh-x509v3-06.txt, as a Proposed Standard.
This document is an individual submission to the IESG.

(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?

The Document Shepherd for this document is Jeffrey Hutzelman,
<jhutz%cmu.edu@localhost>.  I have reviewed this document, and I believe
it is ready for IETF-wide review and publication as a Proposed
Standard.

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

While the SECSH working group concluded in 2006, its mailing list
remains an active forum for SSH implementation developers and other
interested parties.  This draft has been discussed in that forum
and has evolved as a part of that discussion.  I am satisfied that
it has received sufficient review.

(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?

I don't believe any particular additional review is needed.

(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 interested community has discussed those issues and has
      indicated that it still wishes to advance the document, detail
      those concerns here.

I have no concerns or issues with this document.

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

There seems to be a solid consensus among those who have been active
in the discussions of this document.

There has long been interest in the SSH community in supporting X.509
certificates within the SSH protocol; in fact, such work was being
pursued in the SECSH working group prior to its conclusion (see
draft-ietf-secsh-x509-03.txt).  While not everyone active on the
mailing list has participated in discussions of the present document,
there seems to be a solid consensus to move forward among those who
have.  Participants who have been active in this discussion include
several SSH implementors and one of the co-authors of the previously
mentioned 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.)

I am not aware of any such threats or indications of discontent.

(1.g)  Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html 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?

This document satisfies the idnits tool and all of the requirements
called out in ID-Checklist.html.  No additional formal review criteria
apply.

(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].

References in this document are appropriately split.
There is a downward reference to RFC3447, an Informational document
which is a republication of PKCS#1 v2.1.

(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 suggested a reasonable name for the new registry?  See
      [I-D.narten-iana-considerations-rfc2434bis].  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 is correct and consistent with the
body of the document.  This document registers three SSH public key
algorithm names and one family of SSH public key algorith names; it
does not create any new registries.

(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?

This document contains no sections written in formal machine-readable
languages.  It does define protocol messages in the form traditionally
used for the SSH protocol and its extensions, including use of data
types taken from section 5 of RFC4251; these are used correctly.

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


Technical Summary

  X.509 public key certificates use a signature by a trusted
  certification authority to bind a given public key to a given digital
  identity.  This document specifies how to use X.509 version 3 public
  key certificates in public key algorithms in the Secure Shell
  protocol.

Working Group Summary

  When the Secure Shell working group concluded in 2006, active
  work on defining use of X.509 certificates in the SSH protocol
  was left uncompleted.  However, there was and continues to be
  community interest in extending the SSH protocol to provide this
  functionality.

  Further, although the working group concluded, its mailing list
  remains active as a forum for discussion among SSH protocol
  implementors and other interested parties.  This document was
  discussed extensively on that list, and seems to represent the
  consensus of participants in that discussion.

Document Quality

  A number of SSH implementors have been active in reviewing and
  discussing this extension.  While no one has explicitly said
  whether they intend to implement, it seems likely that several
  will do so.