X.509v3 Certificates for Secure Shell Authentication
RFC 6187

[Ballot comment]
Section 1 says:
  >
  > Digital certificates, such as those in X.509 version 3 (X.509v3)
  > format, ...
  >
  Please add a reference.  [RFC5280] seems appropriate.

  Section 1 also says:
  >
  > This document is concerned with SSH implementation details;
  > specification of the underlying cryptographic algorithms and the
  > handling and structure of X.509v3 certificates is left to other
  > standards documents.
  >
  What documents does an implementer need to read?  Obviously, RFC 5280
  is needed.  Please list them as normative references.

[Ballot discuss]
Section 2.1 says:
  >
  > o  There is no requirement on the ordering or number of OCSP
  >    responses.
  >
  There is no reason for the number of OCSP responses to exceed the
  number of certificates proviced.  Why allow more?

  Section 2.1 also says:
  >
  > [RFC5280] describes the structure of X.509v3 certificates to be
  > used with RSA and Digital Signature Algorithm (DSA) public keys.
  >
  I think that RFC 3279 is a better reference for these algorithms.

  Section 2.2.1 says:
  >
  > o  The digitalSignature KeyUsage identifier MAY be used with
  >    certificates for x509v3-ssh-dss, x509v3-ssh-rsa, and x509v3-
  >    ecdsa-sha2-* public key algorithms.
  >
  I think this is incorrect.  I think it should say: If the keyUsage
  extension is present in the cerificate, then digitalSignature MUST
  be set for these identifiers.

  Section 2.2.1 also says:
  >
  > o  The keyAgreement KeyUsage identifier MAY be used for certificates
  >    with convey keys for use with the ecmqv-sha2 key exchange method.
  >
  I think this is incorrect.  I think it should say: If the keyUsage
  extension is present in the cerificate, then digkeyAgreement MUST
  be set for these identifiers.

[Ballot discuss]
This is a discuss-discuss.

A third party IPR disclosure was recently filed on this document.  Given that Certicom is assumed to have IPR
that could apply to any Internet Draft including elliptic curve technology, I do not think this changes the community
consensus but I want to hear the opinions of other ADs.

[Ballot discuss]
Section 4 states:

  For the purposes of server authentication, the mapping between
  certificates and host names is left as an implementation and
  configuration issue for implementers and system administrators.

Leaving this up to software implementers and service operators seems shortsighted. For the sake of interoperability and improved security, I think it would be good to specify rules for checking the identity of hostnames asserted by the server (if the client does not check the server's identity, how can it be said to have authenticated the server?). It might be appropriate to cite draft-saintandre-tls-server-id-check or to borrow some text from that document.

[Ballot comment]
Section 1 says:
  >
  > Digital certificates, such as those in X.509 version 3 (X.509v3)
  > format, ...
  >
  Please add a reference.  [RFC5280] seems appropriate.

  Section 1 also says:
  >
  > This document is concerned with SSH implementation details;
  > specification of the underlying cryptographic algorithms and the
  > handling and structure of X.509v3 certificates is left to other
  > standards documents.
  >
  What documents does an implementer need to read?  Obviously, RFC 5280
  is needed.  Please list them as normative references.

[Ballot discuss]
Section 2.1 says:
  >
  > o  There is no requirement on the ordering or number of OCSP
  >    responses.
  >
  There is no reason for the number of OCSP responses to exceed the
  number of certificates proviced.  Why allow more?

  Section 2.1 also says:
  >
  > [RFC5280] describes the structure of X.509v3 certificates to be
  > used with RSA and Digital Signature Algorithm (DSA) public keys.
  >
  I think that RFC 3279 is a better reference for these algorithms.

  Section 2.2.1 says:
  >
  > o  The digitalSignature KeyUsage identifier MAY be used with
  >    certificates for x509v3-ssh-dss, x509v3-ssh-rsa, and x509v3-
  >    ecdsa-sha2-* public key algorithms.
  >
  I think this is incorrect.  I think it should say: If the keyUsage
  extension is present in the cerificate, then digitalSignature MUST
  be set for these identifiers.

  Section 2.2.1 also says:
  >
  > o  The keyAgreement KeyUsage identifier MAY be used for certificates
  >    with convey keys for use with the ecmqv-sha2 key exchange method.
  >
  I think this is incorrect.  I think it should say: If the keyUsage
  extension is present in the cerificate, then digkeyAgreement MUST
  be set for these identifiers.

[Ballot comment]
A well written document, one question:

2.1.  Public Key Format

  For all of the public key algorithms specified in this document, the
  key format consists of a sequence of one or more X.509v3 certificates
  followed by a sequence of 0 or more Online Certificate Status
  Protocol (OCSP) responses as in Section 4.2 of [RFC2560].  Providing
  OCSP responses directly in this data structure can reduce the number
  of communication rounds required (saving the implementation from
  needing to perform OCSP checking out-of-band) and can also allow a
  client outside of a private network to receive OCSP responses from a
  server behind firewall.

This text almost make it sound as if OCSP data is optional to include.

IANA has a question about the IANA Actions required for this document.

Upon approval of this document, IANA understands that there are two IANA
Actions that it needs to complete.

First, in the Public Key Algorithm Names subregistry of the Secure Shell
(SSH) Protocol Parameters located at:

http://www.iana.org/assignments/ssh-parameters

three new algorithms are to be registered as follows:

Public Key Algorithm Name: x509v3-ssh-dss
Reference: [ RFC-to-be ]
Note:

Public Key Algorithm Name: x509v3-ssh-rsa
Reference: [ RFC-to-be ]
Note:

Public Key Algorithm Name: x509v3-rsa2048-sha256
Reference: [ RFC-to-be ]
Note:

IANA QUESTION: How should the family of SSH public key algorithm names
beginning with "x509v3-ecdsa-sha2-" be represented in the Public Key
Algorithm Names registry?

Second, The two object identifiers used in Section 2.2.2 were assigned
from an arc delegated by IANA to the PKIX Working Group. No further
action by IANA is necessary for this document.

IANA understands that these IANA Actions are the only ones that need to
be completed upon approval of the document.

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,
. 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.