idnits 2.17.1 draft-hallambaker-acme-omnipublish-00.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 == Unrecognized Status in 'Intended Status:', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (July 6, 2015) is 3217 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) == Missing Reference: 'TBS' is mentioned on line 225, but not defined == Unused Reference: 'RFC2822' is defined on line 972, but no explicit reference was found in the text == Unused Reference: 'RFC6960' is defined on line 975, but no explicit reference was found in the text == Unused Reference: 'RFC6090' is defined on line 980, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 983, but no explicit reference was found in the text == Unused Reference: 'RFC6962' is defined on line 990, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-hallambaker-omnibroker-07 == Outdated reference: A later version (-08) exists of draft-hallambaker-wsconnect-05 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Downref: Normative reference to an Informational RFC: RFC 6090 -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) Phillip Hallam-Baker 2 INTERNET-DRAFT Comodo Group Inc. 3 Intended Status: July 6, 2015 4 Expires: January 7, 2016 6 OmniBroker Publication Protocol 7 draft-hallambaker-acme-omnipublish-00 9 Abstract 11 OmniPublish is a Web Service that supports server configuration 12 management. The supported transaction set allows a server to obtain 13 and renew necessary cryptographic credentials, publish service 14 discovery statements and obtain network configuration specifications. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 Copyright Notice 33 Copyright (c) 2015 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Traditional Server Configuration Approach . . . . . . . 3 52 2.2. Automating network management. . . . . . . . . . . . . . 3 53 2.2.1. Cloud Computing Requirements. . . . . . . . . . . . 4 54 3. Omnibroker Publication Service . . . . . . . . . . . . . . . 4 55 3.1. Service Binding . . . . . . . . . . . . . . . . . . . . 5 56 3.2. Acquiring Cryptographic Credentials . . . . . . . . . . 5 57 3.2.1. Example: Small Web Site Operator . . . . . . . . . . 5 58 3.2.2. Example: Large Enterprise . . . . . . . . . . . . . 10 59 3.3. Generating or Obtaining a Public/Private KeyPair. . . . 11 60 3.3.1. Example: Internet Coffee Pot . . . . . . . . . . . 11 61 3.4. Request Network Configuration . . . . . . . . . . . . . 14 62 3.4.1. Example: Coffe Pot Service Registration. . . . . . . 14 63 4. OBPPublish . . . . . . . . . . . . . . . . . . . . . . . . . . 16 64 4.1. OBPPublish Transactions . . . . . . . . . . . . . . . . . 16 65 4.1.1. Advertise . . . . . . . . . . . . . . . . . . . . . 16 66 4.1.2. Credential . . . . . . . . . . . . . . . . . . . . . 16 67 4.1.3. Notify . . . . . . . . . . . . . . . . . . . . . . . 16 68 4.2. OBPPublish Messages . . . . . . . . . . . . . . . . . . . 16 69 4.2.1. Message: PResponse . . . . . . . . . . . . . . . . . 16 70 4.2.2. Message: AdvertiseRequest . . . . . . . . . . . . . 17 71 4.2.3. Message: AdvertiseResponse . . . . . . . . . . . . . 17 72 4.2.4. Message: CredentialRequest . . . . . . . . . . . . . 17 73 4.2.5. Message: CredentialResponse . . . . . . . . . . . . 17 74 4.2.6. Message: NotifyRequest . . . . . . . . . . . . . . . 18 75 4.2.7. Message: NotifyResponse . . . . . . . . . . . . . . 19 76 4.3. OBPPublish Structures . . . . . . . . . . . . . . . . . . 19 77 4.3.1. Structure: TaggedBinary . . . . . . . . . . . . . . 19 78 5. Transport Bindings and Identifiers . . . . . . . . . . . . . . 19 79 5.1. Content-Type Identifiers . . . . . . . . . . . . . . . . 19 80 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 82 7.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 20 83 7.2. Breach of Trust . . . . . . . . . . . . . . . . . . . . . 20 84 7.3. Coercion . . . . . . . . . . . . . . . . . . . . . . . . 20 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 88 9.2. Informative References . . . . . . . . . . . . . . . . . 20 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 1. Definitions 93 1.1. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Introduction 101 OmniPublish is a Web Service that supports server configuration 102 management. The supported transaction set allows a server to obtain 103 and renew necessary cryptographic credentials, publish service 104 discovery statements and obtain network configuration specifications. 106 The services supported by OmniPublish are complimentary to the 107 services provided by OmniBroker [I-D.hallambaker-omnibroker] and the 108 protocols share the same transport binding (HTTP, UYFM) and encoding 109 options (JSON). 111 2.1. Traditional Server Configuration Approach 113 In the traditional approach to server configuration the network 114 administrator is required to anticipate and perform all the necessary 115 configuration needs of the service. For an enterprise server these 116 steps will typically include: 118 * Enter server parameters in the DNS. 120 * Configure firewall to permit external access. 122 * Generate Public/Private Keypair. 124 * Apply for digital certificate. 126 * Install digital certificate. 128 While executing each individual step may be considered 129 straightforward, any configuration task involving five non-trivial 130 human mediated tasks is liable to be error prone. Moreover 131 maintaining the configuration represents an ongoing maintenance 132 effort as certificates expire, network configurations are changed, 133 servers are updated, etc. 135 2.2. Automating network management. 137 In the traditional administration model the human is required to 138 anticipate the needs of the server. Yet the server itself knows its 139 needs with great precision although not necessarily how they are to 140 be realized. 142 A server that is configured to use the TLS protocol knows that a 143 certificate is required and the purposes for which it is to be used. 144 It knows when the certificate is about to expire and requires 145 replacement and when evidence of certificate status (e.g. an OCSP 146 token) requires renewal. 148 Network configuration raises similar considerations except that the 149 information available to a server is typically insufficient to 150 perform network configuration tasks. It is not guaranteed that the 151 local network IP address of a server is the same as the IP address 152 that is visible to the external network. A mechanism in which the 153 server edits DNS entries directly is therefore less functional than 154 one in which the DNS entries are generated by a mediated service that 155 has access to the necessary additional data. 157 Network configuration is an administration function and therefore 158 requires administrative privileges. Accordingly, every OmniPublish 159 request and response is authenticated using credentials established 160 using the SXS-Connect protocol [I-D.hallambaker-wsconnect]. 162 2.2.1. Cloud Computing Requirements. 164 Cloud computing does not necessarily raise new management 165 requirements but the requirements that are raised become more urgent. 166 In the traditional model a service ran on a fixed number of hosts in 167 a configuration that was static for months or years. In a cloud 168 computing environment the number of hosts supporting a service might 169 vary several times in an hour to respond to variations in load. 171 An important consequence of the transient nature of cloud computing 172 is that hosts which provide a service for a few hours or even minutes 173 are issued cryptographic credentials that are valid for a year. 175 3. Omnibroker Publication Service 177 The OmniPublish service is designed to permit services to manage 178 themselves to the greatest extent possible. 180 The features that are most likely to make deployment attractive in 181 the short term are the ability to manage cryptographic credentials 182 including acquisition of public/private keypairs, certificates and 183 certificate status assertions. 185 An enterprise with a large in-house IT department would typically 186 host the Omnipublish service locally. The local service would then be 187 configured to forward publication data to any IT facitilities that 188 happen to be outsourced such as CA services, DNS etc. 190 A similar model may be applied in the home automation environment 191 with devices under management publishing their service information to 192 the local publication server which then forwards the information to 193 external services as necessary. The chief difference between this 194 case and the enterprise case being that the service operation cannot 195 depend on the end user being aware that the device exists, let alone 196 perform configuration. 198 In a pure cloud computing environment the OmniPublish service would 199 have to be outsourced since there is no internal IT system for it to 200 run off. 202 3.1. Service Binding 204 Application establishes a service connection to the OmniPublish 205 service. 207 3.2. Acquiring Cryptographic Credentials 209 One of the chief reasons given for not using cryptographic protocols 210 such as IPSEC, S/MIME and TLS is the difficulty of obtaining or 211 registering the necessary cryptographic credentials. In the case of 212 an Internet protocol this is typically but not always a PKIX 213 certificate bound to a private key held by the the certificate 214 subject. 216 3.2.1. Example: Small Web Site Operator 218 Alice is the owner of a small business that operates a Web site. To 219 protect the privacy of the Web site users, Alice decides to enable 220 TLS on the Web site. Accordingly, Alice selects a Certificate 221 Authority Example CA Inc. that issues a certificate with an 222 appropriate validation requirement for her intended use. 224 Alice provides her contact details to the CA which returns an account 225 identifier alice@example.net and a PIN value [TBS]. 227 The credentials are immediately valid for creating a service 228 connection using the PIN. The Service Connection Ticket is obtained 229 by a Web Server administration tool: 231 POST /.well-known/sxs-connect/ HTTP/1.1 232 Content-Type: application/json;charset=UTF-8 233 Cache-Control: no-store 234 Host: localhost:8080 235 Content-Length: 344 236 Expect: 100-continue 238 { 239 "OpenPINRequest": { 240 "Encryption": ["A128CBC", 241 "A256CBC", 242 "A128GCM", 243 "A256GCM"], 245 "Authentication": ["HS256", 246 "HS384", 247 "HS512", 248 "HS256T128"], 249 "Account": "alice", 250 "Service": ["omni-publish"], 251 "Domain": "example.net", 252 "HaveDisplay": false, 253 "Challenge": " 254 4m7Lzr7g2FzllXcVGeDIOw"}} 256 The service responds with the challenge to be used to validate the 257 PIN: 259 HTTP/1.1 281 Pin code required 260 Content-Length: 511 261 Date: Wed, 21 May 2014 20:05:54 GMT 262 Server: Microsoft-HTTPAPI/2.0 264 { 265 "OpenPINResponse": { 266 "Status": 281, 267 "StatusDescription": "Pin code required", 268 "Challenge": " 269 cHbxV3Uwkb-CYezJhKj-wA", 270 "ChallengeResponse": " 271 98RV4Se7VQIP3FbqcrLKyUth5u6F48dbCGpzrHpkGfQ", 272 "Cryptographic": { 273 "Secret": " 274 e6oSWl3dFfNkpYXvSTvY1w", 275 "Encryption": "A128CBC", 276 "Authentication": "HS256", 277 "Ticket": " 278 V8ae-8uQMtt_uyKJQLbx4umJEpsz--OXVriEHRoq5sw5uq6u1_4tWv8ro7DyD5Su 279 hSpOibX2cOnd0OHSOJpcA1Gs9WjRArqzz0WrD0Inl39d89zbcWoMKYKhlOFFV_LF 280 V8kPPoK8BmaQOxCo3kBrxg"}}} 282 The administration tool completes the request by proving knowledge of 283 the PIN: 285 POST /.well-known/sxs-connect/ HTTP/1.1 286 Content-Type: application/json;charset=UTF-8 287 Cache-Control: no-store 288 Session: Value=J5wXEchUbr7k2A0mvaOEPnr3KGFagzg1vH_MX6W1R14; 289 Id=V8ae-8uQMtt_uyKJQLbx4umJEpsz--OXVriEHRoq5sw5uq6u1_4tWv8ro7Dy 290 D5SuhSpOibX2cOnd0OHSOJpcA1Gs9WjRArqzz0WrD0Inl39d89zbcWoMKYKhlOF 291 FV_LFV8kPPoK8BmaQOxCo3kBrxg 292 Host: localhost:8080 293 Content-Length: 129 294 Expect: 100-continue 295 { 296 "TicketRequest": { 297 "Service": ["omni-publish"], 298 "ChallengeResponse": " 299 49GCx5HUvU2SNE6M3GuKcxgFfvZKDLpTfpqXUOAGXVE"}} 301 The Connection service returns the OmniPublish connection parameters: 303 HTTP/1.1 OK Success 304 Content-Length: 1306 305 Date: Wed, 21 May 2014 20:05:54 GMT 306 Server: Microsoft-HTTPAPI/2.0 308 { 309 "TicketResponse": { 310 "Status": 200, 311 "StatusDescription": "Success", 312 "Cryptographic": [{ 313 "Protocol": "sxs-connect", 314 "Secret": " 315 DOdZw6ynGANAjqnR-1gL0A", 316 "Encryption": "A128CBC", 317 "Authentication": "HS256", 318 "Ticket": " 319 Ay9sUcNcC0GH9cY5NiRFcrqjFL0wTgTn69uO9SUPvP_XqB05yJ_fLqeI622H-bBu 320 klDhb1TpUGwQMAgNNwRkgsu97Dc38WBfUiyetM0TwYY"}], 321 "Service": [{ 322 "Service": "omni-publish", 323 "Name": "localhost", 324 "Port": 8080, 325 "Priority": 100, 326 "Weight": 100, 327 "Transport": "HTTP", 328 "Cryptographic": { 329 "Secret": " 330 LfRHVDFWVkVQu81lI2wT8w", 331 "Encryption": "A128CBC", 332 "Authentication": "HS256T128", 333 "Ticket": " 334 OufJWkZCHmCLVeSuS4Nth4ozUrRfyDa4v8Dd5FIrkIWPQrGnHLgG_6ZmoHQGqIRg 335 7BL7Gm9Jq7LQihkCLhgQjp1LJqpDmDuDFbH5ZRDl7_g"}}, 336 { 337 "Service": "omni-publish", 338 "Name": "localhost", 339 "Port": 9090, 340 "Priority": 100, 341 "Weight": 100, 342 "Transport": "UDP", 343 "Cryptographic": { 344 "Secret": " 345 elODZJePf2UDWW1hHw2-3A", 346 "Encryption": "A128CBC", 347 "Authentication": "HS256T128", 348 "Ticket": " 349 xMn4JDCQIg9WSHTVh1HwdJQq1iBoIHNk-BRHdhq_WGGeWv6cgfDgLYo2-U4BX2IH 350 _SRzZ1fDf5dHzfE67wuPawutwOkemJNH4mOK0XYeNPc"}}]}} 352 The administration tool enters the connection parameters into the 353 server configuration data. At this point all the administrative tasks 354 related to the server are complete and the remainder of the process 355 can be performed automatically. 357 The server begins the process by generating a public key pair and 358 Certificate Signing Request [RFC2986] and requests issue of a 359 certificate with a CredentialRequest: 361 POST /.well-known/omni-publish/ HTTP/1.1 362 Content-Type: application/json;charset=UTF-8 363 Cache-Control: no-store 364 Session: Value=ArwY9yiAOaMjxTx4jE_BzNTNJ5z4Nn-I6gjdZPC5ejI; 365 Id=OufJWkZCHmCLVeSuS4Nth4ozUrRfyDa4v8Dd5FIrkIWPQrGnHLgG_6ZmoHQG 366 qIRg7BL7Gm9Jq7LQihkCLhgQjp1LJqpDmDuDFbH5ZRDl7_g 367 Host: localhost:8080 368 Content-Length: 148 369 Expect: 100-continue 371 { 372 "CredentialRequest": { 373 "Authentication": { 374 "ContentType": "application/pkcs-10", 375 "Data": " 376 AQID"}, 377 "MakePrivateKey": false}} 379 The service accepts the request but the process cannot be completed 380 until the validation process required for the class of certificate 381 has been completed. Accordingly the service returns the status 382 'Pending' and gives an estimated completion time: 384 HTTP/1.1 282 Transaction Incomplete 385 Content-Length: 98 386 Date: Wed, 21 May 2014 20:05:55 GMT 387 Server: Microsoft-HTTPAPI/2.0 389 { 390 "CredentialResponse": { 391 "Status": 282, 392 "StatusDescription": "Transaction Incomplete"}} 394 The validation process completes successfully and the CA issues the 395 certificate. The server requests delivery of the certificate by 396 repeating the CredentialRequest: 398 POST /.well-known/omni-publish/ HTTP/1.1 399 Content-Type: application/json;charset=UTF-8 400 Cache-Control: no-store 401 Session: Value=ArwY9yiAOaMjxTx4jE_BzNTNJ5z4Nn-I6gjdZPC5ejI; 402 Id=OufJWkZCHmCLVeSuS4Nth4ozUrRfyDa4v8Dd5FIrkIWPQrGnHLgG_6ZmoHQG 403 qIRg7BL7Gm9Jq7LQihkCLhgQjp1LJqpDmDuDFbH5ZRDl7_g 404 Host: localhost:8080 405 Content-Length: 148 406 Expect: 100-continue 408 { 409 "CredentialRequest": { 410 "Authentication": { 411 "ContentType": "application/pkcs-10", 412 "Data": " 413 AQID"}, 414 "MakePrivateKey": false}} 416 This time the certificate is ready and is returned to the server. For 417 the convenience of the server software, the response message tells 418 the Web server when the certificate will expire and the earliest and 419 latest dates on which to request renewal: 421 HTTP/1.1 282 Transaction Incomplete 422 Content-Length: 98 423 Date: Wed, 21 May 2014 20:05:55 GMT 424 Server: Microsoft-HTTPAPI/2.0 426 { 427 "CredentialResponse": { 428 "Status": 282, 429 "StatusDescription": "Transaction Incomplete"}} 431 Note that the certificate returned is a short lifetime certificate 432 that is only valid for a 72 hour interval, 24 hours of which have 433 already elapsed at issue time. Use of short lived certificates is 434 generally accepted as being highly desirable as it eliminates the 435 need for certificate status reporting. The certificates issued will 436 expire at the same time that any static status report would. The 437 chief objection to the use of short lived certificates has been the 438 need for daily administrative intervention. Automating the process of 439 updating the certificate eliminates this objection. 441 In addition to eliminating the need to track revocation status 442 separately, performing certificate updates on a daily basis is 443 potentially more reliable than one that is only activated once a 444 year. Network changes that prevent a an update completing 445 successfully have immediate impact at a time the network 446 administration is looking for potential problems rather than being 447 discovered up to a year later when the personel who caused the change 448 may have been reassigned or left the company. 450 The server MAY apply for renewal of the certificate at any time after 451 the earliest date specified in the issue statement. If no request is 452 made by the time that the latest time has been reached, the issuing 453 CA MAY begin attempting to contact their customer to determine the 454 cause. To avoid unnecessary warning messages from the CA (and 455 possibly additional invoices for unused services) the server may 456 inform the CA that certificate updates will not be required for an 457 extended period using the Notify method: 459 POST /.well-known/omni-publish/ HTTP/1.1 460 Content-Type: application/json;charset=UTF-8 461 Cache-Control: no-store 462 Session: Value=wFsqI6wkH-TuCyGkIOjL3TJsbkvJCXxdHGohugk0hx0; 463 Id=vVuUnw2Pi0xlHB2OFnbOBTDmLn9qC1HhEjUkJMHfCtBZRCPXc1GzPw8TLm1b 464 8asS-GCtD8H681WvoGW0DcEgNMDUc0UZu-ZPo_wA9f8f-bk 465 Host: localhost:8080 466 Content-Length: 129 467 Expect: 100-continue 469 { 470 "NotifyRequest": { 471 "NextState": "Offline", 472 "Earliest": "2014-05-21T20:05:56Z", 473 "Latest": "2014-05-21T20:06:56Z"}} 475 3.2.2. Example: Large Enterprise 477 Since Alice only operates one Web server, the simplest management 478 solution for her is for the Web server to establish a direct 479 connection to the CA. In a large enterprise with several hundred 480 servers, a centralized management approach which allows 481 configurations to be applied to groups of servers as a unit is 482 usually required. 484 To support this configuration, Bob deploys a local OmniPublish 485 service in his network. Every machine that Bob manages connects to 486 his local OmniPublish service to obtain its cryptographic 487 credentials. The local OmniPublish service connects to the 488 OmniPublish service of the CA to these service requests: 490 +----------+ 491 | Machine 1|--+ 492 +----------+ | 493 | 494 +----------+ | +----------+ +----------+ 495 | Machine 2|--+-->| Local OP |---------->| CA OP | 496 +----------+ | +----------+ +----------+ 497 | 498 +----------+ | 499 | Machine 3|--+ 500 +----------+ 502 3.3. Generating or Obtaining a Public/Private KeyPair. 504 Conventional wisdom holds that public/private key pairs should be 505 generated on the host on which they are to be used and exist in no 506 other location. 508 In practice, this mode of operation is not always the most desirable. 509 In the case of keypairs to be used for encryption of static data, the 510 decryption key must be available to all the machines that need 511 decryption capabilities. 513 Key generation procedures for public key algorithms can be lengthy. 514 While a delay of a few seconds or even a few minutes is acceptable in 515 a one-time server configuration process, introducing such a delay 516 into server startup is frequently unacceptable. 518 Experience of operating cryptographic systems has proved that correct 519 and secure implementation of key generation capabilities is beyond 520 the capabilities of many programmers. Random seeds are frequently 521 generated with insufficient entropy. In some cases entropy is leaked 522 after the seed is used to generate the private key. 524 For the above reasons, it is frequently but not always desirable to 525 perform generation of public/private keypairs as a centralized 526 service supported by a small number of machines that can be tightly 527 controlled an audited. 529 3.3.1. Example: Internet Coffee Pot 531 Bob buys a new coffee pot for his office that supports the 532 hypothetical 'Ready to Brew' Web Service that allows the machine to 533 be instructed to brew a cup of fresh coffee. Since this is an 534 important and security sensitive function, the coffee pot supports 535 use of the TLS protocol but the control hardware does not have access 536 to a suitible source of randomness for generating a public keypair. 538 To meet this need the coffee pot simply requests that the OmniPublish 539 service generate a keypair on its behalf and return the private key 540 with the certificate. Note that since Bob has bound the coffee pot to 541 his local omnibroker service rather than a service provided by a 542 public CA, Bob still exercises full control over generation of 543 public/private keypairs. He is simply choosing to generate the 544 keypair in a different place. 546 [TBS: provide a DH exchange to enable an application level guarantee 547 that the private key is delivered under a sound encryption scheme] 549 POST /.well-known/omni-publish/ HTTP/1.1 550 Content-Type: application/json;charset=UTF-8 551 Cache-Control: no-store 552 Session: Value=tKs0Y7AGoqfFtZDIUh395TlbIU2E6ciO2beA4lnBtgs; 553 Id=vVuUnw2Pi0xlHB2OFnbOBTDmLn9qC1HhEjUkJMHfCtBZRCPXc1GzPw8TLm1b 554 8asS-GCtD8H681WvoGW0DcEgNMDUc0UZu-ZPo_wA9f8f-bk 555 Host: localhost:8080 556 Content-Length: 147 557 Expect: 100-continue 559 { 560 "CredentialRequest": { 561 "Authentication": { 562 "ContentType": "application/pkcs-10", 563 "Data": " 564 AQID"}, 565 "MakePrivateKey": true}} 567 The service accepts the request and returns the requested 568 credentials: 570 HTTP/1.1 OK Success 571 Content-Length: 3426 572 Date: Wed, 21 May 2014 20:05:55 GMT 573 Server: Microsoft-HTTPAPI/2.0 575 { 576 "CredentialResponse": { 577 "Status": 200, 578 "StatusDescription": "Success", 579 "Credential": { 580 "ContentType": "application/pkix-cert", 581 "Data": " 582 eA0QIvK3hMNUo3d8IxEchavHUltR5O1LUmEnLCcpGL3XROcD_3GtNpvEWgexojbi 583 By4SynEEzCGpRzyFoioPB1Fk2yrA_c74YxRYc4OuFryF9CgrbshEMHi-I9Szip1i 584 Lr6_NDwifiMAUH4KZEwj6TyVCh0zMHWtYY6T_itwdbZhOdxsSxITn4xBEUEzQs3w 585 mSJ5pRbhguaotJ_Vexv87eYlmn-nKrh9w99hVsNFWm2pVmWMgMF__Q_xGWpf4y_Z 586 S4Bko6jpHqY6MA_JjSBxrKXP2FG1JNCe-10I1Oohdtt7z3i1pi9nYb0opPL1pmj2 587 6uXHRYO8hy0oewXEdHP_zg"}, 588 "Support": [{ 589 "ContentType": "application/pkix-cert", 590 "Data": " 591 4IvLI64hE-6_UxpMD_GUkyJLjGlq3Hz9i7G8kOJkn6kSjqyWmy_MGLN57dDGnK7D 592 z9DJYjSHbPk6SaX3r6_ye5YSxyuVF2duQACtH4Bd3icq_QpfiuXB-l8c5QTJe60u 593 ZZgVsGhzpagNpIUEb4VlPVIuQ4ZdV-yxLWhYM28ibzhHMfxNo6YOw-Xa7ySujry4 594 kr-ojsARBcS6jys6-k0_KUH8WPkIeiBisNQI7c4IwhgCE1DJqZRfIEB4fTjLWV3- 595 frOuuY6Y1cz_whODCgn68phD2D6eFuPyiJncU6WrFxF_aQibTQ9C7C61SWtloM5r 596 ASUBjY-bD9_iCppEtHxzoA"}, 597 { 598 "ContentType": "application/pkix-cert", 599 "Data": " 600 LP9gFTTrsaeA_y9GqH_3eNiIbVR6H3HPhEIgu0UlWIKQoy_PeQB3JsOCd5O2Ra2S 601 HnPBMG4aRCVBU8MOTk27L9t4jvHbIy0kC0Ja4hm5yedkcG8sPhFZkHIOmhLhuaNT 602 bdLWFIUkvus420fl6gw1DU9n1H9vCbxG21SXet7iEhXQ9e8tA_i_9046NuS1CwTG 603 kpX0JJqrHHiZ6GQ3kKcn5PAdZkWiMAHReSATeD8GblAwXCkvguvVodMRV84n7gp4 604 JMuUnpKbtpZ_x0ycbG6LhwjmXyT_GzAYtjmSFXsS1shzNkmTYLbus1QFDVWaVPFk 605 AFwfthWawhaYBj0JWiAA0A"}, 606 { 607 "ContentType": "application/pkix-cert", 608 "Data": " 609 DInUnJXe53hXiwrrWEyZPOlKsjzEYnhN_eVIGkArTjR9L7WQ32jY1Mt6sfnQsYiM 610 cRfqANQd3tVLRKnyNQYJaU1MkNmOC7OLSLbWW4XBFxQaCk__T0IoDMxTP4Ol0uUW 611 EVo47OkUMnteOQ21qhBBW415fB2S_WN-UdB3ILzW8jfdNPVy1ctn5XjcaV_WfTPY 612 goUCtuJbULrB17LzmAYkNTdIny2uQs6vO8kogQH1jTw0WYb24NB_iO0tIw8gwRXb 613 iVb3cKH46ywNq4B2BjVcQw5UE_-Q-FMfArKTGg7Z0Oobg3VeOuX_3tC1_wRmnZjy 614 lGLHTGi5yU5nOVranbCuIQ"}, 615 { 616 "ContentType": "application/ocsp-response", 617 "Data": " 618 iyqwOV3TFQE7e0KIPgtDZ0_rMPZSB0rnSBjII_07JwuJjPYpBv6R8U6uK4vJwHOy 619 mxCBQLwa8ZQf9wLUAXwaz1H0bN7vKRZgIoZsTrT96KHRVj1i867zS70ZZg0nH9X9 620 1dwuv_n7KUEmwoUqFX4x9B2Ug3z1TPv-iLjkpPyWz4g"}, 621 { 622 "ContentType": "application/ocsp-response", 623 "Data": " 624 BYAKOKAi9fD3tni3pUKZxHfiBv0ICo9ULKBMiwPOGpGRVomwuawD-D-P4uDnEvXS 625 3mSa3fQ_fz2tw7fOCMrG3n16Yj0NCc4X8GHn49hRRTfzywsgybTxMitgSrXGh4us 626 Qao5gsnlR-Zo4oT2I1wWP1P9CrJY3KcGrSPpu40HD-4"}, 627 { 628 "ContentType": "application/ocsp-response", 629 "Data": " 630 MqSNwx7iFJomrYmB6bo600I5rbEchtbQrkzyBZt7ZW79RI1NRZMN9tkYif4b_Gby 631 QNLNk3eY6WhooU7Yl9boIoQYas-SY7s8Njp4gQmIjk2nPNKNNn2qtrVbfYRtxEIg 632 Nm3zJy9CtdyU87zQxXG-oG29FBG-hAQjmNtEes4xgtU"}, 633 { 634 "ContentType": "application/ocsp-response", 635 "Data": " 636 J5vbsOlkSk4S7CasMzjQOW5C4QXJXjztHP_MaGMvWF0C4CQxZkn_6lmIENuro2gv 637 ew3LTTvAv4ljESkcBP1iT7fGcQBE621ZO_8_RLn8XtDFmUyWvayguhvuhp4mwuL4 638 fFYXvwdWWVt_15X1HL1uCaOyXA88SQpjpxGN8ZuAtBc"}, 639 { 640 "ContentType": "application/pkcs-12", 641 "Data": " 642 PUu_AzFikCBEYq1jB4d5pxCEsnvhq9iW4sXwf--3E8n-qr7HPEWXU2HWqtTjXA0E 643 1NQDWhJrxFM-o-EK1_gVGXKuSaGjndRVUm1p0ec-Vb5C5EBD4a0509ky0JaT1iMT 644 O-sCgBWkfHd-SOjSCbZxpTVZX_na3M0D12uoKCRDJcc39bDWebKrw3IEoJPFbuEn 645 PzGMmoYcs6cVpSl18BCj6t6-rZTSyIVk11NBuhZZ8CotbmdcqKs4_ORaufBgzNzd 646 o9rE-84MCBh-H3IkNZTuuakWOngdgSPkiOUuDd7k7YK-JNXwpDFWJeTiNxJiLOKE 647 vzPo8alcstgdnnb9dVu6uIz_-SXNMj7L5N3iuNRx8ZgWIaCVRDes6HuLqnEZXL-a 648 B1ZxUUvTPs-DUoNndpjsy5k5T1lwLuw7zCevqEBkxb1WpX4T8QBlDpLq1xjxW7tC 649 LUJyrCTRNrAP2t0OMo8z32_V3UZ5Qd5dwTELCfMqUAbDj9dZsKK4mhcdE6hArkr0 650 _XkzrIcL"}]}} 652 3.4. Request Network Configuration 654 Configuring a network server typically requires an administrator to 655 perform several tasks: 657 * Assign an IP address to the server. 659 * Configure the firewall to accept incomming traffic and direct 660 it to the server. 662 * Assign a DNS address to the server. 664 * Configure the server to accept connections at the chosen DNS 665 address. 667 * Configure the relevant authoritative DNS server to publish the 668 server records for the chosen DNS address. 670 * Update local LDAP directories. 672 While each individual step is straightforward, any error or 673 inconsistency introduced may cause the configuration to fail or 674 worse, succeed unreliably. Diagnosing and correcting such errors is 675 one of the principal challenges in network administration. 677 Delegating responsibility for the network configuration to a service 678 enables the configuration to be performed automatically and separates 679 the configuration of the network from the configuration of the 680 servers and services that use the network. This approach greatly 681 simplifies deployment of complex network changes and makes major 682 changes possible without interruption of service. 684 3.4.1. Example: Coffe Pot Service Registration. 686 Having deployed an infrastructure to automate management of his PKI 687 credentials, Bob can leverage the same infrastructure to automate 688 network configuration tasks as well. 690 The coffee pot establishes a service connection using the out of band 691 authentication technique described in [I-D.hallambaker-wsconnect]. 692 Having established the service connection, the coffee pot requests 693 advertisement of the brew-coffee Web service as follows: 695 POST /.well-known/omni-publish/ HTTP/1.1 696 Content-Type: application/json;charset=UTF-8 697 Cache-Control: no-store 698 Session: Value=cWUCjw6DTbyS8o1jkKSfLsJWb_8icI_HTb1Tpb80FJo; 699 Id=vVuUnw2Pi0xlHB2OFnbOBTDmLn9qC1HhEjUkJMHfCtBZRCPXc1GzPw8TLm1b 700 8asS-GCtD8H681WvoGW0DcEgNMDUc0UZu-ZPo_wA9f8f-bk 701 Host: localhost:8080 702 Content-Length: 313 703 Expect: 100-continue 705 { 706 "AdvertiseRequest": { 707 "Service": [{ 708 "Identifier": [{ 709 "Name": "Example.com", 710 "Service": "_make_coffee._wks."}], 711 "Connection": { 712 "IPAddress": "10.1.2.3", 713 "IPPort": 666, 714 "Transport": "TLS", 715 "TransportPolicy": "TLS=Required"}}]}} 717 The advertisement request succeeds and the OmniPublish service 718 reports the successful outcome: 720 POST /.well-known/omni-publish/ HTTP/1.1 721 Content-Type: application/json;charset=UTF-8 722 Cache-Control: no-store 723 Session: Value=cWUCjw6DTbyS8o1jkKSfLsJWb_8icI_HTb1Tpb80FJo; 724 Id=vVuUnw2Pi0xlHB2OFnbOBTDmLn9qC1HhEjUkJMHfCtBZRCPXc1GzPw8TLm1b 725 8asS-GCtD8H681WvoGW0DcEgNMDUc0UZu-ZPo_wA9f8f-bk 726 Host: localhost:8080 727 Content-Length: 313 728 Expect: 100-continue 730 { 731 "AdvertiseRequest": { 732 "Service": [{ 733 "Identifier": [{ 734 "Name": "Example.com", 735 "Service": "_make_coffee._wks."}], 736 "Connection": { 737 "IPAddress": "10.1.2.3", 738 "IPPort": 666, 739 "Transport": "TLS", 740 "TransportPolicy": "TLS=Required"}}]}} 742 In this instance the OmniPublish service has granted the coffee pot a 743 48 hour lease on the service advertisement which must be renewed 744 before expiry. In this case the publication request requires updates 745 to the DNS service which will take some time to propagate. An 746 estimate of the time required to complete publication is returned. 748 4. OBPPublish 750 The OmniPublish protocol is a Web service that a network service or 751 peer calls as a client to advertise the availability of a service and 752 to obtain necessary cryptographic credentials. 754 4.1. OBPPublish Transactions 756 4.1.1. Advertise 758 * Request: AdvertiseRequest 760 * Response: AdvertiseResponse 762 Advises a broker that one or more Internet services are being offered 763 with particular attributes. 765 4.1.2. Credential 767 * Request: CredentialRequest 769 * Response: CredentialResponse 771 Request issue of a cryptographic credential and (optionally) generate 772 a public keypair 774 4.1.3. Notify 776 * Request: NotifyRequest 778 * Response: NotifyResponse 780 Notify the publication service that a server state transition has 781 occurred or is planned. 783 4.2. OBPPublish Messages 785 4.2.1. Message: PResponse 787 Every Query Response contains the following common elements: 789 Status : 790 Integer [1..1] Status return code value 792 StatusDescription : 793 String [0..1] Describes the status code (ignored by processors) 795 4.2.2. Message: AdvertiseRequest 797 Specifies the connection(s) to be established. 799 The attributes required depend on the infrastructure(s) that the 800 broker is capable of registering the service with. 802 Service : 803 OBPQuery.Service [0..Many] Describes a connection to be 804 established. 806 4.2.3. Message: AdvertiseResponse 808 Specifies the connection(s) 810 Status : 811 Integer [1..1] Status return code value 813 StatusDescription : 814 String [0..1] Describes the status code (ignored by processors) 816 Service : 817 OBPQuery.Service [0..Many] Describes a connection that was 818 established. 820 4.2.4. Message: CredentialRequest 822 Request issue of a cryptographic credential and (optionally) generate 823 a public keypair. 825 SubjectIdentifier : 826 String [0..1] The DNS domain or [!RFC2822] account for which 827 the credential is requested. 829 Authentication : 830 TaggedBinary [0..1] Data required by the credential issuer to 831 authenticate the request. For example a Certificate Signing 832 Request [!RFC2986]. 834 MakePrivateKey : 835 Boolean [0..1] If true, requests that a private keypair be 836 generated and the private component returned to the requestor. 838 ResponseTypes : 839 String [0..Many] Types of data requested in response. 841 4.2.5. Message: CredentialResponse 843 Returns issued cryptographic credentials. 845 Status : 846 Integer [1..1] Status return code value 848 StatusDescription : 849 String [0..1] Describes the status code (ignored by processors) 851 Credential : 852 TaggedBinary [0..1] The requested credential type, typically a 853 PKIX End Entity certificate. 855 Support : 856 TaggedBinary [0..Many] Supporting data for the issued 857 credential. For example one or more chains of certificate 858 signing certificates, OCSP [!RFC6960] tokens etc. 860 SecretKey : 861 TaggedBinary [0..1] The secret key for the requested credential 862 (if requested). 864 Expires : 865 DateTime [0..1] The time at which the credential will cease to 866 be accepted by relying parties. 868 EarliestRenewal : 869 DateTime [0..1] The earliest time at which the issuer will 870 accept renewal. 872 LatestRenewal : 873 DateTime [0..1] The latest time at which the issuer suggests 874 requesting renewal. 876 4.2.6. Message: NotifyRequest 878 CurrentState : 879 String [0..1] Current state of the requestor 881 NextState : 882 String [0..1] State that the Requestor plans to enter 884 Earliest : 885 DateTime [0..1] Earliest time at which the transition is 886 expected to complete 888 Latest : 889 DateTime [0..1] Latest time at which the transition is expected 890 to complete 892 4.2.7. Message: NotifyResponse 894 Status : 895 Integer [1..1] Status return code value 897 StatusDescription : 898 String [0..1] Describes the status code (ignored by processors) 900 4.3. OBPPublish Structures 902 4.3.1. Structure: TaggedBinary 904 A sequence of values of the same type. 906 ContentType : 907 String [0..1] MIME Content Type of Data 909 Data : 910 Binary [0..1] Opaque binary data 912 5. Transport Bindings and Identifiers 914 The transport binding options for Omnibroker Publication are 915 identical to those offered for Omnibroker Discovery [I-D.hallambaker- 916 omnibroker]. 918 5.1. Content-Type Identifiers 920 The following content identifiers are defined elsewhere and repeated 921 here for the convenience of implementers. 923 application/ocsp-response 924 OCSP Response token as specified in [!RFC6090]. 926 application/pkix-cert 927 A single DER encoded PKIX Certificate as specified in 928 [!RFC5280]. 930 TBS 931 A Certificate Transparency notary chain as specified in 932 [~RFC6962]. 934 application/pkcs-12 935 A PKCS#12 encrypted private key. 937 6. Acknowledgements 939 Rob Stradling, Robin Alden... 941 7. Security Considerations 943 7.1. Denial of Service 945 7.2. Breach of Trust 947 7.3. Coercion 949 8. IANA Considerations 951 [TBS list out all the code points that require an IANA registration] 953 9. References 955 9.1. Normative References 957 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 958 Requirement Levels", BCP 14, RFC 2119, March 1997. 960 [I-D.hallambaker-omnibroker] Hallam-Baker, P, "OmniBroker Protocol", 961 Internet-Draft draft-hallambaker-omnibroker-07, 21 January 962 2014. 964 [I-D.hallambaker-wsconnect] Hallam-Baker, P, "JSON Service Connect 965 (JCX) Protocol", Internet-Draft draft-hallambaker- 966 wsconnect-05, 21 January 2014. 968 [RFC2986] Nystrom, M.,Kaliski, B., "PKCS #10: Certification Request 969 Syntax Specification Version 1.7", RFC 2986, November 970 2000. 972 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 973 2001. 975 [RFC6960] Santesson, S.,Myers, M.,Ankney, R.,Malpani, A.,Galperin, 976 S.,Adams, C., "X.509 Internet Public Key Infrastructure 977 Online Certificate Status Protocol - OCSP", RFC 6960, June 978 2013. 980 [RFC6090] McGrew, D.,Igoe, K.,Salter, M., "Fundamental Elliptic 981 Curve Cryptography Algorithms", RFC 6090, February 2011. 983 [RFC5280] Cooper, D.,Santesson, S.,Farrell, S.,Boeyen, S.,Housley, 984 R.,Polk, W., "Internet X.509 Public Key Infrastructure 985 Certificate and Certificate Revocation List (CRL) 986 Profile", RFC 5280, May 2008. 988 9.2. Informative References 990 [RFC6962] Laurie, B.,Langley, A.,Kasper, E., "Certificate 991 Transparency", RFC 6962, June 2013. 993 Author's Address 995 Phillip Hallam-Baker 996 Comodo Group Inc. 998 philliph@comodo.com