<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc submissionType="IETF"
     docName="draft-green-tls-static-dh-in-tls13-01"
     category="std">
<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>

<front>
  <title abbrev="Data Center use of Static Diffie-Hellman">Data Center use of Static Diffie-Hellman in TLS 1.3</title>
  <author fullname="Matthew Green" initials="M." surname="Green">
    <organization>Cryptography Engineering LLC</organization>
    <address><postal><street>4506 Roland Ave</street>
    <street>Baltimore, MD  21210</street>
    <street>USA</street>
  </postal>
  <email>mgreen@cryptographyengineering.com</email>
    </address>
  </author>
  
  <author fullname="Ralph Droms" initials="R." surname="Droms">
    <organization>Interisle Consulting</organization>
    <address>
      <email>rdroms.ietf@gmail.com</email>
    </address>
  </author>

  <author fullname="Russ Housley" initials="R." surname="Housley">
    <organization>Vigil Security, LLC</organization>
    <address>
      <postal>
        <street>918 Spring Knoll Drive</street>
        <city>Herndon</city>
        <region>VA</region>
        <code>20170</code>
        <country>USA</country>
      </postal>
      <email>housley@vigilsec.com</email>
    </address>
  </author>

  <author fullname="Paul Turner" initials="P." surname="Turner">
    <organization>Venafi</organization>
    <address>
      <postal>
        <street>175 East 400 South, Suite 300</street>
        <city>Salt Lake City</city>
        <region>UT</region>
        <code>84111</code>
        <country>USA</country>
      </postal>
      <email>paul.turner@venafi.com</email>
    </address>
  </author>

  <author fullname ="Steve Fenter" initials="S." surname="Fenter">
    <organization></organization>
    <address>
      <email>steven.fenter58@gmail.com</email>
    </address>
  </author>
 
  
  <date year="2017"/>
  <abstract>

    <t> Unlike earlier versions of TLS, current drafts of TLS 1.3 have
    instead adopted ephemeral-mode Diffie-Hellman and elliptic-curve
    Diffie-Hellman as the primary cryptographic key exchange mechanism
    used in TLS. This document describes an optional configuration for
    TLS servers that allows for the use of a static Diffie-Hellman
    private key for all TLS connections made to the server. Passive
    monitoring of TLS connections can be enabled by installing a
    corresponding copy of this key in each monitoring device.</t>

  </abstract>
</front>

