idnits 2.17.1 draft-hallambaker-lurk-02.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 == Line 813 has weird spacing: '...bugging and l...' == Line 861 has weird spacing: '...support certa...' -- The document date (April 4, 2016) is 2943 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 156, but not defined == Missing Reference: 'None' is mentioned on line 1078, but not defined -- Looks like a reference, but probably isn't: '201' on line 821 -- Looks like a reference, but probably isn't: '303' on line 836 -- Looks like a reference, but probably isn't: '307' on line 840 -- Looks like a reference, but probably isn't: '401' on line 850 -- Looks like a reference, but probably isn't: '404' on line 854 -- Looks like a reference, but probably isn't: '406' on line 858 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Informational April 4, 2016 5 Expires: October 6, 2016 7 Limited Use of Remote Keys, Protocol and Reference. 8 draft-hallambaker-lurk-02 10 Abstract 12 The Limited Use of Remote Keys (LURK) BOF has been scheduled with the 13 objective of discussing approaches to mitigating security risks to 14 TLS private keys. In particular in situations where a Content 15 Delivery Network (CDN) is used to deliver content and thus the party 16 that is being authenticated is not the party that the user is 17 attempting to authenticate. 19 Three classes of solution are considered, short term credentials, a 20 remote service offering to perform private key operations and a 21 remote service that is further constrained through the use of some 22 form of threshold approach. A JSON/HTTP protocol implementing the 23 second and third protocol is demonstrated and documented. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 6, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 1.2. Related Specifications . . . . . . . . . . . . . . . . . 4 62 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Limited Life Credentials . . . . . . . . . . . . . . . . 7 65 2.2. Private Key Service . . . . . . . . . . . . . . . . . . . 8 66 2.3. Partial Key Service . . . . . . . . . . . . . . . . . . . 9 67 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 68 3.1. Establishing Trust Relationships . . . . . . . . . . . . 10 69 3.1.1. Manual Administration . . . . . . . . . . . . . . . . 10 70 3.1.2. Using the Mathematical Mesh . . . . . . . . . . . . . 10 71 3.2. Service Connection . . . . . . . . . . . . . . . . . . . 11 72 3.3. Creation of necessary key pairs . . . . . . . . . . . . . 12 73 3.4. Private key decryption . . . . . . . . . . . . . . . . . 14 74 3.5. Private key Agreement . . . . . . . . . . . . . . . . . . 15 75 3.6. Private key signature . . . . . . . . . . . . . . . . . . 15 76 3.7. Key Disposal . . . . . . . . . . . . . . . . . . . . . . 16 77 4. Lurk Key Service Reference . . . . . . . . . . . . . . . . . 16 78 4.1. Request Messages . . . . . . . . . . . . . . . . . . . . 17 79 4.1.1. Message: LurkRequest . . . . . . . . . . . . . . . . 17 80 4.1.2. Message: LurkKeyRequest . . . . . . . . . . . . . . . 17 81 4.1.3. Message: LurkResponse . . . . . . . . . . . . . . . . 17 82 4.1.4. Successful Response Codes . . . . . . . . . . . . . . 18 83 4.1.5. Warning Response Codes . . . . . . . . . . . . . . . 18 84 4.1.6. Error Response Codes . . . . . . . . . . . . . . . . 19 85 4.1.7. Structure: Version . . . . . . . . . . . . . . . . . 19 86 4.1.8. Structure: Encoding . . . . . . . . . . . . . . . . . 20 87 4.1.9. Structure: KeyParameters . . . . . . . . . . . . . . 20 88 4.1.10. Structure: ParametersRSA . . . . . . . . . . . . . . 21 89 4.1.11. Structure: ParametersDH . . . . . . . . . . . . . . . 21 90 4.1.12. Structure: ParametersECDH . . . . . . . . . . . . . . 22 91 4.2. Transaction: Hello . . . . . . . . . . . . . . . . . . . 22 92 4.2.1. Message: HelloRequest . . . . . . . . . . . . . . . . 23 93 4.2.2. Message: HelloResponse . . . . . . . . . . . . . . . 23 94 4.3. Transaction: Create . . . . . . . . . . . . . . . . . . . 23 95 4.3.1. Message: CreateRequest . . . . . . . . . . . . . . . 23 96 4.3.2. Message: CreateResponse . . . . . . . . . . . . . . . 24 98 4.4. Transaction: Dispose . . . . . . . . . . . . . . . . . . 24 99 4.4.1. Message: DisposeRequest . . . . . . . . . . . . . . . 24 100 4.4.2. Message: DisposeResponse . . . . . . . . . . . . . . 24 101 4.5. Transaction: Sign . . . . . . . . . . . . . . . . . . . . 25 102 4.5.1. Message: SignRequest . . . . . . . . . . . . . . . . 25 103 4.5.2. Message: SignResponse . . . . . . . . . . . . . . . . 25 104 4.6. Transaction: Agree . . . . . . . . . . . . . . . . . . . 26 105 4.6.1. Message: AgreeRequest . . . . . . . . . . . . . . . . 26 106 4.6.2. Message: AgreeResponse . . . . . . . . . . . . . . . 26 107 4.7. Transaction: Decrypt . . . . . . . . . . . . . . . . . . 27 108 4.7.1. Message: DecryptRequest . . . . . . . . . . . . . . . 27 109 4.7.2. Message: DecryptResponse . . . . . . . . . . . . . . 28 110 5. Advanced Functions . . . . . . . . . . . . . . . . . . . . . 28 111 5.1. Co-operative Key Generation . . . . . . . . . . . . . . . 29 112 5.2. Threshold and Proxy Re-Encryption Schemes . . . . . . . . 29 113 6. Algorithms and Identifiers . . . . . . . . . . . . . . . . . 29 114 6.1. Key Algorithms . . . . . . . . . . . . . . . . . . . . . 30 115 6.1.1. Parameters RSA . . . . . . . . . . . . . . . . . . . 30 116 6.1.2. Parameters DH . . . . . . . . . . . . . . . . . . . . 30 117 6.1.3. Parameters ECDH . . . . . . . . . . . . . . . . . . . 30 118 6.2. Key Use Restrictions . . . . . . . . . . . . . . . . . . 30 119 6.2.1. RSALG Erb-Saltz . . . . . . . . . . . . . . . . . . . 30 120 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 121 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 30 122 8.1. Reference Implementation . . . . . . . . . . . . . . . . 31 123 8.1.1. Coverage: . . . . . . . . . . . . . . . . . . . . . . 31 124 8.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 32 125 8.1.3. Implementation Experience . . . . . . . . . . . . . . 32 126 8.1.4. Contact Info . . . . . . . . . . . . . . . . . . . . 32 127 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 128 9.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 32 129 9.1.1. Disclosure of Private Key . . . . . . . . . . . . . . 32 130 9.1.2. Side Channel Disclosure . . . . . . . . . . . . . . . 32 131 9.1.3. Targeted Side Channel Disclosure . . . . . . . . . . 33 132 9.1.4. Traffic Analysis . . . . . . . . . . . . . . . . . . 33 133 9.1.5. Metadata Leakage . . . . . . . . . . . . . . . . . . 33 134 9.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 33 135 9.2.1. Unauthorized Use of Private Key . . . . . . . . . . . 33 136 9.3. Availability . . . . . . . . . . . . . . . . . . . . . . 33 137 9.3.1. Cached data . . . . . . . . . . . . . . . . . . . . . 33 138 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 139 11. Appendix: TLS Schema . . . . . . . . . . . . . . . . . . . . 34 140 12. Appendix: JSON-C Tag Dictionary . . . . . . . . . . . . . . . 34 141 13. Appendix: Mesh Application Profile . . . . . . . . . . . . . 34 142 14. Normative References . . . . . . . . . . . . . . . . . . . . 34 143 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 145 1. Definitions 147 [Please note that due to work in progress to support the new RFC 148 format etc, some of the formatting features are not currently working 149 as they should. These will be fixed in the next version.] 151 1.1. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 1.2. Related Specifications 159 This protocol is makes use of technology described in the following 160 specifications 162 JSON [RFC7159] 164 For encoding of message data structures. 166 JOSE [RFC7515] [RFC7516] [RFC7518] 168 Formats for cryptographic messages and keys in JSON. 170 JSON Web Service [draft-hallambaker-json-web-service-02] 172 Describes the approach used for Web Service discovery and the 173 encapsulation of JSON messages as HTTP payloads with the necessary 174 authentication and encryption services. 176 Uniform Data Fingerprint [draft-hallambaker-udf-03] 178 Describes the mechanism used to create identifiers for cryptographic 179 keypairs from the public key. 181 In addition, the following specifications are closely related but not 182 required for implementation: 184 Transport Layer Security [RFC5246] 186 The use of TLS to protect the confidentiality and integrity of all 187 protocol communications is of course highly recommended. It is 188 however highly undesirable for a cryptographic protocol such as LURK 189 should rely on transport layer security enhancements alone. 191 The Mathematical Mesh [draft-hallambaker-mesh-architecture-01] 192 [draft-hallambaker-mesh-reference-02] 193 MAY be used to establish trust relationships between the parties in 194 the protocol. 196 CFRG Elliptic Curves and Algorithms [RFC7748] 198 The threshold and proxy re-encryption schemes described are likely to 199 be of most interest in conjunction with the emerging elliptic curve 200 based cryptography. 202 JSON-BCD [draft-hallambaker-jsonbcd-05] 204 JSON-B or JSON-C encoding may be used if an efficient binary or 205 compressed encoding is required. Alternatively, message structures 206 MAY be encoded according to TLS conventions. 208 One piece of technology that is not currently implemented but would 209 be usefully factored out as a separate document is a mechanism to 210 support agreement of symmetric keys and related tickets for use in 211 the payload authentication mechanism. 213 1.3. Terminology 215 The following words and phrases are used as defined terms in this 216 specification: 218 Private Key 220 Any secret information required to perform a Public Key operation. 221 This includes complete keys and partial keys. 223 Partial Key 225 In cases where a threshold key scheme is in use, a private partial 226 key is the private key information used to participate in the 227 threshold scheme by one participant. 229 Complete Key 231 A private key that is sufficient to perform the private key operation 232 without any additional information being provided. 234 2. Introduction 236 The Limited Use of Remote Keys (LURK) BOF has been scheduled with the 237 objective of discussing approaches to mitigating security risks to 238 TLS private keys. This objective was initially motivated by the need 239 to achieve site authentication in a scenario where the actual content 240 is delivered by a third party (aka Content Delivery Networks). But 241 as is demonstrated in the following, almost any solution to this 242 problem will have much broader application. 244 In evaluating proposals, it is important to consider the following 245 constraints: 247 Security 249 The security of a public key cryptosystem depends on the secrecy of 250 the private keys. A service that accepts unauthorized requests to 251 perform private key operations completely demolishes the security of 252 the cryptosystem. 254 While the introduction of a remote key service provides a new 255 potential point of failure into a Web site deployment, a system that 256 has two points of vulnerability that are well protected is usually 257 more secure than one that has a single point of vulnerability that is 258 unguarded. LURK may provide a solution to one of the principal 259 causes of compromise of code signing infrastructures, the disclosure 260 of insecurely held private keys. 262 Infrastructure Impact (Deployability) 264 The Web is supported by a large and complex eco-system. A single Web 265 transaction secured by TLS typically depends on at least a dozen 266 parties and may depend on twice that number. It is not just the user 267 and the content provider that are participants. Both use software 268 applications provided by third parties for access which may in turn 269 be the product of collaboration between tens or hundreds of 270 collaborators. Site maintenance is typically outsourced to a 271 specialist in the field who will in turn typically outsource hosting 272 of the site itself. This hosting may in turn be augmented by a 273 content Delivery Network or DDoS mitigation service. 275 A proposal that requires changes to be made by many parties in the 276 eco-system will be harder to deploy than a change which can be 277 applied bilaterally or unilaterally. 279 Latency 281 Delivery of Web Content is a competitive business where time is 282 literally money. Protocol proposals that delay the perceived loading 283 speed of Web sites are likely to be unacceptable. 285 Transparency and Audit 286 Besides limiting access to the use of a private key, the LURK 287 protocol potentially provides a mechanism for auditing the use of the 288 key. 290 Algorithm Agility 292 Any scheme should be capable of supporting arbitrary public key 293 algorithms and operations. At minimum, support for RSA, Diffie 294 Hellman and the new CFRG Elliptic Curve algorithms is required. 296 Besides Decryption and Digital Signature operations, it would be 297 highly advantageous for any protocol to support Proxy Re-Encryption 298 operations. In particular, support for 'vintage editions' of 299 recryption technology that avoids subsequent IPR encumbrances is 300 highly desirable. 302 Leverage Bound Private Keys 304 The term 'Trustworthy Computing' covers a wide range of hardware 305 based security measures that are now ubiquitously available on mobile 306 devices and increasingly supported on desktop and server hardware. 307 For purposes of limiting exposure of keys, the 309 2.1. Limited Life Credentials 311 While the LURK acronym specifies 'Limited Use', it is important to 312 note that the core objective raised by the use scenario at issue is 313 to limit the window of vulnerability for keys which may be achieved 314 by other means than remote access. 316 In particular, we can limit exposure to the risk of abuse of a 317 credentialed private key by limiting the validity of the credential, 318 either by severely limiting the validity period of the credential or 319 by employing effective mechanisms for revocation. Since the latter 320 has been attempted many times with little success, we concentrate on 321 the first approach. 323 One of the chief concerns when using a CDN is that a machine that 324 might only host a site for a few days or even a few hours requires 325 access to a private key whose credential is typically valid for a 326 year or even more. Hosts that have serviced a site in the past may 327 be rented to other customers for very different purposes before the 328 credentials have expired. The new customer might well have 329 privileged access to the machine and be able to examine disks and 330 memory to recover confidential data including keys. 332 Reducing the validity interval of the credential to match that of the 333 host makes good sense. The chief obstacles to this approach being 334 (1) the need to gracefully handle time synchronization errors in Web 335 clients attempting to access the site. And (2) the administrative 336 burden of frequently installing certificate updates. 338 Practical experience demonstrates that there is little difficulty 339 incurred by setting certificate the validity interval to 25 hours and 340 that even validity intervals of a few hours incur little 341 inconvenience. 343 Automatic issue of certificates is already the subject of the ACME 344 working group and is therefore not considered here except to the 345 extent that it might reduce the significance of the proposed use 346 scenario. 348 2.2. Private Key Service 350 A private key service performs private key operations in response to 351 properly authenticated and authorized requests. At minimum, such a 352 service requires mechanisms to: 354 Determine the private key whose use is requested. 356 Authenticate and authorize the request. 358 Protect the integrity of requests. 360 Protect the integrity and confidentiality of responses. 362 Such a service might prove insufficient for certain applications for 363 reasons of performance and/or security. 365 Batching of requests may be desirable. 367 The ability to pre-request operations may be desirable. 369 The minimal approach is also unsatisfactory on security grounds. A 370 mechanism that relies on correct configuration of the system alone to 371 prevent unauthorized use is likely to be fragile. 373 One approach that could be used to mitigate such risk is to limit the 374 application to specific cryptographic protocols rather than providing 375 unrestricted key exchange or signature capabilities. For example, 376 the service might perform a TLS 1.2 master secret derivation rather 377 than the RSA private key operation on which the exchange is based. 379 While this approach has the benefit of limiting the consequences of a 380 breach in theory, the practical effect is likely to be limited as 381 good cryptographic hygiene requires that a key used for one purpose 382 not be used for any other. 384 Another disadvantage of this approach is that it provides more 385 information to the Key Service and thus provides more opportunity for 386 a malicious side channel attack. A malicious HSM that knows the 387 origin of the requests that it is dealing can choose to only defect 388 on requests that come from the correct counter-party. A well 389 designed protocol that keeps the HSM ignorant of the source and 390 context of the requests cannot restrict the instances in which it 391 defects and is thus at greater risk of exposure. 393 2.3. Partial Key Service 395 The best way to mitigate the risk of unauthorized service is to make 396 use of some form of key splitting 'threshold' cryptography scheme 397 such that the use of private key information held at the client side 398 must be combined with use of private key information held at the LURK 399 service to effect the desired result. 401 This approach uses cryptography to enforce the authorization 402 criteria. 404 While there are many threshold schemes that could be used in theory, 405 for purposes of LURK it is only necessary to split a key into some 406 number of parts (typically two) such that all the parts are required 407 to perform a private key operation. Thus 409 3. Protocol Overview 411 [Note that in the foregoing examples, a technical limitation in the 412 implementation prevents inclusion of the authentication wrapper used 413 to authenticate protocol requests and responses. Removal of this 414 limitation prior to IETF 95 is anticipated.] 416 The LURK protocol has three parties: 418 LURK Service [Key Holder] 420 The holder of the key material. Responds to requests to create, use 421 and destroy key pair. Optionally keeps audit logs of all operations. 423 LURK Client [Key User] 425 The party authorized to direct requests to use the key material. 427 Administrator [Authenticated Party] 428 The party that authorizes LURK Clients to use key material and is 429 authorized to issue creation, and destruction requests for the keys 430 they have created. 432 Establishing the Service and Administrator as separate parties is 433 important as it allows the LURK service to be specified in a form 434 that can be readily implemented on a HSM. 436 3.1. Establishing Trust Relationships 438 The LURK protocol requires two trust relationships to be managed: 440 Between the Administrator and the LURK Service 442 Between the Client and the LURK Service 444 The means of configuration of these relationships is outside the 445 scope of this protocol but it is assumed that each of these parties 446 can authenticate messages from the other using digital signatures and 447 public key exchange. 449 3.1.1. Manual Administration 451 The necessary trust relationships MAY be established manually. This 452 presents something of a challenge in the Content Delivery Network 453 scenario as LURK Clients are being constantly added and removed. 455 3.1.2. Using the Mathematical Mesh 457 One mechanism that MAY be used to establish the necessary 458 authentication information is the Mathematical Mesh [draft- 459 hallambaker-mesh-architecture-01]. This provides a means of 460 automating the necessary administration processes without needing to 461 add support for these processes in the core LURK specification. 463 To begin configuration of a LURK deployment using the Mesh, the 464 administrator: 466 Creates a Mesh profile (if they haven't already done so). 468 Connects the LURK Service to their profile as an application with 469 configuration privilege. 471 Connects the LURK Client to their profile as an application with use 472 privilege. 474 [The Mesh application profile for the service will be added to this 475 document as an appendix in due course.] 476 Once these steps are complete, all three parties have knowledge of 477 the root of trust from which to accept control instructions (i.e. the 478 Administrator's Mesh Profile fingerprint) and a means of 479 authenticating messages from any of the three parties. 481 The administrator MAY configure additional LURK Clients and/or 482 Services in the same fashion. 484 3.2. Service Connection 486 A client MAY use the Hello transaction to determine the protocol 487 version(s), encodings and other features that are supported. 489 To facilitate interoperability, a ACME service MUST support use of 490 the JSON encoding for the Hello transaction. 492 The request message takes no parameters: 494 POST /.well-known/acme/HTTP/1.1 495 Host: example.com 496 Content-Length: 23 498 { 499 "HelloRequest": {}} 501 The response describes the protocol version (0.1) and the encodings 502 its supports. 504 HTTP/1.1 200 OK 505 Date: Tue 22 Mar 2016 02:02:33 506 Content-Length: 403 508 { 509 "HelloResponse": { 510 "Status": 200, 511 "StatusDescription": "OK", 512 "Version": { 513 "Major": 0, 514 "Minor": 1, 515 "Encodings": [{ 516 "ID": "application/json"}, 517 { 518 "ID": "application/json-b"}, 519 { 520 "ID": "application/json-c", 521 "Dictionary": ["MAK5Z-PEEEQ-PWT53-GRR55-MTBSF-UDVGM"]}, 522 { 523 "ID": "application/tls-schema"}]}}} 525 The reference service supports four encodings: 527 o 529 * JSON, The text based encoding used for these examples. 531 * JSON-B, A superset of the JSON encoding that includes binary 532 encoding of data items. 534 * JSON-C, A superset of JSON-B that includes support for 535 compression of tags and data items. 537 * TLS-Schema, An alternative binary encoding that is described by 538 a schema in the notation introduced in the TLS specification. 540 The JSON-C encoding provides an additional parameter 'Dictionary' 541 that identifies the tag compression dictionaries that the service 542 knows. This allows the dictionary to be quoted by reference rather 543 than being sent in channel. 545 Services MAY provide additional encodings at their option. 547 3.3. Creation of necessary key pairs 549 Key pair creation is a function reserved for the administrator. To 550 create a key pair, the administrator sends an authenticated request 551 to the service. Note that while message layer encryption MAY be 552 used, it is not actually required in this case. 554 The request specifies the algorithm, key parameters and intended 555 cryptographic uses. The following shows the complete HTTP request 556 for creation of an RSA signature key with 2048 bit length: 558 [Yes, I know there are no authentication wrappers on the following 559 messages. Just pretend they are there, OK? I have had all of two 560 days to work on this.] 562 POST /.well-known/acme/HTTP/1.1 563 Host: example.com 564 Content-Length: 122 566 { 567 "CreateRequest": { 568 "Parameters": { 569 "ParametersRSA": { 570 "Signature": true, 571 "KeySize": 2048}}}} 573 The response is likewise authenticated and returns the private key: 575 HTTP/1.1 200 OK 576 Date: Tue 22 Mar 2016 02:02:34 577 Content-Length: 612 579 { 580 "CreateResponse": { 581 "Status": 200, 582 "StatusDescription": "OK", 583 "KeyId": "MDZA3-4FYXN-IQPSJ-IO4RP-JTHXO-JSI66", 584 "PublicKey": { 585 "PublicKeyRSA": { 586 "kid": "MDZA3-4FYXN-IQPSJ-IO4RP-JTHXO-JSI66", 587 "n": " 588 qvwwCO9yIYQ7ujSCQKqd-1A-PB-cnG98Q5Qnm1DTU6pn-QdzxENyhhcCV2fFp9ZR 589 m27NtBCBFv_0-F8nvEhow4fQZ_ixZpHBZsoxbEV_p2cVW8aeuHZrOL917o710vct 590 XcRGb5u_t7rvTOciuhWVQxdBdaafgZdDEIlQ3Nzniv4KZvVP69gnTwygICWqRXgP 591 nK_-y12ViWApNtRq9M03czvRKk104rHN4AJirgPIBFO9lsG9Hbeb3EIOCvgSIIm2 592 Qhoh0Sow-HDtaf_j305yF84P9QbxPAYZvWjpkB3Um31iLEqh0s3ZqGpo8iBbmC9q 593 bxzzOOGKqB7WkR8kASbWAw", 594 "e": " 595 AQAB"}}}} 597 The process id repeated to create keypairs for encryption and key 598 agreement. 600 Note that even though it is possible to use a key agreement algorithm 601 for encryption and vice versa, the use of these cryptographic 602 primitives in protocols is very different. Hence it is best to treat 603 these as entirely separate for the purposes of this protocol. 605 Key agreement key request (payload only) 607 { 608 "CreateRequest": { 609 "Parameters": { 610 "ParametersECDH": { 611 "Agreement": true, 612 "Curve": "p256", 613 "Algorithm": "cfrg"}}}} 615 Key agreement key response (payload only) 617 { 618 "CreateResponse": { 619 "Status": 406, 620 "StatusDescription": "Unsupported key parameter"}} 622 Encryption key request (payload only) 624 { 625 "CreateRequest": { 626 "Parameters": { 627 "ParametersECDH": { 628 "Agreement": true, 629 "Curve": "p256", 630 "Algorithm": "cfrg"}}}} 632 Encryption key response (payload only) 634 { 635 "CreateResponse": { 636 "Status": 406, 637 "StatusDescription": "Unsupported key parameter"}} 639 3.4. Private key decryption 641 The message "This information is very secret" has been encrypted 642 using AES 128 in CBC mode and the session key encrypted under the 643 encryption key creates earlier. 645 To decrypt the message, the AcmeClient sends an authenticated request 646 that specifies the key identifer, wrapped key and encrypted data as 647 follows: 649 POST /.well-known/acme/HTTP/1.1 650 Host: example.com 651 Content-Length: 571 653 { 654 "DecryptRequest": { 655 "KeyId": "MDM4H-5EU23-UDIGL-UL2JE-5TW43-CBSR2", 656 "BulkAlg": "aescbc256", 657 "Data": " 658 KvRaMIZEGriT9mw4VYzd683yLdbfvlpZg7L5IFXZM1c", 659 "IV": " 660 2hToimOGS6cs_pecRHvk5Q", 661 "WrappedKey": " 662 c9xf_ZtQ2MQZFk3KJK601a5o58w9Bk7txMaEyjp7JfG3VjtMKL1zh82k-1kAxFsy 663 qk7Gw-zyjcRwsvRIaqHmjybxZkvG0D1ZbqXOjOzBbixjEfpEer1GHd6koh8eoeEP 664 yUVHqOgEdtWbpkaoDZhV1ZvuPBZlnfOo8JEt3_YfZpQ4ZgMyvREe23m4pmBkCHGR 665 8ag0QVUFoSdBoV7McrhxRDfn6zzQkJblVxYcusJ-LU1tTmenfufg7RSVjtXT5DyZ 666 75Bgt-wiiPMwKXRaOsckXoZz2mIBISJMJrK9suQ9JfzPnfUS7lufmLw7Pq7y3mYp 667 7Q8BmpwiASeJlTLbadPH7Q"}} 669 The service returns the decrypted message as an encrypted payload: 671 HTTP/1.1 200 OK 672 Date: Tue 22 Mar 2016 02:02:34 673 Content-Length: 135 675 { 676 "DecryptResponse": { 677 "Status": 200, 678 "StatusDescription": "OK", 679 "Value": " 680 VGhpcyBpbmZvcm1hdGlvbiBpcyB2ZXJ5IHNlY3JldA"}} 682 [Yes, it isn't encrypted yet, patience, patience. Was Rome built in 683 a day?] 685 The inner payload is: 687 { 688 "DecryptResponse": { 689 "Status": 200, 690 "StatusDescription": "OK", 691 "Value": " 692 VGhpcyBpbmZvcm1hdGlvbiBpcyB2ZXJ5IHNlY3JldA"}} 694 Alternatively, the client could send just the wrapped key for 695 decryption and then apply the bulk cipher locally. 697 3.5. Private key Agreement 699 [This is not currently implemented due to lack of the necessary 700 library to implement the new CFRG algorithms.] 702 To request a key agreement operation, the AcmeClient specifies the 703 public key of the counter party and the identifier of the private key 704 to use. A AcmeClient MAY specify the digest algorithm and 705 construction mechanism to be used to convert the result of the key 706 agreement into a key. 708 Request: 710 Response: 712 3.6. Private key signature 714 The AcmeClient requires the message "Very important this is not 715 changed" be signed under the signature key created earlier. 717 Request: 719 { 720 "SignRequest": { 721 "KeyId": "MDZA3-4FYXN-IQPSJ-IO4RP-JTHXO-JSI66", 722 "DigestAlg": "sha256", 723 "Data": " 724 VmVyeSBpbXBvcnRhbnQgdGhpcyBpcyBub3QgY2hhbmdlZA"}} 726 Response: 728 { 729 "SignResponse": { 730 "Status": 200, 731 "StatusDescription": "OK", 732 "Value": " 733 LDcTcNKpoP0REbwhBiUFh3evuO-Ml5tQb1tzk_u-DNU43wbNJGAbctWpPqy913o- 734 VgWUNHh2rbSUey839V6Snoq75ZqIabw1wZFiosdH5GRqy7C-gyR7wpZgiLLLx0qz 735 5uWj80TsyOVqMUQhNknoWb9KLgLazdJlBGPQwYwYV8NEtdoj24ZYhFjViQ7ZR40r 736 0j1kuHJE25QaOKlzvmbVJEytz4MC-Adc24EHyiKHZpVkvT6UdZI9ELZsj7kB5CBi 737 0J5n2NfLheffsBFpRjptjYngI2ccNgm9ktKhEDAUux7tqZyah9xlqt6V1J9IYh3f 738 c_g-5vHaU-dG72Gz7Awj9Q"}} 740 3.7. Key Disposal 742 After a key pair is no longer required, it SHOULD be deleted. A HSM 743 supporting the ACME protocol SHOULD ensure that some form of secure 744 erase is used to assure destruction of the data. 746 Request: 748 { 749 "DisposeRequest": { 750 "KeyId": "MDZA3-4FYXN-IQPSJ-IO4RP-JTHXO-JSI66"}} 752 Response: 754 { 755 "DisposeResponse": { 756 "Status": 200, 757 "StatusDescription": "OK"}} 759 4. Lurk Key Service Reference 761 SRV Prefix: 763 _lurk._tcp 765 HTTP Well Known Service Prefix: 767 /.well-known/lurk 769 The LURK key service provides access to a remote key service. The 770 remote service performs private key related operations in response to 771 authenticated requests. 773 4.1. Request Messages 775 A LURK request payload consists of a payload object that inherits 776 from the LurkRequest class. 778 Note that the request payload is the subject of the presentation 779 layer authentication wrapper. Thus the authantication wrapper is not 780 part of the request payload. 782 4.1.1. Message: LurkRequest 784 Base class for all request messages. 786 [None] 788 4.1.2. Message: LurkKeyRequest 790 Base class for all key request messages. 792 o 794 * Inherits: LurkRequest 796 [None] 798 4.1.3. Message: LurkResponse 800 Base class for all responses. Contains only the status code and 801 status description fields. 803 A service MAY return either the response message specified for that 804 transaction or any parent of that message. Thus the LurkResponse 805 message MAY be returned in response to any request. 807 Status: Integer (Optional) 808 Status return code. The SMTP/HTTP scheme of 2xx = Success, 3xx = 809 incomplete, 4xx = failure is followed. 811 StatusDescription: String (Optional) 813 Text description of the status return code for debugging and log 814 file use. 816 4.1.4. Successful Response Codes 818 The following response codes are returned when a transaction has 819 completed successfully. 821 [201] SuccessOK 823 Operation completed successfully 825 4.1.5. Warning Response Codes 827 The following response codes are returned when a transaction did not 828 complete because the target service has been redirected. 830 In the case that a redirect code is returned, the StatusDescription 831 field contains the URI of the new service. Note however that the 832 redirect location indicated in a status response might be incorrect 833 or even malicious and cannot be considered trustworthy without 834 appropriate authentication. 836 [303] RedirectPermanent 838 Service has been permanently moved 840 [307] RedirectTemporary 842 Service has been temporarily moved 844 4.1.6. Error Response Codes 846 A response code in the range 400-499 is returned when the service was 847 able to process the transaction but the transaction resulted in an 848 error. 850 [401] ClientUnauthorized 852 Client is not authorized to perform specified request 854 [404] NotFound 856 The requested object could not be found. 858 [406] NotAcceptable 860 The request asked for an operation that cannot be supported 861 because the server does not support certain parameters in the 862 request. For example, specific key sizes, algorithms, etc. 864 4.1.7. Structure: Version 866 Describes a protocol version. 868 Major: Integer (Optional) 870 Major version number of the service protocol. A higher 872 Minor: Integer (Optional) 874 Minor version number of the service protocol. 876 Encodings: Encoding [0..Many] 877 Enumerates alternative encodings (e.g. ASN.1, XML, JSON-B) 878 supported by the service. If no encodings are specified, the JSON 879 encoding is assumed. 881 URI: String [0..Many] 883 The preferred URI for this service. This MAY be used to effect a 884 redirect in the case that a service moves. 886 4.1.8. Structure: Encoding 888 Describes a message content encoding. 890 ID: String (Optional) 892 The IANA encoding name 894 Dictionary: String [0..Many] 896 For encodings that employ a named dictionary for tag or data 897 compression, the name of the dictionary as defined by that 898 encoding scheme. 900 4.1.9. Structure: KeyParameters 902 Specifies a cryptographic algorithm and related parameters. Note 903 that while the parameters structures allows a key to be specified 904 that supports multiple operations each key SHOULD only specify 905 exactly one operation. 907 Encrypt: Boolean (Optional) 909 Key supports encryption and decryption operations. 911 Agreement: Boolean (Optional) 913 Key supports key agreement operations. 915 Signature: Boolean (Optional) 917 Key Supports signature operations. 919 Uses: String (Optional) 921 Specifies the permitted uses for the key. All the listed uses are 922 permitted. If present non-empty, the LURK Service MUST NOT 923 permit any use not specified. 925 4.1.10. Structure: ParametersRSA 927 o 929 * Inherits: KeyParameters 931 Describes parameters for the RSA algorithm 933 KeySize: Integer (Optional) 935 The Key Size. Services MUST support key sizes of 2048 and 4096 936 bits. Services MAY support other key sizes greater than 2048 937 bits. Services MUST NOT support key sizes less than 2048 bits. 939 Padding: String [0..Many] 941 If present, specifies the padding modes that are to be supported 942 by the key. 944 4.1.11. Structure: ParametersDH 946 o 948 * Inherits: KeyParameters 950 Specifies parameters for the Diffie Hellman algorithm. These are the 951 prime and the generator which may be specified by name (for known 952 IETF defined curves) or by the parameters. 954 Curve: String (Optional) 955 Specify the curve to generate a key on by name 957 Prime: Binary (Optional) 959 Prime to use 961 Generator: Binary (Optional) 963 Generator to use 965 4.1.12. Structure: ParametersECDH 967 o 969 * Inherits: KeyParameters 971 Specifies parameters for Elliptic Curve Diffie Hellman algorithm 973 Curve: String (Optional) 975 The curve name. Valid values are "Curve255" and "Curve448" 977 Algorithm: String (Optional) 979 Specify the precise algorithm and version. 981 4.2. Transaction: Hello 983 Request: HelloRequest 985 Response:HelloResponse 987 Report service and version information. 989 The Hello transaction provides a means of determining which protocol 990 versions, message encodings and transport protocols are supported by 991 the service. 993 4.2.1. Message: HelloRequest 995 o 997 * Inherits: LurkRequest 999 [None] 1001 4.2.2. Message: HelloResponse 1003 Always reports success. Describes the configuration of the Mesh 1004 portal service. 1006 o 1008 * Inherits: LurkResponse 1010 Version: Version (Optional) 1012 Enumerates the protocol versions supported 1014 Alternates: Version [0..Many] 1016 Enumerates alternate protocol version(s) supported 1018 4.3. Transaction: Create 1020 Request: CreateRequest 1022 Response:CreateResponse 1024 Create a new public key pair for the specified algorithm and 1025 cryptographic parameters. 1027 4.3.1. Message: CreateRequest 1029 o 1031 * Inherits: LurkKeyRequest 1033 Request creation of a new key pair 1035 [None] 1037 4.3.2. Message: CreateResponse 1039 o 1041 * Inherits: LurkResponse 1043 Returns the identifier of a key pair 1045 KeyId: String (Optional) 1047 Unique identifier for the public key pair created if the operation 1048 succeeded. 1050 4.4. Transaction: Dispose 1052 Request: DisposeRequest 1054 Response:DisposeResponse 1056 Dispose of the specified key pair. 1058 4.4.1. Message: DisposeRequest 1060 o 1062 * Inherits: LurkKeyRequest 1064 Request creation of a new key pair 1066 KeyId: String (Optional) 1068 The Key to dispose. 1070 4.4.2. Message: DisposeResponse 1072 o 1074 * Inherits: LurkResponse 1076 Reports result of an attempt to dispose of a key pair. 1078 [None] 1080 4.5. Transaction: Sign 1082 Request: SignRequest 1084 Response:SignResponse 1086 Request signature of a data value or digest 1088 4.5.1. Message: SignRequest 1090 o 1092 * Inherits: LurkKeyRequest 1094 Describe the data to be signed 1096 KeyId: String (Optional) 1098 The key to be used for the operation. 1100 DigestAlg: String (Optional) 1102 The digest algorithm to be used. 1104 Data: Binary (Optional) 1106 Data to be digested and signed. 1108 Digest: Binary (Optional) 1110 Digest calculated on the data to be signed. 1112 This field is ignored if the Data field is present. 1114 4.5.2. Message: SignResponse 1116 o 1118 * Inherits: LurkResponse 1120 Returns the signature response. 1122 Value: Binary (Optional) 1124 The signature response value. 1126 4.6. Transaction: Agree 1128 Request: AgreeRequest 1130 Response:AgreeResponse 1132 Perform a key agreement operation. 1134 4.6.1. Message: AgreeRequest 1136 o 1138 * Inherits: LurkKeyRequest 1140 Specify the key agreement parameters. 1142 KeyId: String (Optional) 1144 The key to be used for the operation. 1146 4.6.2. Message: AgreeResponse 1148 o 1150 * Inherits: LurkResponse 1152 Returns the result of the key agreement 1154 Value: Binary (Optional) 1156 The key agreement result 1158 4.7. Transaction: Decrypt 1160 Request: DecryptRequest 1162 Response:DecryptResponse 1164 Perform a decryption operation. 1166 4.7.1. Message: DecryptRequest 1168 o 1170 * Inherits: LurkKeyRequest 1172 Request a decryption operation. 1174 KeyId: String (Optional) 1176 The key to be used for the operation. 1178 BulkAlg: String (Optional) 1180 The bulk decryption algorithm to be used 1182 Data: Binary (Optional) 1184 Data to be decrypted 1186 IV: Binary (Optional) 1188 Initialization Vector. This field is ignored unless the Data 1189 field is also specified. If an algorithm that requires an 1190 initialization vector is specified and this field is empty, the 1191 leading bytes of the Data field are used. 1193 WrappedKey: Binary (Optional) 1195 Wrapped key data to decrypt 1197 4.7.2. Message: DecryptResponse 1199 o 1201 * Inherits: LurkResponse 1203 Returns the result of the decryption request 1205 Value: Binary (Optional) 1207 The decrypted data 1209 5. Advanced Functions 1211 The functions described in this document are not intended to be an 1212 exhaustive list of all the possible features that a HSM providing 1213 LURK services might be expected to provide. Possible additional 1214 features commonly supported by HSM devices that are not necessarily 1215 within the scope of the LURK objectives include: 1217 Ability to securely transfer key pairs to other LURK devices for 1218 backup purposes. 1220 Maintaining logs of all device operations. Such logs MAY be append 1221 only so as to prevent tampering or destruction. 1223 Constraining the use of a private key to specific protocol uses such 1224 as a specific TLS key exchange. 1226 More interestingly however, we can take advantage of the transition 1227 to new cipher suites based on Diffie Hellman to take advantage of 1228 some of the interesting properties of this crypto system. 1230 For example, in any Diffie Hallman type crypto scheme, the shared 1231 parameters are a cyclic group G, the private key is an integer n that 1232 is less than the order of the group and the public key is |e^n|G 1233 where e is a non zero point in G. 1235 It follows therefore that given two Diffie Hellman key pairs (x, e^x) 1236 and (y, e^y), and we can generate a new key pair (x+y, e^x . e^y). 1237 This feature permits the co-operative key generation and threshold 1238 key agreement schemes described below. 1240 5.1. Co-operative Key Generation 1242 An extension to the current protocol supports the use of co-operative 1243 key generation techniques. In this approach, a generated Key Pair 1244 can be shown to have been derived from specific inputs that guarantee 1245 certain properties of the final Key Pair. 1247 Before requesting key pair generation by the LURK Service, the 1248 administrator generates a Key Pair and sends both parts of the key 1249 pair to the service. The service then generates a new key pair 1250 internally and then combines it in the manner described above to 1251 generate the final key pair. The service then returns the public 1252 component of both the initial and the derived key pair to allow the 1253 administrator to verify that the construction did in fact use the 1254 material provided. 1256 This approach guarantees that the final key pair has at least as much 1257 randomness as either of the input key pairs. This provides certain 1258 protections against both the use of a faulty number generator by one 1259 party or the other and the use of a HSM using a maliciously 1260 constructed key pair. 1262 5.2. Threshold and Proxy Re-Encryption Schemes 1264 Another interesting possibility is that the use of the private key be 1265 split between the LURK Client and LURK Service using a threshold 1266 cryptography scheme. 1268 While there are many threshold schemes in the literature, only some 1269 of these are generally considered to be practical. Fortunately, the 1270 Diffie Hellman key combination effect described above provides a very 1271 simple and practical scheme for the case where there are n shares and 1272 all n shares are required to perform a key agreement operation. 1274 Surprisingly perhaps, the use of such a scheme does not require any 1275 changes to the protocol at all as far as the actual use of the key is 1276 concerned. Generation of a keys may require changes however since it 1277 is now necessary to generate multiple key pairs and communicate them 1278 to the appropriate parties. 1280 6. Algorithms and Identifiers 1282 This section is currently mostly a placeholder. It is expected that 1283 LURK will support: 1285 The traditional IETF repertoire of cryptographic algorithms (RSA, DH, 1286 etc) 1287 The new algorithms developed by CFRG and CURDLE. 1289 6.1. Key Algorithms 1291 6.1.1. Parameters RSA 1293 The RSA algorithm supports the following padding modes: PKCS#1, OEAP. 1295 A LURK Service MUST NOT support key sizes of less than 2048 bits. 1297 6.1.2. Parameters DH 1299 The Diffie Hellman key agreement mechanism described in [RFC2631] 1300 with the named groups defined in [RFC4419] and [RFC5114]. 1302 6.1.3. Parameters ECDH 1304 Elliptic Curve Diffie Hellman on the following groups: 1306 NIST P256, P384, P521 1308 Curve 25519 and Curve 448 as specified in [RFC7748] 1310 6.2. Key Use Restrictions 1312 Key use restrictions specify the purposes for which a key may be 1313 used. These MAY limit the use of the key to specific key agreement 1314 mechanisms (e.g. for TLS, SSH, etc.) 1316 6.2.1. RSALG Erb-Saltz 1318 TLS key agreement according to the mechanism described in [draft-erb- 1319 lurk-rsalg]. 1321 7. Acknowledgements 1323 TBS 1325 8. Implementation Status 1327 This section records the status of known implementations of the 1328 protocol defined by this specification at the time of posting of this 1329 Internet-Draft, and is based on a proposal described in RFC 6982. 1330 The description of implementations in this section is intended to 1331 assist the IETF in its decision processes in progressing drafts to 1332 RFCs. Please note that the listing of any individual implementation 1333 here does not imply endorsement by the IETF. Furthermore, no effort 1334 has been spent to verify the information presented here that was 1335 supplied by IETF contributors. This is not intended as, and must not 1336 be construed to be, a catalog of available implementations or their 1337 features. Readers are advised to note that other implementations may 1338 exist. 1340 According to RFC 6982, "this will allow reviewers and working groups 1341 to assign due consideration to documents that have the benefit of 1342 running code, which may serve as evidence of valuable experimentation 1343 and feedback that have made the implemented protocols more mature. 1344 It is up to the individual working groups to use this information as 1345 they see fit". 1347 8.1. Reference Implementation 1349 Organization: Comodo Group Inc. 1351 Implementer: Phillip Hallam-Baker 1353 Maturity: Prototype 1355 This implementation was used to produce the reference section and all 1356 the examples in this document. Since the conversion of specification 1357 to code is automatic, there is a high degree of assurance that the 1358 reference implementation is consistent with this document. 1360 8.1.1. Coverage: 1362 The draft-xx branch describes the code used to create version xx of 1363 this document. 1365 The main current limitations are that the code only supports RSA key 1366 pairs and for ease of development the server does not persist keys 1367 across sessions. Nor does the implementation currently support the 1368 HTTP payload authentication and encryption layer or make use of TLS. 1369 These could be easily fixed. 1371 The client and server are implemented as libraries that may be called 1372 from a multi-protocol server. A standalone server will be provided 1373 in a future release. 1375 Only the JSON encoding is currently implemented. The JSON-B, JSON-C, 1376 ASN.1 and TLS Schema implementations are all supported by the code 1377 generation tool but not currently implemented as the build tool 1378 bindings for those encodings have not yet been finalized or 1379 documented. 1381 The key restrictions for TLS key exchange have not yet been 1382 implemented. 1384 The code has only been tested on Windows 10 but passed compatibility 1385 testing for both Mono and dotNetCore 10 run times which should in 1386 theory permit use on Linux and OSX platforms. 1388 8.1.2. Licensing 1390 The code is released under an MIT License 1392 Source code is available from GitHub at 1393 https://github.com/hallambaker/LURK-PHB 1395 8.1.3. Implementation Experience 1397 The implementation and specification documentation were developed in 1398 Visual Studio using the PHB Build Tools suite. 1400 8.1.4. Contact Info 1402 Contact Phillip Hallam-Baker phill@hallambaker.com 1404 9. Security Considerations 1406 [This is just a sketch for the present.] 1408 9.1. Confidentiality 1410 9.1.1. Disclosure of Private Key 1412 The service provider has access to the private key or a partial key 1413 which may therefore be at risk of disclosure if the service is 1414 breached. 1416 Best practice dictates that a LURK service employ mechanisms to bind 1417 private keys and partial keys to the Host such that extraction is not 1418 possible. 1420 9.1.2. Side Channel Disclosure 1422 A malicious LURK service might intentionally leak a private key or 1423 partial key through a side channel. For example the RSA modulus side 1424 channel described by Moti Yung. 1426 Another potential vector for side channel attacks is through any 1427 mechanism that involves randomness. For example, a service might 1428 leak parts of the private key in nonce values it supplied. 1430 9.1.3. Targeted Side Channel Disclosure 1432 A malicious LURK service that has context information that allows it 1433 to determine the source of a request might only defect on specific 1434 requests. For example, leaking private key material on a request 1435 from a co-conspirator or leaking session key material when 1436 communication is being made to a specific site to facilitate 1437 surveillance. 1439 9.1.4. Traffic Analysis 1441 The patterns of access to a LURK service might reveal information 1442 that discloses behaviors of the client using the service. 1444 9.1.5. Metadata Leakage 1446 A LURK service might log metadata relating to requests that would not 1447 otherwise be kept and thus expose the data to the possibility of 1448 disclosure. 1450 Contrawise, metadata capture might be highly desirable to support 1451 logging and audit. 1453 9.2. Integrity 1455 9.2.1. Unauthorized Use of Private Key 1457 A LURK service might provide private key services to unauthorized 1458 parties. 1460 The ability to log and audit use of the service is thus highly 1461 desirable. 1463 9.3. Availability 1465 9.3.1. Cached data 1467 The long term master secrets established in a TLS key exchange may 1468 have a lifetime of hours or even days. A host that no longer has 1469 access to the LURK service may nevertheless have the ability to 1470 establish TLS channels by using cached connection tickets. 1472 10. IANA Considerations 1474 [TBS list out all the code points that require an IANA registration] 1476 11. Appendix: TLS Schema 1478 [TLS notation schema for use with the TLS encoding redacted for 1479 brevity.] 1481 12. Appendix: JSON-C Tag Dictionary 1483 [JSON-C tag dictionary for use with JSON-C encoding redacted for 1484 brevity.] 1486 13. Appendix: Mesh Application Profile 1488 [Not yet implemented.] 1490 14. Normative References 1492 [draft-erb-lurk-rsalg] 1493 "[Reference Not Found!]". 1495 [draft-hallambaker-json-web-service-02] 1496 "[Reference Not Found!]". 1498 [draft-hallambaker-jsonbcd-05] 1499 "[Reference Not Found!]". 1501 [draft-hallambaker-mesh-architecture-01] 1502 "[Reference Not Found!]". 1504 [draft-hallambaker-mesh-reference-02] 1505 "[Reference Not Found!]". 1507 [draft-hallambaker-udf-03] 1508 "[Reference Not Found!]". 1510 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1511 RFC 2631, DOI 10.17487/RFC2631, June 1999. 1513 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 1514 Group Exchange for the Secure Shell (SSH) Transport Layer 1515 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006. 1517 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 1518 Groups for Use with IETF Standards", RFC 5114, 1519 DOI 10.17487/RFC5114, January 2008. 1521 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1522 (TLS) Protocol Version 1.2", RFC 5246, 1523 DOI 10.17487/RFC5246, August 2008. 1525 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 1526 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1527 2014. 1529 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1530 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1531 2015. 1533 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1534 RFC 7516, DOI 10.17487/RFC7516, May 2015. 1536 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 1537 DOI 10.17487/RFC7518, May 2015. 1539 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1540 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1541 2016. 1543 Author's Address 1545 Phillip Hallam-Baker 1546 Comodo Group Inc. 1548 Email: philliph@comodo.com