X.509v3 Certificates for Secure Shell Authentication
draft-igoe-secsh-x509v3-07

Network Working Group                                            K. Igoe
Internet-Draft                                  National Security Agency
Intended status: Standards Track                              D. Stebila
Expires: July 7, 2011                Queensland University of Technology
                                                         January 3, 2011

          X.509v3 Certificates for Secure Shell Authentication
                       draft-igoe-secsh-x509v3-07

Abstract

   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 7, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as

Igoe & Stebila            Expires July 7, 2011                  [Page 1]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Public Key Algorithms Using X.509 Version 3 Certificates . . .  5
     2.1.  Public Key Format  . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Certificate Extensions . . . . . . . . . . . . . . . . . .  7
       2.2.1.  KeyUsage . . . . . . . . . . . . . . . . . . . . . . .  7
       2.2.2.  ExtendedKeyUsage . . . . . . . . . . . . . . . . . . .  8
   3.  Signature Encoding . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  x509v3-ssh-dss . . . . . . . . . . . . . . . . . . . . . .  9
     3.2.  x509v3-ssh-rsa . . . . . . . . . . . . . . . . . . . . . .  9
     3.3.  x509v3-rsa2048-sha256  . . . . . . . . . . . . . . . . . .  9
     3.4.  x509v3-ecdsa-sha2-*  . . . . . . . . . . . . . . . . . . . 10
   4.  Use in public key algorithms . . . . . . . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Appendix A.  Example . . . . . . . . . . . . . . . . . . . . . . . 19
   Appendix B.  Acknowledgements  . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21

Igoe & Stebila            Expires July 7, 2011                  [Page 2]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

1.  Introduction

   There are two Secure Shell (SSH) protocols that use public key
   cryptography for authentication.  The Transport Layer Protocol,
   described in [RFC4253], requires that a digital signature algorithm
   (called the "public key algorithm") MUST be used to authenticate the
   server to the client.  Additionally, the User Authentication Protocol
   described in [RFC4252] allows for the use of a digital signature to
   authenticate the client to the server ("publickey" authentication).

   In both cases, the validity of the authentication depends upon the
   strength of the linkage between the public signing key and the
   identity of the signer.  Digital certificates, such as those in X.509
   version 3 (X.509v3) format [RFC5280], are used in many corporate and
   government environments to provide identity management.  They use a
   chain of signatures by a trusted root certification authority and its
   intermediate certificate authorites to bind a given public signing
   key to a given digital identity.

   The following public key authentication algorithms are currently
   available for use in SSH:

                       +--------------+-----------+
                       |   Algorithm  | Reference |
                       +--------------+-----------+
                       |    ssh-dss   | [RFC4253] |
                       |              |           |
                       |    ssh-rsa   | [RFC4253] |
                       |              |           |
                       | pgp-sign-dss | [RFC4253] |
                       |              |           |
                       | pgp-sign-rsa | [RFC4253] |
                       |              |           |
                       | ecdsa-sha2-* | [RFC5656] |
                       +--------------+-----------+

   Since Pretty Good Privacy (PGP) has its own method for binding a
   public key to a digital identity, this document focuses solely upon
   the non-PGP methods.  In particular, this document defines the
   following public key algorithms which differ from the above solely in
   their use of X.509v3 certificates to convey the signer's public key.

Igoe & Stebila            Expires July 7, 2011                  [Page 3]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

                         +-----------------------+
                         |       Algorithm       |
                         +-----------------------+
                         |     x509v3-ssh-dss    |
                         |                       |
                         |     x509v3-ssh-rsa    |
                         |                       |
                         | x509v3-rsa2048-sha256 |
                         |                       |
                         |  x509v3-ecdsa-sha2-*  |
                         +-----------------------+

   Public keys conveyed using the x509v3-ecdsa-sha2-* public key
   algorithms can be used with the ecmqv-sha2 key exchange method.

   Implementation of this specification requires familiarity with the
   Secure Shell protocol [RFC4251] [RFC4253] and X.509v3 certificates
   [RFC5280].  Data types used in describing protocol messages are
   defined in Section 5 of [RFC4251].

   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, particularly [RFC3447], [FIPS-186-3],
   [FIPS-180-2], [FIPS-180-3], [SEC1], and [RFC5280].

   An earlier Internet-Draft for the use of X.509v3 certificates in the
   Secure Shell was proposed by O. Saarenmaa and J. Galbraith; while
   this document is informed in part by that Internet-Draft, it does not
   maintain strict compatibility.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Igoe & Stebila            Expires July 7, 2011                  [Page 4]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

