draft-igoe-secsh-x509v3-06.txt

[Jeffrey Hutzelman <[e-mail]>]

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,
<[e-mail]>.  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.