idnits 2.17.1 draft-green-tls-static-dh-in-tls13-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2489 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-20 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 5915 ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Downref: Normative reference to an Informational RFC: RFC 7193 ** Downref: Normative reference to an Informational RFC: RFC 7906 -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Green 3 Internet-Draft Cryptography Engineering LLC 4 Intended status: Standards Track R. Droms 5 Expires: January 4, 2018 Interisle Consulting 6 R. Housley 7 Vigil Security, LLC 8 P. Turner 9 Venafi 10 S. Fenter 11 July 3, 2017 13 Data Center use of Static Diffie-Hellman in TLS 1.3 14 draft-green-tls-static-dh-in-tls13-01 16 Abstract 18 Unlike earlier versions of TLS, current drafts of TLS 1.3 have 19 instead adopted ephemeral-mode Diffie-Hellman and elliptic-curve 20 Diffie-Hellman as the primary cryptographic key exchange mechanism 21 used in TLS. This document describes an optional configuration for 22 TLS servers that allows for the use of a static Diffie-Hellman 23 private key for all TLS connections made to the server. Passive 24 monitoring of TLS connections can be enabled by installing a 25 corresponding copy of this key in each monitoring device. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 4, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Enterprise Out-of-band TLS Decryption Architecture . . . . . 4 65 3. Enterprise Requirements for Passive (out-of-band) TLS 66 Decryption . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Summary of the Existing Diffie-Hellman Handshake . . . . . . 6 68 5. Using static (EC)DHE on the server . . . . . . . . . . . . . 7 69 6. Key Representation . . . . . . . . . . . . . . . . . . . . . 7 70 7. TLS Static DH Key (TSK) Protocol . . . . . . . . . . . . . . 8 71 7.1. Key Push . . . . . . . . . . . . . . . . . . . . . . . . 10 72 7.2. Key Request . . . . . . . . . . . . . . . . . . . . . . . 10 73 8. Alternative Solutions for Enterprise Monitoring and 74 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . 11 75 9. Weaknesses of Alternative Solutions . . . . . . . . . . . . . 11 76 10. Security considerations . . . . . . . . . . . . . . . . . . . 12 77 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 79 13. Normative References . . . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 Unlike earlier versions of TLS, current drafts of TLS 1.3 85 [I-D.ietf-tls-tls13] do not provide support for the RSA handshake -- 86 and have instead adopted ephemeral-mode Diffie-Hellman (DHE) and 87 elliptic-curve Diffie-Hellman (ECDHE) as the primary cryptographic 88 key exchange mechanism used in TLS. 90 While ephemeral (EC) Diffie-Hellman is in nearly all ways an 91 improvement over the TLS RSA handshake, the use of these mechanisms 92 complicates certain enterprise settings. Specifically, the use of 93 ephemeral ciphersuites is not compatible with current enterprise 94 network monitoring tools such as Intrusion Detection Systems (IDS) 95 and application monitoring systems, which leverage the current TLS 96 RSA handshake passively monitor intranet TLS connections made between 97 endpoints under the enterprise's control. This traffic includes TLS 98 connections made from enterprise network security devices (firewalls) 99 and load balancers at the edge of the enterprise network to internal 100 enterprise TLS servers. It does not include TLS connections 101 traveling over the external Internet. 103 Such monitoring of the enterprise network is ubiquitous and 104 indispensable in some industries. This monitoring is required for 105 effective and safe operation of enterprise networks. Loss of this 106 capability may slow adoption of TLS 1.3. 108 This document describes an optional configuration for TLS servers 109 that is compatible with the TLS 1.3 ephemeral ciphersuites without 110 precluding enterprise network monitoring. This configuration allows 111 for the use of a static (EC) Diffie-Hellman private key for all TLS 112 connections made to the server. Passive monitoring of TLS 113 connections can be enabled by installing a corresponding copy of this 114 key in each authorized monitoring device. 116 An advantage of this proposal is that it can be implemented using 117 software modifications to the TLS server and enterprise network 118 monitoring tools, without the need to make changes to TLS client 119 implementations. 121 1.1. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 This document introduces the term "static (elliptic curve) Diffie- 128 Hellman ephemeral", generally written as "static (EC)DHE", to refer 129 to long-lived finite field or elliptic curve Diffie-Hellman keys or 130 key pairs that will be used with the TLS 1.3 ephemeral ciphersuites 131 to negotiate traffic keys for multiple TLS sessions. 133 For clarity, this document also introduces the term "ephemeral 134 (elliptic curve) Diffie-Hellman ephemeral", generally written as 135 "ephemeral (EC)DHE", to denote finite field or elliptic curve Diffie- 136 Hellman keys or key pairs that will be used with the TLS 1.3 137 ephemeral ciphersuites to negotiate traffic keys for a single TLS 138 sessions. 140 1.2. ASN.1 142 The Cryptographic Message Syntax (CMS) [RFC5652] and asymmetric key 143 packages [RFC5958] are generated using ASN.1 [X680], which uses the 144 Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 145 [X690]. 147 2. Enterprise Out-of-band TLS Decryption Architecture 149 This document describes the use of a static (elliptic-curve) Diffie- 150 Hellman (static (EC)DHE) private key by servers for use in TLS 1.3 151 sessions internal to an enterprise network where network monitoring 152 is required. In Figure 1, the Web Servers use a static (EC)DHE key 153 pair with the standard TLS 1.3 handshake for connections from the 154 Load Balancer, and the Back-End Services use static (EC)DHE for 155 connections from the Web Servers. The Load Balancer uses ephemeral 156 (EC)DHE key pairs with the standard TLS 1.3 handshake for connections 157 from external Browsers over the Internet, to provide Forward Secrecy 158 on those connections that are exposed to third-party monitoring. 159 Internally, the static (EC)DHE keys are provided to authorized TLS 160 Decrypter devices, such as intrusion detection systems, application 161 monitoring systems or network packet capture devices. 163 ******************************** 164 * * 165 * +--------+ * 166 * TLS | Web | * 167 * Termination + Server + * 168 * | /| |\ * 169 +---------+ +----------+ * +----|-----+/ +--------+ \+----------+ * 170 | | | | * | Load + + Back-end | * 171 | Browser +--+ Internet |-*-+ Balancer | | Server | * 172 | | | | * | | + + | * 173 +---------+ +----------+ * +----------+\ +--------+ /+----------+ * 174 * | .\| Web |/. * 175 * . + Server + . * 176 * . | | . * 177 * . +--------+ . * 178 * . . * 179 * . -------- . * 180 * . / TLS \ . * 181 * | Decrypter| * 182 * \ / * 183 * -------- * 184 * * 185 *** Enterprise Network Boundary ** 187 | 188 <------ Ephemeral (EC)DHE ------>|<-------- Static (EC)DHE --------> 189 | 191 Figure 1: Enterprise TLS Decryption Architecture 193 3. Enterprise Requirements for Passive (out-of-band) TLS Decryption 195 Enterprise networks based on this architecture have operational 196 requirements for traffic monitoring and ex post facto analysis for 197 purposes of: 199 o Application troubleshooting and performance analysis 201 o Fraud monitoring 203 o Security, including intrusion detection, malware detection, 204 confidential data exfiltration and layer 7 DDoS protection 206 o Audit compliance 208 o Customer Experience Monitoring 209 Specific requirements to meet the listed operational requirements 210 include: 212 o TLS decryption for network security monitoring tools must be done 213 in real time with no gaps in decryption. 215 o The solution must be able to decrypt passively captured pcap 216 traces. 218 o The solution must scale to handle thousands of TLS sessions/sec. 220 o Key material must be preserved for back-in-time analysis. The 221 period for key retention depends upon local policy, reflecting 222 operational, security and compliance requirements. 224 o Key material must be encrypted during network transit 226 o The solution must not negatively impact the enterprise 227 infrastructure (servers, network, etc.) 229 o The solution must be able to decrypt the session when a TLS 230 session is reused. This may involve the use of a TLS decryption 231 appliance. 233 o The solution must be able to decrypt in a physical data center, in 234 a virtual environment, and in a cloud. 236 4. Summary of the Existing Diffie-Hellman Handshake 238 In TLS 1.3, servers exchange keys using two primary modes, DHE and 239 ECDHE. In a simplified view of the full handshake, the following 240 steps occur: 242 1. The client generates an ephemeral public and private key, and 243 transmits the public key within a "key_share" message, along with 244 a random nonce (ClientHello.random). 245 2. The server generates an ephemeral public and private key, and 246 transmits the public key within a "key_share" message, along with 247 a random nonce (ServerHello.random). 248 3. The two parties now calculate a shared (EC)DHE secret by 249 combining the other party's ephemeral public key with their own 250 ephemeral private key. 251 4. A series of traffic and handshake keys is derived by combining 252 this shared secret with various inputs from the handshake, 253 including the ClientHello.random and ServerHello.random. 254 5. Data encryption is performed using the shared secret. 256 5. Using static (EC)DHE on the server 258 The proposal embodied in this draft modifies the standard TLS 259 handshake summarized above in the following ways: 261 For each elliptic curve (and FF-DH parameter length) supported by 262 the server, the server is provisioned with a static (EC)DHE 263 private/public key pair. This key pair may be either: 265 * generated at server installation, and rotated at periodic 266 intervals appropriate for any long-term server key, 268 * generated at a central key management server and distributed 269 (in a secure encrypted form) to the appropriate endpoint 270 servers. 272 All steps of the original handshake proceed as above, with the 273 following modification to server behavior. Step (2) proceeds as 274 follows: 276 2. The server transmits the static public key within a "key_share" 277 message, along with a random nonce (ServerHello.random). 279 6. Key Representation 281 The Asymmetric Key Package [RFC5958] MUST be used to transfer the 282 centrally managed Diffie-Hellman key pair. The key package contains 283 at least one Diffie-Hellman key pair. Each Diffie-Hellman key pair 284 is associated with a set of attributes, including the key validity 285 period for that Diffie-Hellman key pair. 287 OneAsymmetricKey is defined in Section 2 of [RFC5958]. The fields 288 are used as follows: 290 o version MUST be set to v2, which has an integer value of 1. 292 o privateKeyAlgorithm MUST be set to the algorithm identifier of the 293 Diffie-Hellman key pair. For convenience, some popular algorithm 294 identifiers are listed in Figure 2. 296 o privateKey MUST be set to the Diffie-Hellman private key encoded 297 as an OCTET STRING. 299 o attributes MUST be included even though the field is optional. 300 The set of attributes MUST include the key validity period 301 attribute defined in Section 15 of [RFC7906]. Other attributes 302 MAY be included as well. 304 o publicKey MUST be included even though the field is optional. It 305 MUST be set to the Diffie-Hellman public key, encoded as a BIT 306 STRING. This is the same BIT STRING that would be included in an 307 X.509 certificate [RFC5280] for this public key. 309 +-------------------------------------------------------------------+ 310 | | 311 | Finite Field Diffie-Hellman | 312 | object identifier: { 1 2 840 10046 2 1 } | 313 | parameter encoding: DomainParameters, Section 2.3.3 of [RFC3279] | 314 | private key encoding: INTEGER | 315 | public key encoding: INTEGER | 316 | | 317 | Elliptic Curve Diffie-Hellman | 318 | object identifier: { 1 3 132 1 12 } | 319 | parameter encoding: ECParameters, Section 2.1.2 of [RFC5480] | 320 | (MUST use the namedCurve CHOICE) | 321 | private key encoding: ECPrivateKey, Section 3 of [RFC5915] | 322 | public key encoding: ECPoint, Section 2.2 of [RFC5480] | 323 | | 324 +-------------------------------------------------------------------+ 326 Figure 2: Popular Diffie-Hellman Algorithm Identifiers 328 The CMS protecting content types [RFC5652][RFC5083] can be used to 329 provide authentication and confidentiality protection for the 330 Asymmetric Key Package: 332 o SignedData can be used to apply a digital signature to the 333 Asymmetric Key Package. 335 o EncryptedData can be used to encrypt the Asymmetric Key Package 336 with previously distributed symmetric encryption key. 338 o EnvelopedData can be used to encrypt the Asymmetric Key Package, 339 where the sender and the receiver establish a symmetric encryption 340 key using Diffie-Hellman key agreement. 342 o AuthEnvelopedData can be used to protect the Asymmetric Key 343 Package where the sender and the receiver establish a symmetric 344 authenticated encryption key using Diffie-Hellman key agreement. 346 7. TLS Static DH Key (TSK) Protocol 348 The TLS Static DH Key (TSK) Protocol is used in cases where the 349 Diffie-Hellman keys are centrally managed. The two main roles in the 350 TSK protocol are "key manager" and "key consumer". Key consumers can 351 be TLS servers or TLS decrypters. The key manager generates, 352 distributes, and tracks static (EC)DHE keys used by key consumers. 353 TSK messaging is based on HTTPS [RFC2818]. Keys are transferred as 354 Asymmetric Key Packages [RFC5958], using the profile in Section 6 of 355 this document. 357 -------------- ----------------- 358 | TLS server |-------| key manager | 359 -------------- ----------------- 360 | | 361 | | 362 | | 363 | ----------------- 364 |------------>| TLS decrypter | 365 | ----------------- 366 | 367 | 368 -------------- 369 | TLS client | 370 -------------- 372 Figure 3: TSK protocol components 374 The key manager can push keys to key consumers: 376 TLS server key manager TLS decrypter 377 | | | 378 | |-- | 379 | | \ Generate | 380 | | / key pair | 381 | |<- | 382 | | | 383 | |----------------------->| 384 | | Push key pair | 385 |<------------------------| | 386 | Push key pair | | 388 Figure 4: TSK protocol push model 390 Alternatively, key consumers can request (or pull) keys from the key 391 manager. 393 TLS server key manager TLS decrypter 394 | | | 395 | |-- | 396 | | \ Generate | 397 | | / key pair | 398 | |<- | 399 | | | 400 | |<-----------------------| 401 | | Request key pair | 402 |------------------------>| | 403 | Request key pair | | 405 Figure 5: TSK protocol pull model 407 7.1. Key Push 409 An HTTPS-based TSK push is composed of the appropriate HTTP headers, 410 followed by the binary value of the BER (Basic Encoding Rules) 411 encoding of the Asymmetric Key Package. 413 The Content-Type header MUST be application/cms [RFC7193] if the 414 Asymmetric Key Package is encrypted with CMS [RFC6032]. The Content- 415 Type header MUST be application/pkcs8 if the Asymmetric Key Package 416 is transferred in plain text (within the encrypted HTTPS stream). 418 7.2. Key Request 420 A key consumer may request a key by providing a fingerprint [RFC6234] 421 of the public key. The key manager is responsible for determining if 422 the key consumer is authorized to receive a copy of the key being 423 requested. 425 Example with plain text Asymmetric Key Package: 427 GET /tsk/key/PublicKeyFingerprint 428 Accept: application/pkcs8 430 Example with CMS encrypted and/or signed Asymmetric Key Package: 432 GET /tsk/key/PublicKeyFingerprint 433 Accept: application/cms 435 The response to the TSK push is composed of the appropriate HTTP 436 headers, followed by the binary value of the BER (Basic Encoding 437 Rules) encoding of the Asymmetric Key Package. 439 The Content-Type header MUST be application/cms [RFC7193] if the 440 Asymmetric Key Package is encrypted with CMS [RFC6032]. The Content- 441 Type header MUST be application/pkcs8 if the Asymmetric Key Package 442 is transferred in plain text (within the encrypted HTTPS stream). 444 8. Alternative Solutions for Enterprise Monitoring and Troubleshooting 446 o Export of ephemeral keys 448 o Export of decrypted traffic from TLS proxy devices at the edge of 449 the enterprise network 451 o Placement of TLS proxies in the enterprise network 453 o Reliance on TCP/IP headers not encrypted by TLS 455 o Reliance on application/server logs 457 o Doing troubleshooting and malware analysis at the endpoint. 459 o Adding a TCP or UDP extension to provide the information needed to 460 do packet analysis. 462 9. Weaknesses of Alternative Solutions 464 Export of ephemeral keys: Scale - In a large enterprise there will 465 be billions of ephemeral keys to export and manage. There will 466 also be difficulty in transporting these keys to real time 467 tools that need decrypted packets. The complexity of the 468 solution is a problem that adds risk. 470 Export of decrypted traffic from TLS proxy devices: Decrypted 471 traffic at only the edge of the network is not adequate for the 472 enterprise requirements listed above (troubleshooting, network 473 security monitoring, etc...) 475 TLS proxies in the network: Inline TLS proxies will not scale to the 476 number of decryption points needed within an enterprise. Each 477 inline proxy adds cost, latency, and production risk. 479 Reliance on TCP/IP headers: IP and/or TCP headers are not adequate 480 for the enterprise requirements listed above. Troubleshooters 481 must be able to find transactions in a pcap trace, identified 482 by markers like userids, session ids, URLs, and time stamps. 483 Threat Detection teams must be able to look for Indicators of 484 Compromise in the payload of packets, etc. 486 Reliance on Application/server logs: Logging is not adequate for the 487 enterprise requirements listed above. Code developers cannot 488 anticipate every possible problem and put a log message in just 489 the right place. There are billions of lines of code in a data 490 center, and it's not scalable to try and improve logging. 492 Troubleshooting and malware analysis at the endpoint: Endpoints 493 don't have the robustness to do their own workload and handle 494 the burden of the various enterprise requirements listed above. 495 These requirements would include always-on full packet capture 496 at the endpoint with no packet drops. 498 Adding TCP/UDP extensions: An important part of troubleshooting, 499 network security monitoring, etc. is analysis of the 500 application-specific payload of the packet. It is not possible 501 to anticipate ahead of time, among thousands of unique 502 applications, which fields in the application payload will be 503 important. 505 10. Security considerations 507 We now consider the security implications of the change described 508 above: 510 1. The shift from fully-ephemeral (EC)HDE to static (EC)DHE affects 511 the security properties offered by the TLS 1.3 handshake by 512 eliminating the Forward Secrecy property provided by the server. 513 If a server is compromised and the private key is stolen, then an 514 attacker who observes any TLS handshake (even one that occurred 515 prior to the compromise) performed with this static (EC)DHE key 516 pair will be able to recover session traffic encryption keys and 517 will be able to decrypt traffic. 519 2. As long as the server static secret key is not compromised, the 520 resulting protocol will provide strong cryptographic security, as 521 long as the Diffie-Hellman parameters (e.g., finite-field group 522 or elliptic curve) are correctly generated and provide security 523 at a sufficient cryptographic security level. 525 3. A flaw in the generation of finite-field Diffie-Hellman 526 parameters or the use of an insecure implementation could leak 527 some bits of the static secret key over time. This risk is not 528 present in ephemeral DH implementations. Implementers should use 529 care to avoid such pitfalls. 531 Thus the modification described in Section 10 represents a deliberate 532 weakening of some security properties. Implementers who choose to 533 include this capability should carefully consider the risks to their 534 infrastructure of using a handshake without Forward Secrecy. Static 535 (EC)DHE key pairs should be rotated regularly. 537 11. IANA Considerations 539 This document contains no actions for IANA. 541 12. Acknowledgements 543 This modification to TLS was initially suggested by Hugo Krawczyk. 545 13. Normative References 547 [I-D.ietf-tls-tls13] 548 Rescorla, E., "The Transport Layer Security (TLS) Protocol 549 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 550 April 2017. 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, 554 DOI 10.17487/RFC2119, March 1997, 555 . 557 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 558 DOI 10.17487/RFC2818, May 2000, 559 . 561 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 562 Identifiers for the Internet X.509 Public Key 563 Infrastructure Certificate and Certificate Revocation List 564 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 565 2002, . 567 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 568 Authenticated-Enveloped-Data Content Type", RFC 5083, 569 DOI 10.17487/RFC5083, November 2007, 570 . 572 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 573 Housley, R., and W. Polk, "Internet X.509 Public Key 574 Infrastructure Certificate and Certificate Revocation List 575 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 576 . 578 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 579 "Elliptic Curve Cryptography Subject Public Key 580 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 581 . 583 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 584 RFC 5652, DOI 10.17487/RFC5652, September 2009, 585 . 587 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 588 Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, 589 . 591 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 592 DOI 10.17487/RFC5958, August 2010, 593 . 595 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 596 (CMS) Encrypted Key Package Content Type", RFC 6032, 597 DOI 10.17487/RFC6032, December 2010, 598 . 600 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 601 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 602 DOI 10.17487/RFC6234, May 2011, 603 . 605 [RFC7193] Turner, S., Housley, R., and J. Schaad, "The application/ 606 cms Media Type", RFC 7193, DOI 10.17487/RFC7193, April 607 2014, . 609 [RFC7906] Timmel, P., Housley, R., and S. Turner, "NSA's 610 Cryptographic Message Syntax (CMS) Key Management 611 Attributes", RFC 7906, DOI 10.17487/RFC7906, June 2016, 612 . 614 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 615 One (ASN.1): Specification of basic notation", 616 ITU-T Recommendation X.680, 2015. 618 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 619 Specification of Basic Encoding Rules (BER), Canonical 620 Encoding Rules (CER) and Distinguished Encoding Rules 621 (DER)", ITU-T Recommendation X.690, 2015. 623 Authors' Addresses 624 Matthew Green 625 Cryptography Engineering LLC 626 4506 Roland Ave 627 Baltimore, MD 21210 628 USA 630 Email: mgreen@cryptographyengineering.com 632 Ralph Droms 633 Interisle Consulting 635 Email: rdroms.ietf@gmail.com 637 Russ Housley 638 Vigil Security, LLC 639 918 Spring Knoll Drive 640 Herndon, VA 20170 641 USA 643 Email: housley@vigilsec.com 645 Paul Turner 646 Venafi 647 175 East 400 South, Suite 300 648 Salt Lake City, UT 84111 649 USA 651 Email: paul.turner@venafi.com 653 Steve Fenter 655 Email: steven.fenter58@gmail.com