2.  Public Key Algorithms Using X.509 Version 3 Certificates

   This document defines the following new public key algorithms for use
   in the Secure Shell protocol: x509v3-ssh-dss, x509v3-ssh-rsa, x509v3-
   rsa2048-sha256, and the family of algorithms given by x509v3-ecdsa-
   sha2-*.  In these algorithms, a public key is stored in an X.509v3
   certificate.  This certificate, a chain of certificates leading to a
   trusted certificate authority, and optional messages giving the
   revocation status of the certificates are sent as the public key data
   in the Secure Shell protocol according to the format in this section.

2.1.  Public Key Format

   The reader is referred to [RFC5280] for a general description of
   X.509 version 3 certificates.  For the purposes of this document, it
   suffices to know that in X.509 a chain or sequence of certificates
   (possibly of length one) allows a trusted root certificate authority
   and its intermediate certificate authorities to cryptographically
   bind a given public key to a given digital identity using public key
   signatures.

   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.  As with any use of OCSP data,
   implementations SHOULD check that the production time of the OCSP
   response is acceptable.  It is RECOMMENDED, but not REQUIRED, that
   implementations reject certificates for which the certificate status
   is revoked.

   The key format has the following specific encoding:

     string  "x509v3-ssh-dss" / "x509v3-ssh-rsa" /
             "x509v3-rsa2048-sha256" / "x509v3-ecdsa-sha2-[identifier]"
     uint32  certificate-count
     string  certificate[1..certificate-count]
     uint32  ocsp-response-count
     string  ocsp-response[0..ocsp-response-count]

   In the figure above, the string [identifier] is the identifier of the
   elliptic curve domain parameters.  The format of this string is
   specified in Section 6.1 of [RFC5656].  Information on the REQUIRED
   and RECOMMENDED sets of elliptic curve domain parameters for use with

Igoe & Stebila            Expires July 7, 2011                  [Page 5]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

   this algorithm can be found in Section 10 of [RFC5656].

   Each certificate and ocsp-response MUST be encoded as a string of
   octets using the Distinguished Encoding Rules (DER) encoding of
   Abstract Syntax Notation One (ASN.1) [ASN1].  An example of an SSH
   key exchange involving one of these public key algorithms is given in
   Appendix A.

   Additionally, the following constraints apply:

   o  The sender's certificate MUST be the first certificate and the
      public key conveyed by this certificate MUST be consistent with
      the public key algorithm being employed to authenticate the
      sender.

   o  Each following certificate MUST certify the one preceding it.

   o  The self-signed certificate specifying the root authority MAY be
      omitted.  All other intermediate certificates in the chain leading
      to a root authority MUST be included.

   o  To improve the chances that a peer can verify certificate chains
      and OCSP responses, individual certificates and OCSP responses
      SHOULD be signed using only signature algorithms corresponding to
      public key algorithms supported by the peer, as indicated in the
      server_host_key_algorithms field of the SSH_MSG_KEXINIT packet
      (see Section 7.1 of [RFC4253]).  However, other algorithms MAY be
      used.  The choice of signature algorithm used by any given
      certificate or OCSP response is independent of the signature
      algorithms chosen by other elements in the chain.

   o  Verifiers MUST be prepared to receive certificate chains and OCSP
      responses that use algorithms not listed in the
      server_host_key_algorithms field of the SSH_MSG_KEXINIT packet,
      including algorithms which potentially have no Secure Shell
      equivalent.  However, peers sending such chains should recognize
      that such chains are more likely to be unverifiable than chains
      which use only algorithms listed in the server_host_key_algorithms
      field.

   o  There is no requirement on the ordering of OCSP responses.  The
      number of OCSP responses MUST NOT exceeed the number of
      certificates.

   Upon receipt of a certificate chain, implementations MUST verify the
   certificate chain according to Section 6.1 of [RFC5280] based on a
   root of trust configured by the system administrator or user.