<middle>
  <section title="Introduction" anchor="section-1">

    <t>Unlike earlier versions of TLS, current drafts of TLS 1.3 <xref
    target="I-D.ietf-tls-tls13" /> do not provide support for the RSA
    handshake -- and have instead adopted ephemeral-mode
    Diffie-Hellman (DHE) and elliptic-curve Diffie-Hellman (ECDHE) as
    the primary cryptographic key exchange mechanism used in TLS.</t>

    <t>While ephemeral (EC) Diffie-Hellman is in nearly all ways an
    improvement over the TLS RSA handshake, the use of these
    mechanisms complicates certain enterprise settings. Specifically,
    the use of ephemeral ciphersuites is
    not compatible with current enterprise network monitoring tools
    such as Intrusion Detection Systems (IDS) and
    application monitoring systems, which leverage the current TLS RSA
    handshake passively monitor intranet TLS connections made between
    endpoints under the enterprise's control. This traffic includes
    TLS connections made from enterprise network security devices
    (firewalls) and load balancers at the edge of the enterprise
    network to internal enterprise TLS servers. It does not include
    TLS connections traveling over the external Internet.</t>

    <t>Such monitoring of the enterprise network is ubiquitous and
    indispensable in some industries. This monitoring is required for
    effective and safe operation of enterprise networks. Loss of this
    capability may slow adoption of TLS 1.3.</t>

    <t> This document describes an optional configuration for TLS
    servers that is compatible with the TLS 1.3 ephemeral ciphersuites
    without precluding enterprise network monitoring. This
    configuration allows for the use of a static (EC) Diffie-Hellman
    private key for all TLS connections made to the server. Passive
    monitoring of TLS connections can be enabled by installing a
    corresponding copy of this key in each authorized monitoring
    device.</t>

    <t>An advantage of this proposal is that it can be implemented
    using software modifications to the TLS server and enterprise
    network monitoring tools, without the need to make changes to TLS
    client implementations.</t>

    <section title="Terminology">

      <t>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 <xref target="RFC2119" />.</t>

      <t>This document introduces the term “static (elliptic curve)
      Diffie-Hellman ephemeral”, generally written as “static
      (EC)DHE”, to refer to long-lived finite field or elliptic curve
      Diffie-Hellman keys or key pairs that will be used with the TLS
      1.3 ephemeral ciphersuites to negotiate traffic keys for
      multiple TLS sessions.</t>

      <t>For clarity, this document also introduces the term
      “ephemeral (elliptic curve) Diffie-Hellman ephemeral”,
      generally written as “ephemeral (EC)DHE”, to denote finite field
      or elliptic curve Diffie-Hellman keys or key pairs that will be
      used with the TLS 1.3 ephemeral ciphersuites to negotiate
      traffic keys for a single TLS sessions.</t>
      
    </section>

    <section title="ASN.1">

      <t>The Cryptographic Message Syntax (CMS)
      <xref target="RFC5652" /> and asymmetric key packages
      <xref target="RFC5958" /> are generated using ASN.1
      <xref target="X680" />, which uses the Basic Encoding
      Rules (BER) and the Distinguished Encoding Rules (DER)
      <xref target="X690" />.</t>
 
    </section>
    
  </section>
  
  <section title="Enterprise Out-of-band TLS Decryption Architecture">
    
    <t>This document describes the use of a static (elliptic-curve)
    Diffie-Hellman (static (EC)DHE) private key by servers for use in TLS 1.3
    sessions internal to an enterprise network where network
    monitoring is required.  In <xref target="TSK-1" />, the Web
    Servers use a static (EC)DHE key pair with the standard TLS 1.3
    handshake for connections from the Load Balancer, and the Back-End
    Services use static (EC)DHE for connections from the Web Servers.
    The Load Balancer uses ephemeral (EC)DHE key pairs with the
    standard TLS 1.3 handshake for connections from external Browsers
    over the Internet, to provide Forward Secrecy on those connections
    that are exposed to third-party monitoring.  Internally, the
    static (EC)DHE keys are provided to authorized TLS Decrypter
    devices, such as intrusion detection systems, application
    monitoring systems or network packet capture devices.</t>

    <figure align="center" anchor="TSK-1"
            title="Enterprise TLS Decryption Architecture">
      <artwork align="center"><![CDATA[
                                ********************************
                               *                                *
                              *            +--------+            *
                             *   TLS       |  Web   |             *
                            * Termination  + Server +              *
                           *      |       /|        |\              *
 +---------+  +----------+ * +----|-----+/ +--------+ \+----------+ *
 |         |  |          | * |   Load   +              + Back-end | *
 | Browser +--+ Internet |-*-+ Balancer |              |  Server  | *
 |         |  |          | * |    |     +              +          | *
 +---------+  +----------+ * +----------+\ +--------+ /+----------+ *
                           *      |      .\|  Web   |/.             *
                           *            .  + Server +  .            *
                           *            .  |        |  .            *
                           *            .  +--------+  .            *
                           *            .              .            *
                           *            .   --------   .            *
                           *             . /  TLS   \ .             *
                           *              | Decrypter|              *
                            *              \        /              *
                             *              --------              *
                              *                                  *
                               *** Enterprise Network Boundary **

                                  |
 <------ Ephemeral (EC)DHE ------>|<-------- Static (EC)DHE -------->
                                  |

]]>
      </artwork>
    </figure>

  </section>
  
  <section title="Enterprise Requirements for Passive (out-of-band) TLS Decryption">
    <t>Enterprise networks based on this architecture have operational
    requirements for traffic monitoring and ex post facto analysis for
    purposes of:</t>

    <t><list style="symbols">
      <t>Application troubleshooting and performance analysis</t>
      <t>Fraud monitoring</t>
      <t>Security, including intrusion detection, malware
      detection, confidential data exfiltration and layer 7 DDoS
      protection</t>
      <t>Audit compliance</t>
      <t>Customer Experience Monitoring</t>
    </list></t>
    
    <t>Specific requirements to meet the listed operational
    requirements include:</t>

    <t><list style="symbols">
      <t>TLS decryption for network security monitoring tools
      must be done in real time with no gaps in decryption.</t>
           
      <t>The solution must be able to decrypt passively captured
      pcap traces.</t> 
      <t>The solution must scale to handle thousands of TLS
      sessions/sec.</t> 
      <t>Key material must be preserved for back-in-time analysis.
      The period for key retention depends upon local policy,
      reflecting operational, security and compliance
      requirements.</t>
      <t>Key material must be encrypted during network transit</t>
      <t>The solution must not negatively impact the enterprise
      infrastructure (servers, network, etc.)</t> 
      <t>The solution must be able to decrypt the session when a TLS
      session is reused.  This may involve the use of a TLS decryption
      appliance.</t>
      <t>The solution must be able to decrypt in a physical data
      center, in a virtual environment, and in a cloud.</t> 
    </list></t>

  </section>
  


  <section title="Summary of the Existing Diffie-Hellman Handshake"
           anchor="section-2">

    <t>In TLS 1.3, servers exchange keys using two primary modes,
    DHE and ECDHE. In a simplified view of the full
    handshake, the following steps occur:

    <list style="numbers"><?rfc subcompact="yes"?>
    <t>The client generates an ephemeral public and private key,
    and transmits the public key within a "key_share" message,
    along with a random nonce (ClientHello.random).</t>
    
    <t>The server generates an ephemeral public and private key,
    and transmits the public key within a "key_share" message,
    along with a random nonce (ServerHello.random).</t>
    
    <t>The two parties now calculate a shared (EC)DHE
    secret by combining the other party's ephemeral public key
    with their own ephemeral private key.</t>

    <t>A series of traffic and handshake keys is derived by
    combining this shared secret with various inputs from the
    handshake, including the ClientHello.random and
    ServerHello.random.</t>

    <t>Data encryption is performed using the shared secret.</t>

    <?rfc subcompact="no"?>
    </list>
    </t>
  </section>

  <section title="Using static (EC)DHE on the server"
           anchor="section-3">

    <t>The proposal embodied in this draft modifies the standard TLS
    handshake summarized above in the following ways:
    <list style="empty">

      <t>For each elliptic curve (and FF-DH parameter length)
      supported by the server, the server is provisioned with a
      static (EC)DHE private/public key pair. This key pair may be either:
      <list style="symbols">
        <t>generated at
        server installation, and rotated at periodic intervals
        appropriate for any long-term server key,</t>
        <t>generated at a central key management server and distributed (in a
        secure encrypted form) to the appropriate endpoint servers.</t>
      </list>
      </t>

      <t>All steps of the original handshake proceed as above, with the
      following modification to server behavior. Step (2) proceeds as
      follows:</t>

    </list>
    </t>
    
    <t><list style="hanging" hangIndent="4">
      <t hangText="2."> The server transmits the static public key within a "key_share"
      message, along with a random nonce (ServerHello.random).</t>

    </list>
    </t>

  </section>

  <section title="Key Representation" anchor="keyrep">

    <t>The Asymmetric Key Package [RFC5958] MUST be used to transfer
    the centrally managed Diffie-Hellman key pair.  The key package
    contains at least one Diffie-Hellman key pair.  Each
    Diffie-Hellman key pair is associated with a set of attributes,
    including the key validity period for that Diffie-Hellman key
    pair.</t>

    <t>OneAsymmetricKey is defined in Section 2 of [RFC5958].  The
    fields are used as follows:
    <list style="symbols">

      <t>version MUST be set to v2, which has an integer value of 1.</t>

      <t>privateKeyAlgorithm MUST be set to the algorithm identifier
      of the Diffie-Hellman key pair.  For convenience, some popular
      algorithm identifiers are listed in <xref target="TSK-2" />.</t>

      <t>privateKey MUST be set to the Diffie-Hellman private key
      encoded as an OCTET STRING.</t>

      <t>attributes MUST be included even though the field is
      optional.  The set of attributes MUST include the key validity
      period attribute defined in Section 15 of <xref
      target="RFC7906" />.  Other attributes MAY be included as
      well.</t>

      <t>publicKey MUST be included even though the field is optional.
      It MUST be set to the Diffie-Hellman public key, encoded as a
      BIT STRING.  This is the same BIT STRING that would be included
      in an X.509 certificate <xref target="RFC5280" /> for this public
      key.</t>
    </list></t>

    <figure align="center" anchor="TSK-2"
            title="Popular Diffie-Hellman Algorithm Identifiers">
      <artwork align="center"><![CDATA[
+-------------------------------------------------------------------+
|                                                                   |
| Finite Field Diffie-Hellman                                       |
|  object identifier: { 1 2 840 10046 2 1 }                         |
|  parameter encoding: DomainParameters, Section 2.3.3 of [RFC3279] |
|  private key encoding: INTEGER                                    |
|  public key encoding: INTEGER                                     |
|                                                                   |
| Elliptic Curve Diffie-Hellman                                     |
|  object identifier: { 1 3 132 1 12 }                              |
|  parameter encoding: ECParameters, Section 2.1.2 of [RFC5480]     |
|                         (MUST use the namedCurve CHOICE)          |
|  private key encoding: ECPrivateKey, Section 3 of [RFC5915]       |
|  public key encoding:  ECPoint, Section 2.2 of [RFC5480]          |
|                                                                   |
+-------------------------------------------------------------------+
]]>
      </artwork>
    </figure>

    <t>The CMS protecting content types <xref target="RFC5652" /><xref
    target="RFC5083" /> can be used to provide authentication and
    confidentiality protection for the Asymmetric Key Package:
    <list style="symbols">

      <t>SignedData can be used to apply a digital signature to
      the Asymmetric Key Package.</t>

      <t>EncryptedData can be used to encrypt the Asymmetric Key
      Package with previously distributed symmetric encryption
      key.</t>

      <t>EnvelopedData can be used to encrypt the Asymmetric Key
      Package, where the sender and the receiver establish a symmetric
      encryption key using Diffie-Hellman key agreement.</t>

      <t>AuthEnvelopedData can be used to protect the Asymmetric Key
      Package where the sender and the receiver establish a symmetric
      authenticated encryption key using Diffie-Hellman key
      agreement.</t>

    </list>
    </t>
            
  </section>

  <section title="TLS Static DH Key (TSK) Protocol">

    <t>The TLS Static DH Key (TSK) Protocol is used in cases where the
    Diffie-Hellman keys are centrally managed.  The two main roles in
    the TSK protocol are "key manager" and "key consumer". Key
    consumers can be TLS servers or TLS decrypters. The key manager
    generates, distributes, and tracks static (EC)DHE keys used by key
    consumers. TSK messaging is based on HTTPS <xref target="RFC2818"
    />. Keys are transferred as Asymmetric Key Packages <xref
    target="RFC5958" />, using the profile in <xref target="keyrep" />
    of this document.</t>

    <figure align="center" anchor="TSK-3"
            title="TSK protocol components">
      <artwork align="center"><![CDATA[

    --------------       -----------------
    | TLS server |-------|  key manager  |
    --------------       -----------------
           |                     |
           |                     |
           |                     |
           |             -----------------
           |------------>| TLS decrypter |
           |             -----------------
           |
           |
    --------------
    | TLS client |
    --------------
]]>
      </artwork>
    </figure>

    <t>The key manager can push keys to key consumers: </t>
    
    <figure align="center" anchor="TSK-4"
            title="TSK protocol push model">
      <artwork align="center"><![CDATA[
    TLS server               key manager             TLS decrypter
        |                         |                        |
        |                         |--                      |
        |                         |  \ Generate            |
        |                         |  / key pair            |
        |                         |<-                      |
        |                         |                        |
        |                         |----------------------->|
        |                         |      Push key pair     |
        |<------------------------|                        |
        |       Push key pair     |                        |
]]>
      </artwork>
    </figure>
    

    <t>Alternatively, key consumers can request (or pull) keys from the
    key manager. </t>
    
    <figure align="center" anchor="TSK-5"
            title="TSK protocol pull model">
      <artwork align="center"><![CDATA[
    TLS server               key manager             TLS decrypter
        |                         |                        |
        |                         |--                      |
        |                         |  \ Generate            |
        |                         |  / key pair            |
        |                         |<-                      |
        |                         |                        |
        |                         |<-----------------------|
        |                         |    Request key pair    |
        |------------------------>|                        |
        |     Request key pair    |                        |
]]>
      </artwork>
    </figure>
        
    <section title="Key Push">

      <t>An HTTPS-based TSK push is composed of the appropriate HTTP
      headers, followed by the binary value of the BER (Basic Encoding
      Rules) encoding of the Asymmetric Key Package.</t>
            
      <t>The Content-Type header MUST be application/cms
      <xref target="RFC7193" /> if the Asymmetric Key Package is
      encrypted with CMS <xref target="RFC6032" />. The Content-Type
      header MUST be application/pkcs8 if the Asymmetric Key Package
      is transferred in plain text (within the encrypted HTTPS
      stream).</t>
    </section>
          
    <section title="Key Request">

      <t>A key consumer may request a key by providing a fingerprint
      <xref target="RFC6234" /> of the public key. The key manager is
      responsible for determining if the key consumer is authorized to
      receive a copy of the key being requested.</t>

      <t>Example with plain text Asymmetric Key Package:
      <list style="empty">
        <?rfc subcompact="yes"?>      
        <t>GET /tsk/key/PublicKeyFingerprint</t>
        <t>Accept: application/pkcs8</t>
        <?rfc subcompact="no"?>
      </list>
      </t>

      <t>Example with CMS encrypted and/or signed Asymmetric Key Package:
      <list style="empty">
        <?rfc subcompact="yes"?>      
        <t>GET /tsk/key/PublicKeyFingerprint</t>
        <t>Accept: application/cms</t>
        <?rfc subcompact="no"?>
      </list>
      </t>

      <t>The response to the TSK push is composed of the appropriate
      HTTP headers, followed by the binary value of the BER (Basic
      Encoding Rules) encoding of the Asymmetric Key Package.</t>
            
      <t>The Content-Type header MUST be application/cms
      <xref target="RFC7193" /> if the Asymmetric Key Package is
      encrypted with CMS <xref target="RFC6032" />. The Content-Type
      header MUST be application/pkcs8 if the Asymmetric Key Package
      is transferred in plain text (within the encrypted HTTPS
      stream).</t>

    </section>
    
  </section>

  <section
      title="Alternative Solutions for Enterprise Monitoring and Troubleshooting">
    <t><list style="symbols">
      <t>Export of ephemeral keys</t> 
      <t>Export of decrypted traffic from TLS proxy devices at
      the edge of the enterprise network</t> 
      <t>Placement of TLS proxies in the enterprise network</t> 
      <t>Reliance on TCP/IP headers not encrypted by TLS</t> 
      <t>Reliance on application/server logs</t> 
      <t>Doing troubleshooting and malware analysis at the
      endpoint.</t> 
      <t>Adding a TCP or UDP extension to provide the
      information needed to do packet analysis.</t> 
    </list></t>
    
  </section>
  
  <section title="Weaknesses of Alternative Solutions">
    
    <t><list style="hanging" hangIndent="6">
      <t hangText="Export of ephemeral keys:">
        Scale – In a large enterprise there will be billions of
        ephemeral keys to export and manage.  There will also be
        difficulty in transporting these keys to real time tools that
        need decrypted packets.  The complexity of the solution is a
        problem that adds risk.</t>
      <t hangText="Export of decrypted traffic from TLS proxy devices:">
        Decrypted traffic at only the edge of the network is not
        adequate for the enterprise requirements listed above
        (troubleshooting, network security monitoring, etc…)</t>
      <t hangText="TLS proxies in the network:">
        Inline TLS proxies will not scale to the number of decryption
        points needed within an enterprise.  Each inline proxy adds
        cost, latency, and production risk.</t>
      <t hangText="Reliance on TCP/IP headers:">
        IP and/or TCP headers are not adequate for the enterprise
        requirements listed above.  Troubleshooters must be able to
        find transactions in a pcap trace, identified by markers like
        userids, session ids, URLs, and time stamps.  Threat Detection
        teams must be able to look for Indicators of Compromise in the
        payload of packets, etc.</t>
      <t hangText="Reliance on Application/server logs:">
        Logging is not adequate for the enterprise requirements
        listed above.  Code developers cannot anticipate every
        possible problem and put a log message in just the right
        place.  There are billions of lines of code in a data
        center, and it’s not scalable to try and improve
        logging.</t> 
      <t hangText="Troubleshooting and malware analysis at the endpoint:">
        Endpoints don’t have the robustness to do their own workload
        and handle the burden of the various enterprise requirements
        listed above.  These requirements would include always-on full
        packet capture at the endpoint with no packet drops.</t>
      <t hangText="Adding TCP/UDP extensions:">
        An important part of troubleshooting, network security
        monitoring, etc. is analysis of the application-specific
        payload of the packet.  It is not possible to anticipate ahead
        of time, among thousands of unique applications, which fields
        in the application payload will be important.</t>
    </list></t>

  </section>
        
  <section title="Security considerations" anchor="section-4">
    <t>We now consider the security implications of the change
    described above:</t>

    <t><list style="numbers">
      <t>The shift from fully-ephemeral (EC)HDE to static
      (EC)DHE affects the security properties offered by the TLS 1.3
      handshake by eliminating the Forward Secrecy property provided
      by the server. If a server is compromised and the private key is
      stolen, then an attacker who observes any TLS handshake (even
      one that occurred prior to the compromise) performed with this
      static (EC)DHE key pair will be able to recover session traffic
      encryption keys and will be able to decrypt traffic.</t>

      <t>As long as the server static secret key is not compromised, the
        resulting protocol will provide strong cryptographic security, as
      long as the Diffie-Hellman parameters (e.g., finite-field group or
      elliptic curve) are correctly generated and provide security at a
      sufficient cryptographic security level.
      </t>

