idnits 2.17.1 draft-hallambaker-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 -- The document date (May 21, 2014) is 3621 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 224, but not defined == Unused Reference: 'RFC6960' is defined on line 945, but no explicit reference was found in the text == Unused Reference: 'RFC2822' is defined on line 950, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 953, but no explicit reference was found in the text == Unused Reference: 'RFC6090' is defined on line 958, but no explicit reference was found in the text == Unused Reference: 'RFC6962' is defined on line 978, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Downref: Normative reference to an Informational RFC: RFC 6090 == Outdated reference: A later version (-08) exists of draft-hallambaker-omnibroker-07 ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-08) exists of draft-hallambaker-wsconnect-05 -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 3 errors (**), 0 flaws (~~), 9 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: Standards Track May 21, 2014 4 Expires: November 22, 2014 6 OmniBroker Publication Protocol 7 draft-hallambaker-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) 2014 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: AdvertiseRequest . . . . . . . . . . . . . 16 70 4.2.2. Message: AdvertiseResponse . . . . . . . . . . . . . 17 71 4.2.3. Message: CredentialRequest . . . . . . . . . . . . . 17 72 4.2.4. Message: CredentialResponse . . . . . . . . . . . . 17 73 4.2.5. Message: NotifyRequest . . . . . . . . . . . . . . . 18 74 4.2.6. Message: NotifyResponse . . . . . . . . . . . . . . 18 75 4.3. OBPPublish Structures . . . . . . . . . . . . . . . . . . 18 76 4.3.1. Structure: TaggedBinary . . . . . . . . . . . . . . 18 77 5. Transport Bindings and Identifiers . . . . . . . . . . . . . . 19 78 5.1. Content-Type Identifiers . . . . . . . . . . . . . . . . 19 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 7.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 19 82 7.2. Breach of Trust . . . . . . . . . . . . . . . . . . . . . 19 83 7.3. Coercion . . . . . . . . . . . . . . . . . . . . . . . . 19 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 87 9.2. Informative References . . . . . . . . . . . . . . . . . 20 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 1. Definitions 92 1.1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. Introduction 100 OmniPublish is a Web Service that supports server configuration 101 management. The supported transaction set allows a server to obtain 102 and renew necessary cryptographic credentials, publish service 103 discovery statements and obtain network configuration specifications. 105 The services supported by OmniPublish are complimentary to the 106 services provided by OmniBroker [I-D.hallambaker-omnibroker] and the 107 protocols share the same transport binding (HTTP, UYFM) and encoding 108 options (JSON). 110 2.1. Traditional Server Configuration Approach 112 In the traditional approach to server configuration the network 113 administrator is required to anticipate and perform all the necessary 114 configuration needs of the service. For an enterprise server these 115 steps will typically include: 117 * Enter server parameters in the DNS. 119 * Configure firewall to permit external access. 121 * Generate Public/Private Keypair. 123 * Apply for digital certificate. 125 * Install digital certificate. 127 While executing each individual step may be considered 128 straightforward, any configuration task involving five non-trivial 129 human mediated tasks is liable to be error prone. Moreover 130 maintaining the configuration represents an ongoing maintenance 131 effort as certificates expire, network configurations are changed, 132 servers are updated, etc. 134 2.2. Automating network management. 136 In the traditional administration model the human is required to 137 anticipate the needs of the server. Yet the server itself knows its 138 needs with great precision although not necessarily how they are to 139 be realized. 141 A server that is configured to use the TLS protocol knows that a 142 certificate is required and the purposes for which it is to be used. 143 It knows when the certificate is about to expire and requires 144 replacement and when evidence of certificate status (e.g. an OCSP 145 token) requires renewal. 147 Network configuration raises similar considerations except that the 148 information available to a server is typically insufficient to 149 perform network configuration tasks. It is not guaranteed that the 150 local network IP address of a server is the same as the IP address 151 that is visible to the external network. A mechanism in which the 152 server edits DNS entries directly is therefore less functional than 153 one in which the DNS entries are generated by a mediated service that 154 has access to the necessary additional data. 156 Network configuration is an administration function and therefore 157 requires administrative privileges. Accordingly, every OmniPublish 158 request and response is authenticated using credentials established 159 using the SXS-Connect protocol [I-D.hallambaker-wsconnect]. 161 2.2.1. Cloud Computing Requirements. 163 Cloud computing does not necessarily raise new management 164 requirements but the requirements that are raised become more urgent. 165 In the traditional model a service ran on a fixed number of hosts in 166 a configuration that was static for months or years. In a cloud 167 computing environment the number of hosts supporting a service might 168 vary several times in an hour to respond to variations in load. 170 An important consequence of the transient nature of cloud computing 171 is that hosts which provide a service for a few hours or even minutes 172 are issued cryptographic credentials that are valid for a year. 174 3. Omnibroker Publication Service 176 The OmniPublish service is designed to permit services to manage 177 themselves to the greatest extent possible. 179 The features that are most likely to make deployment attractive in 180 the short term are the ability to manage cryptographic credentials 181 including acquisition of public/private keypairs, certificates and 182 certificate status assertions. 184 An enterprise with a large in-house IT department would typically 185 host the Omnipublish service locally. The local service would then be 186 configured to forward publication data to any IT facitilities that 187 happen to be outsourced such as CA services, DNS etc. 189 A similar model may be applied in the home automation environment 190 with devices under management publishing their service information to 191 the local publication server which then forwards the information to 192 external services as necessary. The chief difference between this 193 case and the enterprise case being that the service operation cannot 194 depend on the end user being aware that the device exists, let alone 195 perform configuration. 197 In a pure cloud computing environment the OmniPublish service would 198 have to be outsourced since there is no internal IT system for it to 199 run off. 201 3.1. Service Binding 203 Application establishes a service connection to the OmniPublish 204 service. 206 3.2. Acquiring Cryptographic Credentials 208 One of the chief reasons given for not using cryptographic protocols 209 such as IPSEC, S/MIME and TLS is the difficulty of obtaining or 210 registering the necessary cryptographic credentials. In the case of 211 an Internet protocol this is typically but not always a PKIX 212 certificate bound to a private key held by the the certificate 213 subject. 215 3.2.1. Example: Small Web Site Operator 217 Alice is the owner of a small business that operates a Web site. To 218 protect the privacy of the Web site users, Alice decides to enable 219 TLS on the Web site. Accordingly, Alice selects a Certificate 220 Authority Example CA Inc. that issues a certificate with an 221 appropriate validation requirement for her intended use. 223 Alice provides her contact details to the CA which returns an account 224 identifier alice@example.net and a PIN value [TBS]. 226 The credentials are immediately valid for creating a service 227 connection using the PIN. The Service Connection Ticket is obtained 228 by a Web Server administration tool: 230 POST /.well-known/sxs-connect/ HTTP/1.1 231 Content-Type: application/json;charset=UTF-8 232 Cache-Control: no-store 233 Host: localhost:8080 234 Content-Length: 344 235 Expect: 100-continue 237 { 238 "OpenPINRequest": { 239 "Encryption": ["A128CBC", 240 "A256CBC", 241 "A128GCM", 242 "A256GCM"], 244 "Authentication": ["HS256", 245 "HS384", 246 "HS512", 247 "HS256T128"], 248 "Account": "alice", 249 "Service": ["omni-publish"], 250 "Domain": "example.net", 251 "HaveDisplay": false, 252 "Challenge": " 253 4m7Lzr7g2FzllXcVGeDIOw"}} 255 The service responds with the challenge to be used to validate the 256 PIN: 258 HTTP/1.1 281 Pin code required 259 Content-Length: 511 260 Date: Wed, 21 May 2014 20:05:54 GMT 261 Server: Microsoft-HTTPAPI/2.0 263 { 264 "OpenPINResponse": { 265 "Status": 281, 266 "StatusDescription": "Pin code required", 267 "Challenge": " 268 cHbxV3Uwkb-CYezJhKj-wA", 269 "ChallengeResponse": " 270 98RV4Se7VQIP3FbqcrLKyUth5u6F48dbCGpzrHpkGfQ", 271 "Cryptographic": { 272 "Secret": " 273 e6oSWl3dFfNkpYXvSTvY1w", 274 "Encryption": "A128CBC", 275 "Authentication": "HS256", 276 "Ticket": " 277 V8ae-8uQMtt_uyKJQLbx4umJEpsz--OXVriEHRoq5sw5uq6u1_4tWv8ro7DyD5Su 278 hSpOibX2cOnd0OHSOJpcA1Gs9WjRArqzz0WrD0Inl39d89zbcWoMKYKhlOFFV_LF 279 V8kPPoK8BmaQOxCo3kBrxg"}}} 281 The administration tool completes the request by proving knowledge of 282 the PIN: 284 POST /.well-known/sxs-connect/ HTTP/1.1 285 Content-Type: application/json;charset=UTF-8 286 Cache-Control: no-store 287 Session: Value=J5wXEchUbr7k2A0mvaOEPnr3KGFagzg1vH_MX6W1R14; 288 Id=V8ae-8uQMtt_uyKJQLbx4umJEpsz--OXVriEHRoq5sw5uq6u1_4tWv8ro7Dy 289 D5SuhSpOibX2cOnd0OHSOJpcA1Gs9WjRArqzz0WrD0Inl39d89zbcWoMKYKhlOF 290 FV_LFV8kPPoK8BmaQOxCo3kBrxg 291 Host: localhost:8080 292 Content-Length: 129 293 Expect: 100-continue 294 { 295 "TicketRequest": { 296 "Service": ["omni-publish"], 297 "ChallengeResponse": " 298 49GCx5HUvU2SNE6M3GuKcxgFfvZKDLpTfpqXUOAGXVE"}} 300 The Connection service returns the OmniPublish connection parameters: 302 HTTP/1.1 OK Success 303 Content-Length: 1306 304 Date: Wed, 21 May 2014 20:05:54 GMT 305 Server: Microsoft-HTTPAPI/2.0 307 { 308 "TicketResponse": { 309 "Status": 200, 310 "StatusDescription": "Success", 311 "Cryptographic": [{ 312 "Protocol": "sxs-connect", 313 "Secret": " 314 DOdZw6ynGANAjqnR-1gL0A", 315 "Encryption": "A128CBC", 316 "Authentication": "HS256", 317 "Ticket": " 318 Ay9sUcNcC0GH9cY5NiRFcrqjFL0wTgTn69uO9SUPvP_XqB05yJ_fLqeI622H-bBu 319 klDhb1TpUGwQMAgNNwRkgsu97Dc38WBfUiyetM0TwYY"}], 320 "Service": [{ 321 "Service": "omni-publish", 322 "Name": "localhost", 323 "Port": 8080, 324 "Priority": 100, 325 "Weight": 100, 326 "Transport": "HTTP", 327 "Cryptographic": { 328 "Secret": " 329 LfRHVDFWVkVQu81lI2wT8w", 330 "Encryption": "A128CBC", 331 "Authentication": "HS256T128", 332 "Ticket": " 333 OufJWkZCHmCLVeSuS4Nth4ozUrRfyDa4v8Dd5FIrkIWPQrGnHLgG_6ZmoHQGqIRg 334 7BL7Gm9Jq7LQihkCLhgQjp1LJqpDmDuDFbH5ZRDl7_g"}}, 335 { 336 "Service": "omni-publish", 337 "Name": "localhost", 338 "Port": 9090, 339 "Priority": 100, 340 "Weight": 100, 341 "Transport": "UDP", 342 "Cryptographic": { 343 "Secret": " 344 elODZJePf2UDWW1hHw2-3A", 345 "Encryption": "A128CBC", 346 "Authentication": "HS256T128", 347 "Ticket": " 348 xMn4JDCQIg9WSHTVh1HwdJQq1iBoIHNk-BRHdhq_WGGeWv6cgfDgLYo2-U4BX2IH 349 _SRzZ1fDf5dHzfE67wuPawutwOkemJNH4mOK0XYeNPc"}}]}} 351 The administration tool enters the connection parameters into the 352 server configuration data. At this point all the administrative tasks 353 related to the server are complete and the remainder of the process 354 can be performed automatically. 356 The server begins the process by generating a public key pair and 357 Certificate Signing Request [RFC2986] and requests issue of a 358 certificate with a CredentialRequest: 360 POST /.well-known/omni-publish/ HTTP/1.1 361 Content-Type: application/json;charset=UTF-8 362 Cache-Control: no-store 363 Session: Value=ArwY9yiAOaMjxTx4jE_BzNTNJ5z4Nn-I6gjdZPC5ejI; 364 Id=OufJWkZCHmCLVeSuS4Nth4ozUrRfyDa4v8Dd5FIrkIWPQrGnHLgG_6ZmoHQG 365 qIRg7BL7Gm9Jq7LQihkCLhgQjp1LJqpDmDuDFbH5ZRDl7_g 366 Host: localhost:8080 367 Content-Length: 148 368 Expect: 100-continue 370 { 371 "CredentialRequest": { 372 "Authentication": { 373 "ContentType": "application/pkcs-10", 374 "Data": " 375 AQID"}, 376 "MakePrivateKey": false}} 378 The service accepts the request but the process cannot be completed 379 until the validation process required for the class of certificate 380 has been completed. Accordingly the service returns the status 381 'Pending' and gives an estimated completion time: 383 HTTP/1.1 282 Transaction Incomplete 384 Content-Length: 98 385 Date: Wed, 21 May 2014 20:05:55 GMT 386 Server: Microsoft-HTTPAPI/2.0 388 { 389 "CredentialResponse": { 390 "Status": 282, 391 "StatusDescription": "Transaction Incomplete"}} 393 The validation process completes successfully and the CA issues the 394 certificate. The server requests delivery of the certificate by 395 repeating the CredentialRequest: 397 POST /.well-known/omni-publish/ HTTP/1.1 398 Content-Type: application/json;charset=UTF-8 399 Cache-Control: no-store 400 Session: Value=ArwY9yiAOaMjxTx4jE_BzNTNJ5z4Nn-I6gjdZPC5ejI; 401 Id=OufJWkZCHmCLVeSuS4Nth4ozUrRfyDa4v8Dd5FIrkIWPQrGnHLgG_6ZmoHQG 402 qIRg7BL7Gm9Jq7LQihkCLhgQjp1LJqpDmDuDFbH5ZRDl7_g 403 Host: localhost:8080 404 Content-Length: 148 405 Expect: 100-continue 407 { 408 "CredentialRequest": { 409 "Authentication": { 410 "ContentType": "application/pkcs-10", 411 "Data": " 412 AQID"}, 413 "MakePrivateKey": false}} 415 This time the certificate is ready and is returned to the server. For 416 the convenience of the server software, the response message tells 417 the Web server when the certificate will expire and the earliest and 418 latest dates on which to request renewal: 420 HTTP/1.1 282 Transaction Incomplete 421 Content-Length: 98 422 Date: Wed, 21 May 2014 20:05:55 GMT 423 Server: Microsoft-HTTPAPI/2.0 425 { 426 "CredentialResponse": { 427 "Status": 282, 428 "StatusDescription": "Transaction Incomplete"}} 430 Note that the certificate returned is a short lifetime certificate 431 that is only valid for a 72 hour interval, 24 hours of which have 432 already elapsed at issue time. Use of short lived certificates is 433 generally accepted as being highly desirable as it eliminates the 434 need for certificate status reporting. The certificates issued will 435 expire at the same time that any static status report would. The 436 chief objection to the use of short lived certificates has been the 437 need for daily administrative intervention. Automating the process of 438 updating the certificate eliminates this objection. 440 In addition to eliminating the need to track revocation status 441 separately, performing certificate updates on a daily basis is 442 potentially more reliable than one that is only activated once a 443 year. Network changes that prevent a an update completing 444 successfully have immediate impact at a time the network 445 administration is looking for potential problems rather than being 446 discovered up to a year later when the personel who caused the change 447 may have been reassigned or left the company. 449 The server MAY apply for renewal of the certificate at any time after 450 the earliest date specified in the issue statement. If no request is 451 made by the time that the latest time has been reached, the issuing 452 CA MAY begin attempting to contact their customer to determine the 453 cause. To avoid unnecessary warning messages from the CA (and 454 possibly additional invoices for unused services) the server may 455 inform the CA that certificate updates will not be required for an 456 extended period using the Notify method: 458 POST /.well-known/omni-publish/ HTTP/1.1 459 Content-Type: application/json;charset=UTF-8 460 Cache-Control: no-store 461 Session: Value=wFsqI6wkH-TuCyGkIOjL3TJsbkvJCXxdHGohugk0hx0; 462 Id=vVuUnw2Pi0xlHB2OFnbOBTDmLn9qC1HhEjUkJMHfCtBZRCPXc1GzPw8TLm1b 463 8asS-GCtD8H681WvoGW0DcEgNMDUc0UZu-ZPo_wA9f8f-bk 464 Host: localhost:8080 465 Content-Length: 129 466 Expect: 100-continue 468 { 469 "NotifyRequest": { 470 "NextState": "Offline", 471 "Earliest": "2014-05-21T20:05:56Z", 472 "Latest": "2014-05-21T20:06:56Z"}} 474 3.2.2. Example: Large Enterprise 476 Since Alice only operates one Web server, the simplest management 477 solution for her is for the Web server to establish a direct 478 connection to the CA. In a large enterprise with several hundred 479 servers, a centralized management approach which allows 480 configurations to be applied to groups of servers as a unit is 481 usually required. 483 To support this configuration, Bob deploys a local OmniPublish 484 service in his network. Every machine that Bob manages connects to 485 his local OmniPublish service to obtain its cryptographic 486 credentials. The local OmniPublish service connects to the 487 OmniPublish service of the CA to these service requests: 489 +----------+ 490 | Machine 1|--+ 491 +----------+ | 492 | 493 +----------+ | +----------+ +----------+ 494 | Machine 2|--+-->| Local OP |---------->| CA OP | 495 +----------+ | +----------+ +----------+ 496 | 497 +----------+ | 498 | Machine 3|--+ 499 +----------+ 501 3.3. Generating or Obtaining a Public/Private KeyPair. 503 Conventional wisdom holds that public/private key pairs should be 504 generated on the host on which they are to be used and exist in no 505 other location. 507 In practice, this mode of operation is not always the most desirable. 508 In the case of keypairs to be used for encryption of static data, the 509 decryption key must be available to all the machines that need 510 decryption capabilities. 512 Key generation procedures for public key algorithms can be lengthy. 513 While a delay of a few seconds or even a few minutes is acceptable in 514 a one-time server configuration process, introducing such a delay 515 into server startup is frequently unacceptable. 517 Experience of operating cryptographic systems has proved that correct 518 and secure implementation of key generation capabilities is beyond 519 the capabilities of many programmers. Random seeds are frequently 520 generated with insufficient entropy. In some cases entropy is leaked 521 after the seed is used to generate the private key. 523 For the above reasons, it is frequently but not always desirable to 524 perform generation of public/private keypairs as a centralized 525 service supported by a small number of machines that can be tightly 526 controlled an audited. 528 3.3.1. Example: Internet Coffee Pot 530 Bob buys a new coffee pot for his office that supports the 531 hypothetical 'Ready to Brew' Web Service that allows the machine to 532 be instructed to brew a cup of fresh coffee. Since this is an 533 important and security sensitive function, the coffee pot supports 534 use of the TLS protocol but the control hardware does not have access 535 to a suitible source of randomness for generating a public keypair. 537 To meet this need the coffee pot simply requests that the OmniPublish 538 service generate a keypair on its behalf and return the private key 539 with the certificate. Note that since Bob has bound the coffee pot to 540 his local omnibroker service rather than a service provided by a 541 public CA, Bob still exercises full control over generation of 542 public/private keypairs. He is simply choosing to generate the 543 keypair in a different place. 545 [TBS: provide a DH exchange to enable an application level guarantee 546 that the private key is delivered under a sound encryption scheme] 548 POST /.well-known/omni-publish/ HTTP/1.1 549 Content-Type: application/json;charset=UTF-8 550 Cache-Control: no-store 551 Session: Value=tKs0Y7AGoqfFtZDIUh395TlbIU2E6ciO2beA4lnBtgs; 552 Id=vVuUnw2Pi0xlHB2OFnbOBTDmLn9qC1HhEjUkJMHfCtBZRCPXc1GzPw8TLm1b 553 8asS-GCtD8H681WvoGW0DcEgNMDUc0UZu-ZPo_wA9f8f-bk 554 Host: localhost:8080 555 Content-Length: 147 556 Expect: 100-continue 558 { 559 "CredentialRequest": { 560 "Authentication": { 561 "ContentType": "application/pkcs-10", 562 "Data": " 563 AQID"}, 564 "MakePrivateKey": true}} 566 The service accepts the request and returns the requested 567 credentials: 569 HTTP/1.1 OK Success 570 Content-Length: 3426 571 Date: Wed, 21 May 2014 20:05:55 GMT 572 Server: Microsoft-HTTPAPI/2.0 574 { 575 "CredentialResponse": { 576 "Status": 200, 577 "StatusDescription": "Success", 578 "Credential": { 579 "ContentType": "application/pkix-cert", 580 "Data": " 581 eA0QIvK3hMNUo3d8IxEchavHUltR5O1LUmEnLCcpGL3XROcD_3GtNpvEWgexojbi 582 By4SynEEzCGpRzyFoioPB1Fk2yrA_c74YxRYc4OuFryF9CgrbshEMHi-I9Szip1i 583 Lr6_NDwifiMAUH4KZEwj6TyVCh0zMHWtYY6T_itwdbZhOdxsSxITn4xBEUEzQs3w 584 mSJ5pRbhguaotJ_Vexv87eYlmn-nKrh9w99hVsNFWm2pVmWMgMF__Q_xGWpf4y_Z 585 S4Bko6jpHqY6MA_JjSBxrKXP2FG1JNCe-10I1Oohdtt7z3i1pi9nYb0opPL1pmj2 586 6uXHRYO8hy0oewXEdHP_zg"}, 587 "Support": [{ 588 "ContentType": "application/pkix-cert", 589 "Data": " 590 4IvLI64hE-6_UxpMD_GUkyJLjGlq3Hz9i7G8kOJkn6kSjqyWmy_MGLN57dDGnK7D 591 z9DJYjSHbPk6SaX3r6_ye5YSxyuVF2duQACtH4Bd3icq_QpfiuXB-l8c5QTJe60u 592 ZZgVsGhzpagNpIUEb4VlPVIuQ4ZdV-yxLWhYM28ibzhHMfxNo6YOw-Xa7ySujry4 593 kr-ojsARBcS6jys6-k0_KUH8WPkIeiBisNQI7c4IwhgCE1DJqZRfIEB4fTjLWV3- 594 frOuuY6Y1cz_whODCgn68phD2D6eFuPyiJncU6WrFxF_aQibTQ9C7C61SWtloM5r 595 ASUBjY-bD9_iCppEtHxzoA"}, 596 { 597 "ContentType": "application/pkix-cert", 598 "Data": " 599 LP9gFTTrsaeA_y9GqH_3eNiIbVR6H3HPhEIgu0UlWIKQoy_PeQB3JsOCd5O2Ra2S 600 HnPBMG4aRCVBU8MOTk27L9t4jvHbIy0kC0Ja4hm5yedkcG8sPhFZkHIOmhLhuaNT 601 bdLWFIUkvus420fl6gw1DU9n1H9vCbxG21SXet7iEhXQ9e8tA_i_9046NuS1CwTG 602 kpX0JJqrHHiZ6GQ3kKcn5PAdZkWiMAHReSATeD8GblAwXCkvguvVodMRV84n7gp4 603 JMuUnpKbtpZ_x0ycbG6LhwjmXyT_GzAYtjmSFXsS1shzNkmTYLbus1QFDVWaVPFk 604 AFwfthWawhaYBj0JWiAA0A"}, 605 { 606 "ContentType": "application/pkix-cert", 607 "Data": " 608 DInUnJXe53hXiwrrWEyZPOlKsjzEYnhN_eVIGkArTjR9L7WQ32jY1Mt6sfnQsYiM 609 cRfqANQd3tVLRKnyNQYJaU1MkNmOC7OLSLbWW4XBFxQaCk__T0IoDMxTP4Ol0uUW 610 EVo47OkUMnteOQ21qhBBW415fB2S_WN-UdB3ILzW8jfdNPVy1ctn5XjcaV_WfTPY 611 goUCtuJbULrB17LzmAYkNTdIny2uQs6vO8kogQH1jTw0WYb24NB_iO0tIw8gwRXb 612 iVb3cKH46ywNq4B2BjVcQw5UE_-Q-FMfArKTGg7Z0Oobg3VeOuX_3tC1_wRmnZjy 613 lGLHTGi5yU5nOVranbCuIQ"}, 614 { 615 "ContentType": "application/ocsp-response", 616 "Data": " 617 iyqwOV3TFQE7e0KIPgtDZ0_rMPZSB0rnSBjII_07JwuJjPYpBv6R8U6uK4vJwHOy 618 mxCBQLwa8ZQf9wLUAXwaz1H0bN7vKRZgIoZsTrT96KHRVj1i867zS70ZZg0nH9X9 619 1dwuv_n7KUEmwoUqFX4x9B2Ug3z1TPv-iLjkpPyWz4g"}, 620 { 621 "ContentType": "application/ocsp-response", 622 "Data": " 623 BYAKOKAi9fD3tni3pUKZxHfiBv0ICo9ULKBMiwPOGpGRVomwuawD-D-P4uDnEvXS 624 3mSa3fQ_fz2tw7fOCMrG3n16Yj0NCc4X8GHn49hRRTfzywsgybTxMitgSrXGh4us 625 Qao5gsnlR-Zo4oT2I1wWP1P9CrJY3KcGrSPpu40HD-4"}, 626 { 627 "ContentType": "application/ocsp-response", 628 "Data": " 629 MqSNwx7iFJomrYmB6bo600I5rbEchtbQrkzyBZt7ZW79RI1NRZMN9tkYif4b_Gby 630 QNLNk3eY6WhooU7Yl9boIoQYas-SY7s8Njp4gQmIjk2nPNKNNn2qtrVbfYRtxEIg 631 Nm3zJy9CtdyU87zQxXG-oG29FBG-hAQjmNtEes4xgtU"}, 632 { 633 "ContentType": "application/ocsp-response", 634 "Data": " 635 J5vbsOlkSk4S7CasMzjQOW5C4QXJXjztHP_MaGMvWF0C4CQxZkn_6lmIENuro2gv 636 ew3LTTvAv4ljESkcBP1iT7fGcQBE621ZO_8_RLn8XtDFmUyWvayguhvuhp4mwuL4 637 fFYXvwdWWVt_15X1HL1uCaOyXA88SQpjpxGN8ZuAtBc"}, 638 { 639 "ContentType": "application/pkcs-12", 640 "Data": " 641 PUu_AzFikCBEYq1jB4d5pxCEsnvhq9iW4sXwf--3E8n-qr7HPEWXU2HWqtTjXA0E 642 1NQDWhJrxFM-o-EK1_gVGXKuSaGjndRVUm1p0ec-Vb5C5EBD4a0509ky0JaT1iMT 643 O-sCgBWkfHd-SOjSCbZxpTVZX_na3M0D12uoKCRDJcc39bDWebKrw3IEoJPFbuEn 644 PzGMmoYcs6cVpSl18BCj6t6-rZTSyIVk11NBuhZZ8CotbmdcqKs4_ORaufBgzNzd 645 o9rE-84MCBh-H3IkNZTuuakWOngdgSPkiOUuDd7k7YK-JNXwpDFWJeTiNxJiLOKE 646 vzPo8alcstgdnnb9dVu6uIz_-SXNMj7L5N3iuNRx8ZgWIaCVRDes6HuLqnEZXL-a 647 B1ZxUUvTPs-DUoNndpjsy5k5T1lwLuw7zCevqEBkxb1WpX4T8QBlDpLq1xjxW7tC 648 LUJyrCTRNrAP2t0OMo8z32_V3UZ5Qd5dwTELCfMqUAbDj9dZsKK4mhcdE6hArkr0 649 _XkzrIcL"}]}} 651 3.4. Request Network Configuration 653 Configuring a network server typically requires an administrator to 654 perform several tasks: 656 * Assign an IP address to the server. 658 * Configure the firewall to accept incomming traffic and direct 659 it to the server. 661 * Assign a DNS address to the server. 663 * Configure the server to accept connections at the chosen DNS 664 address. 666 * Configure the relevant authoritative DNS server to publish the 667 server records for the chosen DNS address. 669 * Update local LDAP directories. 671 While each individual step is straightforward, any error or 672 inconsistency introduced may cause the configuration to fail or 673 worse, succeed unreliably. Diagnosing and correcting such errors is 674 one of the principal challenges in network administration. 676 Delegating responsibility for the network configuration to a service 677 enables the configuration to be performed automatically and separates 678 the configuration of the network from the configuration of the 679 servers and services that use the network. This approach greatly 680 simplifies deployment of complex network changes and makes major 681 changes possible without interruption of service. 683 3.4.1. Example: Coffe Pot Service Registration. 685 Having deployed an infrastructure to automate management of his PKI 686 credentials, Bob can leverage the same infrastructure to automate 687 network configuration tasks as well. 689 The coffee pot establishes a service connection using the out of band 690 authentication technique described in [I-D.hallambaker-wsconnect]. 691 Having established the service connection, the coffee pot requests 692 advertisement of the brew-coffee Web service as follows: 694 POST /.well-known/omni-publish/ HTTP/1.1 695 Content-Type: application/json;charset=UTF-8 696 Cache-Control: no-store 697 Session: Value=cWUCjw6DTbyS8o1jkKSfLsJWb_8icI_HTb1Tpb80FJo; 698 Id=vVuUnw2Pi0xlHB2OFnbOBTDmLn9qC1HhEjUkJMHfCtBZRCPXc1GzPw8TLm1b 699 8asS-GCtD8H681WvoGW0DcEgNMDUc0UZu-ZPo_wA9f8f-bk 700 Host: localhost:8080 701 Content-Length: 313 702 Expect: 100-continue 704 { 705 "AdvertiseRequest": { 706 "Service": [{ 707 "Identifier": [{ 708 "Name": "Example.com", 709 "Service": "_make_coffee._wks."}], 710 "Connection": { 711 "IPAddress": "10.1.2.3", 712 "IPPort": 666, 713 "Transport": "TLS", 714 "TransportPolicy": "TLS=Required"}}]}} 716 The advertisement request succeeds and the OmniPublish service 717 reports the successful outcome: 719 POST /.well-known/omni-publish/ HTTP/1.1 720 Content-Type: application/json;charset=UTF-8 721 Cache-Control: no-store 722 Session: Value=cWUCjw6DTbyS8o1jkKSfLsJWb_8icI_HTb1Tpb80FJo; 723 Id=vVuUnw2Pi0xlHB2OFnbOBTDmLn9qC1HhEjUkJMHfCtBZRCPXc1GzPw8TLm1b 724 8asS-GCtD8H681WvoGW0DcEgNMDUc0UZu-ZPo_wA9f8f-bk 725 Host: localhost:8080 726 Content-Length: 313 727 Expect: 100-continue 729 { 730 "AdvertiseRequest": { 731 "Service": [{ 732 "Identifier": [{ 733 "Name": "Example.com", 734 "Service": "_make_coffee._wks."}], 735 "Connection": { 736 "IPAddress": "10.1.2.3", 737 "IPPort": 666, 738 "Transport": "TLS", 739 "TransportPolicy": "TLS=Required"}}]}} 741 In this instance the OmniPublish service has granted the coffee pot a 742 48 hour lease on the service advertisement which must be renewed 743 before expiry. In this case the publication request requires updates 744 to the DNS service which will take some time to propagate. An 745 estimate of the time required to complete publication is returned. 747 4. OBPPublish 749 The OmniPublish protocol is a Web service that a network service or 750 peer calls as a client to advertise the availability of a service and 751 to obtain necessary cryptographic credentials. 753 4.1. OBPPublish Transactions 755 4.1.1. Advertise 757 * Request: AdvertiseRequest 759 * Response: AdvertiseResponse 761 Advises a broker that one or more Internet services are being offered 762 with particular attributes. 764 4.1.2. Credential 766 * Request: CredentialRequest 768 * Response: CredentialResponse 770 Request issue of a cryptographic credential and (optionally) generate 771 a public keypair 773 4.1.3. Notify 775 * Request: NotifyRequest 777 * Response: NotifyResponse 779 Notify the publication service that a server state transition has 780 occurred or is planned. 782 4.2. OBPPublish Messages 784 4.2.1. Message: AdvertiseRequest 786 Specifies the connection(s) to be established. 788 The attributes required depend on the infrastructure(s) that the 789 broker is capable of registering the service with. 791 Service : 792 OBPQuery.Service [0..Many] Describes a connection to be 793 established. 795 4.2.2. Message: AdvertiseResponse 797 Specifies the connection(s) 799 Status : 800 Integer [1..1] Status return code value 802 StatusDescription : 803 String [0..1] Describes the status code (ignored by processors) 805 Service : 806 OBPQuery.Service [0..Many] Describes a connection that was 807 established. 809 4.2.3. Message: CredentialRequest 811 Request issue of a cryptographic credential and (optionally) generate 812 a public keypair. 814 SubjectIdentifier : 815 String [0..1] The DNS domain or [!RFC2822] account for which 816 the credential is requested. 818 Authentication : 819 TaggedBinary [0..1] Data required by the credential issuer to 820 authenticate the request. For example a Certificate Signing 821 Request [!RFC2986]. 823 MakePrivateKey : 824 Boolean [0..1] If true, requests that a private keypair be 825 generated and the private component returned to the requestor. 827 ResponseTypes : 828 String [0..Many] Types of data requested in response. 830 4.2.4. Message: CredentialResponse 832 Returns issued cryptographic credentials. 834 Status : 835 Integer [1..1] Status return code value 837 StatusDescription : 838 String [0..1] Describes the status code (ignored by processors) 840 Credential : 841 TaggedBinary [0..1] The requested credential type, typically a 842 PKIX End Entity certificate. 844 Support : 845 TaggedBinary [0..Many] Supporting data for the issued 846 credential. For example one or more chains of certificate 847 signing certificates, OCSP [!RFC6960] tokens etc. 849 SecretKey : 850 TaggedBinary [0..1] The secret key for the requested credential 851 (if requested). 853 Expires : 854 DateTime [0..1] The time at which the credential will cease to 855 be accepted by relying parties. 857 EarliestRenewal : 858 DateTime [0..1] The earliest time at which the issuer will 859 accept renewal. 861 LatestRenewal : 862 DateTime [0..1] The latest time at which the issuer suggests 863 requesting renewal. 865 4.2.5. Message: NotifyRequest 867 CurrentState : 868 String [0..1] Current state of the requestor 870 NextState : 871 String [0..1] State that the Requestor plans to enter 873 Earliest : 874 DateTime [0..1] Earliest time at which the transition is 875 expected to complete 877 Latest : 878 DateTime [0..1] Latest time at which the transition is expected 879 to complete 881 4.2.6. Message: NotifyResponse 883 Status : 884 Integer [1..1] Status return code value 886 StatusDescription : 887 String [0..1] Describes the status code (ignored by processors) 889 4.3. OBPPublish Structures 891 4.3.1. Structure: TaggedBinary 893 A sequence of values of the same type. 895 ContentType : 896 String [0..1] MIME Content Type of Data 898 Data : 899 Binary [0..1] Opaque binary data 901 5. Transport Bindings and Identifiers 903 The transport binding options for Omnibroker Publication are 904 identical to those offered for Omnibroker Discovery [I-D.hallambaker- 905 omnibroker]. 907 5.1. Content-Type Identifiers 909 The following content identifiers are defined elsewhere and repeated 910 here for the convenience of implementers. 912 application/ocsp-response 913 OCSP Response token as specified in [!RFC6090]. 915 application/pkix-cert 916 A single DER encoded PKIX Certificate as specified in 917 [!RFC5280]. 919 TBS 920 A Certificate Transparency notary chain as specified in 921 [~RFC6962]. 923 application/pkcs-12 924 A PKCS#12 encrypted private key. 926 6. Acknowledgements 928 Rob Stradling, Robin Alden... 930 7. Security Considerations 932 7.1. Denial of Service 934 7.2. Breach of Trust 936 7.3. Coercion 937 8. IANA Considerations 939 [TBS list out all the code points that require an IANA registration] 941 9. References 943 9.1. Normative References 945 [RFC6960] Santesson, S.,Myers, M.,Ankney, R.,Malpani, A.,Galperin, 946 S.,Adams, C., "X.509 Internet Public Key Infrastructure 947 Online Certificate Status Protocol - OCSP", RFC 6960, June 948 2013. 950 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 951 2001. 953 [RFC5280] Cooper, D.,Santesson, S.,Farrell, S.,Boeyen, S.,Housley, 954 R.,Polk, W., "Internet X.509 Public Key Infrastructure 955 Certificate and Certificate Revocation List (CRL) 956 Profile", RFC 5280, May 2008. 958 [RFC6090] McGrew, D.,Igoe, K.,Salter, M., "Fundamental Elliptic 959 Curve Cryptography Algorithms", RFC 6090, February 2011. 961 [I-D.hallambaker-omnibroker] Hallam-Baker, P, "OmniBroker Protocol", 962 Internet-Draft draft-hallambaker-omnibroker-07, 21 January 963 2014. 965 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 966 Requirement Levels", BCP 14, RFC 2119, March 1997. 968 [RFC2986] Nystrom, M.,Kaliski, B., "PKCS #10: Certification Request 969 Syntax Specification Version 1.7", RFC 2986, November 970 2000. 972 [I-D.hallambaker-wsconnect] Hallam-Baker, P, "JSON Service Connect 973 (JCX) Protocol", Internet-Draft draft-hallambaker- 974 wsconnect-05, 21 January 2014. 976 9.2. Informative References 978 [RFC6962] Laurie, B.,Langley, A.,Kasper, E., "Certificate 979 Transparency", RFC 6962, June 2013. 981 Author's Address 983 Phillip Hallam-Baker 984 Comodo Group Inc. 986 philliph@comodo.com