Igoe & Stebila            Expires July 7, 2011                  [Page 6]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

   Issues associated with the use of certificates (such as expiration of
   certificates and revocation of compromised certificates) are
   addressed in [RFC5280] and are outside the scope of this document.
   However, compliant implementations MUST comply with [RFC5280].
   Implementations providing and processing OCSP responses MUST comply
   with [RFC2560].

   When no OCSP responses are provided, it is up to the implementation
   and system administrator to decide whether to accept the certificate
   or not.  It may be possible for the implementation to retrieve OCSP
   responses based on the id-ad-ocsp access description in the
   certificate's Authority Information Access data (Section 4.2.2.1 of
   [RFC5280]).  However, if the id-ad-ocsp access description indicates
   that the certificate authority employs OCSP, and no OCSP response
   information is available, it is RECOMMENDED that the certificate be
   rejected.

   [RFC5480] and [RFC5758] describes the structure of X.509v3
   certificates to be used with Elliptic Curve Digitial Signature
   Algorithm (ECDSA) public keys.  [RFC3279] and [RFC5280] describe the
   structure of X.509v3 certificates to be used with RSA and Digital
   Signature Algorithm (DSA) public keys.  [RFC5759] provides additional
   guidance for ECDSA keys in Suite B X.509v3 certificate and
   certificate revocation list profiles.

2.2.  Certificate Extensions

   Certificate extensions allow for the specification of additional
   attributes associated with a public key in an X.509v3 certificate
   (see Section 4.2 of [RFC5280]).  The KeyUsage and ExtendedKeyUsage
   extensions may be used to restrict the use of X.509v3 certificates in
   the context of the Secure Shell protocol as specified in the
   following sections.

2.2.1.  KeyUsage

   The KeyUsage extension MAY be used to restrict a certificate's use.
   In accordance with Section 4.2.1.3 of [RFC5280], if the KeyUsage
   extension is present, then the certificate MUST be used only for one
   of the purposes indicated.  There are two relevant keyUsage
   identifiers for the certificate corresponding to the public key
   algorithm in use:

   o  If the KeyUsage extension is present in a certificate for the
      x509v3-ssh-dss, x509v3-ssh-rsa, or x509v3-ecdsa-sha2-* public key
      algorithms, then the digitalSignature bit MUST be set.

Igoe & Stebila            Expires July 7, 2011                  [Page 7]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

   o  If the KeyUsage extension is present in a certificate for ecmqv-
      sha2 key exchange method, then the keyAgreement bit MUST be set.

   For the remaining certificates in the certificate chain,
   implementations MUST comply with existing conventions on KeyUsage
   identifiers and certificates as in Section 4.2.1.3 on [RFC5280].

2.2.2.  ExtendedKeyUsage

   This document defines two ExtendedKeyUsage key purpose IDs that MAY
   be used to restrict a certificate's use: id-kp-secureShellClient,
   which indicates that the key can be used for a Secure Shell client,
   and id-kp-secureShellServer, which indicates that the key can be used
   for a Secure Shell server.  In accordance with Section 4.2.1.12 of
   [RFC5280], if the ExtendedKeyUsage extension is present, then the
   certificate MUST be used only for one of the purposes indicated.  The
   object identifiers of the two key purpose IDs defined in this
   document are as follows:

   o  id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
      dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

   o  id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } -- extended key purpose
      identifiers

   o  id-kp-secureShellClient OBJECT IDENTIFIER ::= { id-kp 21 }

   o  id-kp-secureShellServer OBJECT IDENTIFIER ::= { id-kp 22 }

Igoe & Stebila            Expires July 7, 2011                  [Page 8]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

3.  Signature Encoding

   Signing and verifying using the X.509v3-based public key algorithms
   specified in this document (x509v3-ssh-dss, x509v3-ssh-rsa, x509v3-
   ecdsa-sha2-*) is done in the analogous way for the corresponding non-
   X.509v3-based public key algorithms (ssh-dss, ssh-rsa, ecdsa-sha2-*,
   respectively).  For concreteness, we specify this explicitly below.

3.1.  x509v3-ssh-dss

   Signing and verifying using the x509v3-ssh-dss key format is done
   according to the Digital Signature Standard [FIPS-186-3] using the
   SHA-1 hash [FIPS-180-2].

   The resulting signature is encoded as follows:

     string  "ssh-dss"
     string  dss_signature_blob

   The value for dss_signature_blob is encoded as a string containing r,
   followed by s (which are fixed-length 160-bit integers, without
   lengths or padding, unsigned, and in network byte order).

   This format is the same as for ssh-dss signatures in Section 6.6 of
   [RFC4253].