<!--
          <t>Replay attacks are prevented due to the fact that the server
      generates a unique 32-byte ServerHello.random field using a strong
      random number generator, and this value is included in the traffic
      key derivation procedure.
      </t>
-->

      <t>A flaw in the generation of finite-field Diffie-Hellman
        parameters or the use of an insecure implementation could leak
      some bits of the static secret key over time. This risk is not
      present in ephemeral DH implementations. Implementers should use
      care to avoid such pitfalls.
      </t>

    </list>
    </t>

    <t>Thus the modification described in <xref target="section-4"/>
    represents a deliberate weakening of some security
    properties. Implementers who choose to include this capability
    should carefully consider the risks to their infrastructure of
    using a handshake without Forward Secrecy. Static (EC)DHE key pairs
    should be rotated regularly.</t>

  </section>

  <section title="IANA Considerations" anchor="section-5"><t>
    This document contains no actions for IANA.</t>

  </section>

  <section title="Acknowledgements" anchor="section-6"><t>
    This modification to TLS was initially suggested by Hugo Krawczyk.</t>

  </section>

</middle>

<back>
  <references title="Normative References">

    <?rfc include="reference.RFC.2119" ?>
    <?rfc include="reference.RFC.2818" ?>
    <?rfc include="reference.RFC.3279" ?>
    <?rfc include="reference.RFC.5083" ?>
    <?rfc include="reference.RFC.5280" ?>
    <?rfc include="reference.RFC.5480" ?>
    <?rfc include="reference.RFC.5915" ?>
    <?rfc include="reference.RFC.5652" ?>
    <?rfc include="reference.RFC.5958" ?>
    <?rfc include="reference.RFC.6032" ?>
    <?rfc include="reference.RFC.6234" ?>
    <?rfc include="reference.RFC.7193" ?>
    <?rfc include="reference.RFC.7906" ?>
    <?rfc include="reference.I-D.ietf-tls-tls13" ?>
    <?rfc include="reference.CCITT.X680.2002 ?>
    <?rfc include="reference.CCITT.X690.2002 ?>

    <reference anchor="X680">
      <front>
        <title>Information technology -- Abstract Syntax Notation
             One (ASN.1): Specification of basic notation</title>
        <author>
          <organization>ITU-T</organization>
        </author>
        <date year="2015" />
      </front>

      <seriesInfo name="ITU-T" value="Recommendation X.680" />

    </reference>


    <reference anchor="X690">
      <front>
        <title>Information technology -- ASN.1 encoding rules:
             Specification of Basic Encoding Rules (BER), Canonical
             Encoding Rules (CER) and Distinguished Encoding Rules
             (DER)</title>
        <author>
          <organization>ITU-T</organization>
        </author>
        <date year="2015" />
      </front>

      <seriesInfo name="ITU-T" value="Recommendation X.690" />

    </reference>

  </references>

</back>

</rfc>
        