3.2.  x509v3-ssh-rsa

   Signing and verifying using the x509v3-ssh-rsa key format is
   performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC3447]
   using the SHA-1 hash [FIPS-180-2].

   The resulting signature is encoded as follows:

     string  "ssh-rsa"
     string  rsa_signature_blob

   The value for rsa_signature_blob is encoded as a string containing s
   (which is an integer, without lengths or padding, unsigned, and in
   network byte order).

   This format is the same as for ssh-rsa signatures in Section 6.6 of
   [RFC4253].

3.3.  x509v3-rsa2048-sha256

   Signing and verifying using the x509v3-rsa2048-sha256 key format is
   performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC3447]

Igoe & Stebila            Expires July 7, 2011                  [Page 9]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

   using the SHA-256 hash [FIPS-180-3]; RSA keys conveyed using this
   format MUST have a modulus of at least 2048 bits.

   The resulting signature is encoded as follows:

     string  "rsa2048-sha256"
     string  rsa_signature_blob

   The value for rsa_signature_blob is encoded as a string containing s
   (which is an integer, without lengths or padding, unsigned, and in
   network byte order).

   Unlike the other public key formats specified in this document, the
   x509v3-rsa2048-sha256 public key format does not correspond to any
   previously existing SSH non-certificate public key format.  The main
   purpose of introducing this public key format is to provide an RSA-
   based public key format that is compatible with current
   recommendations on key size and hash functions.  For example, NIST's
   draft recommendations on cryptographic algorithms and key lengths
   [SP-800-131] specify that digital signature generation using an RSA
   key with modulus less than 2048 bits or with the SHA-1 hash function
   is acceptable through 2010 and deprecated from 2011 through 2013,
   whereas an RSA key with modulus at least 2048 bits and SHA-256 is
   acceptable for the indefinite future.  The introduction of other non-
   certificate-based SSH public key formats compatible with the above
   recommendations is outside the scope of this document.

3.4.  x509v3-ecdsa-sha2-*

   Signing and verifying using the x509v3-ecdsa-sha2-* key formats is
   performed according to the ECDSA algorithm in [FIPS-186-3] using the
   SHA2 hash function family [FIPS-180-3].  The choice of hash function
   from the SHA2 hash function family is based on the key size of the
   ECDSA key as specified in Section 6.2.1 of [RFC5656].

   The resulting signature is encoded as follows:

     string  "ecdsa-sha2-[identifier]"
     string  ecdsa_signature_blob

   The string [identifier] is the identifier of the elliptic curve
   domain parameters.  The format of this string is specified in Section
   6.1 of [RFC5656].

   The ecdsa_signature_blob value has the following specific encoding:

     mpint   r
     mpint   s

Igoe & Stebila            Expires July 7, 2011                 [Page 10]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

   The integers r and s are the output of the ECDSA algorithm.

   This format is the same as for ecdsa-sha2-* signatures in Section
   3.1.2 of [RFC5656].

Igoe & Stebila            Expires July 7, 2011                 [Page 11]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

4.  Use in public key algorithms

   The public key algorithms and encodings defined in this document
   SHOULD be accepted any place in the Secure Shell protocol suite where
   public keys are used, including, but not limited to, the following
   protocol messages for server authentication and user authentication:

   o  in the SSH_MSG_USERAUTH_REQUEST message when "publickey"
      authentication is used [RFC4252]

   o  in the SSH_MSG_USERAUTH_REQUEST message when "hostbased"
      authentication is used [RFC4252]

   o  in the SSH_MSG_KEXDH_REPLY message [RFC4253]

   o  in the SSH_MSG_KEXRSA_PUBKEY message [RFC4432]

   o  in the SSH_MSG_KEXGSS_HOSTKEY message [RFC4462]

   o  in the SSH_MSG_KEX_ECDH_REPLY message [RFC5656]

   o  in the SSH_MSG_KEX_ECMQV_REPLY message [RFC5656]

   When a public key from this specification is included in the input to
   a hash algorithm, the exact bytes that are transmitted on the wire
   must be used as input to the hash functions.  In particular,
   implementations MUST NOT omit any of the chain certificates or OCSP
   responses that were included on the wire, nor change encoding of the
   certificate or OCSP data.  Otherwise hashes that are meant to be
   computed in parallel by both peers will have differing values.

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

   For the purposes of server authentication, it is RECOMMENDED that
   implementations support the following mechanism mapping host names to
   certificates.  However, local policy MAY disable the mechanism or MAY
   impose additional constraints before considering a matching
   successful.  Furthermore, additional mechanisms mapping host names to
   certificates MAY be used and are left as implementation and
   configuration issues for implementers and system administrators.

   The RECOMMENDED server authentication mechanism is as follows.  The
   subjectAlternativeName X.509v3 extension, as described in Section
   4.2.1.6 of [RFC5280], SHOULD be used to convey the server host name,
   using either dNSName entries or iPAddress entries to convey domain
   names or IP addresses as appropriate.  Multiple entries MAY be

Igoe & Stebila            Expires July 7, 2011                 [Page 12]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

   specified.  The following rules apply:

   o  If the client's reference identifier (e.g., the host name typed by
      the client) is a DNS domain name, the server's identity SHOULD be
      checked using the rules specified in [ID-TLS-CERTS].  Support for
      the DNS-ID identifier type is RECOMMENDED in client and server
      software implementations.  Certification authorities that issue
      certificates for use by Secure Shell servers SHOULD support the
      DNS-ID identifier type.  Service providers SHOULD include the
      DNS-ID identifier type in certificate requests.  The DNS-ID MAY
      contain the wildcard character '*' as the complete left-most label
      within the identifier.

   o  If the client's reference identifier is an IP address as defined
      by [RFC0791] or [RFC2460], the client SHOULD convert that address
      to the "network byte order" octet string representation and
      compare it against a subjectAltName entry of type iPAddress.  A
      match occurs if the octet strings are identifier for the reference
      identifier and any presented identifier.

Igoe & Stebila            Expires July 7, 2011                 [Page 13]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

5.  Security Considerations

   This document provides new public key algorithms for the Secure Shell
   protocol that convey public keys using X.509v3 certificates.  For the
   most part, the security considerations involved in using the Secure
   Shell protocol apply, since all of the public key algorithms
   introduced in this document are based on existing algorithms in the
   Secure Shell protocol.  However, implementers should be aware of
   security considerations specific to the use of X.509v3 certificates
   in a public key infrastructure, including considerations related to
   expired certificates and certificate revocation lists.

   The reader is directed to the security considerations sections of
   [RFC5280] for the use of X.509v3 certificates, [RFC2560] for the use
   of OCSP response, [RFC4253] for server authentication, and [RFC4252]
   for user authentication.  Implementations SHOULD NOT use revoked
   certificates because many causes of certificate revocation mean that
   the critical authentication properties needed are no longer true.
   For example, compromise of a certificate's private key or issuance of
   a certificate to the wrong party are common reasons to revoke a
   certificate.

   If a party to the SSH exchange attempts to use a revoked X.509v3
   certificate, this attempt along with the date, time, certificate
   identity, and apparent origin IP address of the attempt SHOULD be
   logged as a security event in the system's audit logs or the system's
   general event logs.  Similarly, if a certificate indicates that OCSP
   is used and there is no response to the OCSP query, the absence of a
   response along with the details of the attempted certificate use (as
   before) SHOULD be logged.

   As with all specifications involving cryptographic algorithms, the
   quality of security provided by this specification depends on the
   strength of the cryptographic algorithms in use, the security of the
   keys, the correctness of the implementation, and the security of the
   public key infrastructure and the certificate authorities.
   Accordingly, implementers are encouraged to use high assurance
   methods when implementing this specification and other parts of the
   Secure Shell protocol suite.

Igoe & Stebila            Expires July 7, 2011                 [Page 14]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

6.  IANA Considerations

   Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250],
   this document makes the following registrations:

   In the Public Key Algorithm Names registry:

   o  The SSH public key algorithm "x509v3-ssh-dss".

   o  The SSH public key algorithm "x509v3-ssh-rsa".

   o  The SSH public key algorithm "x509v3-rsa2048-sha256".

   o  The family of SSH public key algorithm names beginning with
      "x509v3-ecdsa-sha2-" and not containing the at-sign ('@').

   This document creates no new registries.

   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.

Igoe & Stebila            Expires July 7, 2011                 [Page 15]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

7.  References

7.1.  Normative References

   [ASN1]     International Telecommunications Union, "Abstract Syntax
              Notation One (ASN.1): Specification of basic notation",
               X.680, July 2002.

   [FIPS-180-2]
              National Institute of Standards and Technology, "Secure
              Hash Standard", FIPS 180-2, August 2002.

   [FIPS-180-3]
              National Institute of Standards and Technology, "Secure
              Hash Standard", FIPS 180-3, October 2008.

   [FIPS-186-3]
              National Institute of Standards and Technology, "Digital
              Signature Standard (DSS)", FIPS 186-3, June 2009.

   [ID-TLS-CERTS]
              Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", December 2010, <http://tools.ietf.org/
              html/draft-saintandre-tls-server-id-check-12>.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
              Adams, "X.509 Internet Public Key Infrastructure Online
              Certificate Status Protocol - OCSP", RFC 2560, June 1999.

   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
              Identifiers for the Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 3279, April 2002.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications

Igoe & Stebila            Expires July 7, 2011                 [Page 16]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

              Version 2.1", RFC 3447, February 2003.

   [RFC4250]  Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH)
              Protocol Assigned Numbers", RFC 4250, January 2006.

   [RFC4251]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, January 2006.

   [RFC4252]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Authentication Protocol", RFC 4252, January 2006.

   [RFC4253]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, January 2006.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", RFC 5480, March 2009.

   [RFC5656]  Stebila, D. and J. Green, "Elliptic Curve Algorithm
              Integration in the Secure Shell Transport Layer",
              RFC 5656, December 2009.

   [RFC5758]  Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
              Polk, "Internet X.509 Public Key Infrastructure:
              Additional Algorithms and Identifiers for DSA and ECDSA",
              RFC 5758, January 2010.

   [SEC1]     Standards for Efficient Cryptography Group, "Elliptic
              Curve Cryptography", SEC 1, September 2000,
              <http://www.secg.org/download/aid-780/sec1-v2.pdf>.

7.2.  Informative References

   [RFC4432]  Harris, B., "RSA Key Exchange for the Secure Shell (SSH)
              Transport Layer Protocol", RFC 4432, March 2006.

   [RFC4462]  Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
              "Generic Security Service Application Program Interface
              (GSS-API) Authentication and Key Exchange for the Secure
              Shell (SSH) Protocol", RFC 4462, May 2006.

   [RFC5759]  Solinas, J. and L. Zieglar, "Suite B Certificate and
              Certificate Revocation List (CRL) Profile", RFC 5759,

Igoe & Stebila            Expires July 7, 2011                 [Page 17]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

              January 2010.

   [SP-800-131]
              Barker, E. and A. Roginsky, "DRAFT Recommendation for the
              Transitioning of Cryptographic Algorithms and Key
              Lengths", NIST Special Publication 800-131, June 2010.

Igoe & Stebila            Expires July 7, 2011                 [Page 18]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

Appendix A.  Example

   The following example illustrates the use of an X.509v3 certificate
   for a public key for the Digital Signature Algorithm when used in a
   Diffie-Hellman key exchange method.  In the example, there is a chain
   of certificates of length 2, and a single OCSP response is provided.

     byte    SSH_MSG_KEXDH_REPLY
     string  0x00 0x00 0xXX 0xXX  -- length of the remaining data in
                                     this string
             0x00 0x00 0x00 0x0D  -- length of string "x509v3-ssh-dss"
             "x509v3-ssh-dss"
             0x00 0x00 0x00 0x02  -- there are 2 certificates
             0x00 0x00 0xXX 0xXX  -- length of sender certificate
             DER-encoded sender certificate
             0x00 0x00 0xXX 0xXX  -- length of issuer certificate
             DER-encoded issuer certificate
             0x00 0x00 0x00 0x01  -- there is 1 OCSP response
             0x00 0x00 0xXX 0xXX  -- length of OCSP response
             DER-encoded OCSP response
     mpint   f
     string  signature of H

Igoe & Stebila            Expires July 7, 2011                 [Page 19]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

Appendix B.  Acknowledgements

   The authors gratefully acknowledge helpful comments from Ran
   Atkinson, Samuel Edoho-Eket, Joseph Galbraith, Russ Housley, Jeffrey
   Hutzelman, Jan Pechanec, Peter Saint-Andre, Sean Turner, and Nicolas
   Williams.

   O. Saarenmaa and J. Galbraith previously prepared an Internet-Draft
   on a similar topic.

Igoe & Stebila            Expires July 7, 2011                 [Page 20]
Internet-Draft        X.509v3 Certificates for SSH          January 2011

Authors' Addresses

   Kevin M. Igoe
   National Security Agency
   NSA/CSS Commercial Solutions Center
   United States of America

   Email: kmigoe@nsa.gov

   Douglas Stebila
   Queensland University of Technology
   Information Security Institute
   Level 7, 126 Margaret St
   Brisbane, Queensland  4000
   Australia

   Email: douglas@stebila.ca

Igoe & Stebila            Expires July 7, 2011                 [Page 21]