idnits 2.17.1 draft-hallambaker-omnibroker-08.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 19, 2014) is 3629 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 571, but not defined == Missing Reference: 'Required' is mentioned on line 693, but not defined == Unused Reference: 'I-D.hallambaker-omnipublish' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'RFC3339' is defined on line 773, but no explicit reference was found in the text == Unused Reference: 'RFC4648' is defined on line 776, but no explicit reference was found in the text == Unused Reference: 'I-D.hallambaker-httpsession' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'RFC4627' is defined on line 790, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 797, but no explicit reference was found in the text == Unused Reference: 'I-D.hallambaker-jsonbcd' is defined on line 801, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) == Outdated reference: A later version (-03) exists of draft-hallambaker-httpsession-02 == Outdated reference: A later version (-08) exists of draft-hallambaker-wsconnect-05 ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) == Outdated reference: A later version (-01) exists of draft-hallambaker-privatedns-00 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-24) exists of draft-hallambaker-jsonbcd-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.hallambaker-jsonbcd' Summary: 4 errors (**), 0 flaws (~~), 14 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 19, 2014 4 Expires: November 20, 2014 6 OmniBroker Protocol 7 draft-hallambaker-omnibroker-08 9 Abstract 11 An Omnibroker is an agent chosen and trusted by an Internet user to 12 provide information such as name and certificate status information 13 that are in general trusted even if they are not trustworthy. Rather 14 than acting as a mere conduit for information provided by existing 15 services, an Omnibroker is responsible for curating those sources to 16 protect the user. 18 The Omnibroker Protocol (OBP) provides an aggregated interface to 19 trusted Internet services including DNS, OCSP and various forms of 20 authentication service. Multiple transport bindings are supported to 21 permit efficient access in virtually every common deployment scenario 22 and ensure access in any deployment scenario in which access is not 23 being purposely denied. 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 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Omnibroker Discovery and Publication Services . . . . . . 4 61 2.2. Omnibroker Implementation . . . . . . . . . . . . . . . . 4 62 2.2.1. Establishing service . . . . . . . . . . . . . . . . 5 63 2.2.2. Protocol Bindings . . . . . . . . . . . . . . . . . 5 64 3. OmniDiscovery Service . . . . . . . . . . . . . . . . . . . . 6 65 3.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Walled Gardens . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Censorship . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.2. Trust Substitution . . . . . . . . . . . . . . . . . . . 7 69 4.3. Censorship Bypass . . . . . . . . . . . . . . . . . . . . 8 70 5. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.1. Connection Broker . . . . . . . . . . . . . . . . . . . . 8 72 5.1.1. Service Connection Broker . . . . . . . . . . . . . 8 73 5.1.2. Peer Connection Broker . . . . . . . . . . . . . . . 10 74 5.1.3. Credential Validation . . . . . . . . . . . . . . . 11 75 5.1.4. Message: QMessage . . . . . . . . . . . . . . . . . 12 76 5.1.5. Message: QRequest . . . . . . . . . . . . . . . . . 12 77 5.1.6. Message: QResponse . . . . . . . . . . . . . . . . . 12 78 5.1.7. Structure: Identifier . . . . . . . . . . . . . . . 12 79 5.1.8. Structure: Connection . . . . . . . . . . . . . . . 13 80 5.1.9. Structure: Credential . . . . . . . . . . . . . . . 13 81 5.1.10. Structure: CertificateID . . . . . . . . . . . . . 13 82 5.1.11. Structure: Advice . . . . . . . . . . . . . . . . . 13 83 5.1.12. Structure: Service . . . . . . . . . . . . . . . . 14 84 6. OBPQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 6.1. QueryConnect . . . . . . . . . . . . . . . . . . . . . . 14 86 6.1.1. Message: QueryConnectRequest . . . . . . . . . . . . 14 87 6.1.2. Message: QueryConnectResponse . . . . . . . . . . . 14 88 6.2. Validate . . . . . . . . . . . . . . . . . . . . . . . . 15 89 6.2.1. Message: ValidateRequest . . . . . . . . . . . . . . 15 90 6.2.2. Message: ValidateResponse . . . . . . . . . . . . . 15 91 7. Transport Bindings . . . . . . . . . . . . . . . . . . . . . . 15 92 7.1. JSON Payload Binding . . . . . . . . . . . . . . . . . . 16 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 95 9.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 17 96 9.2. Breach of Trust . . . . . . . . . . . . . . . . . . . . . 17 97 9.3. Coercion . . . . . . . . . . . . . . . . . . . . . . . . 17 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 99 11. Example Data . . . . . . . . . . . . . . . . . . . . . . . . 17 100 11.1. Ticket A . . . . . . . . . . . . . . . . . . . . . . . . 17 101 11.2. Ticket B . . . . . . . . . . . . . . . . . . . . . . . . 17 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 103 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 1. Definitions 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 2. Purpose 116 Today, a network client is required to make queries against multiple 117 information sources to establish a secure connection to a network 118 resource. A DNS query is required to translate network names to 119 Internet addresses. If TLS transport is used, an OSCP query may be 120 required to validate the server certificate. Support for client 121 authentication may require interaction with another service. 123 Servers require similar support when accepting Internet connections. 124 Even though most networking infrastructure supports some form of 125 network administration, it is left to the network administrator to 126 fill in the gap between server applications and network 127 infrastructure. Making use of such facilities is rarely cost 128 effective except at the very largest installations. 130 An Omnibroker is a trusted agent that acts as a single point of 131 service for client queries requesting a connection to a named network 132 resource and server advertisements accepting connections to a named 133 network resource. 135 2.1. Omnibroker Discovery and Publication Services 137 The Omnibroker protocol is a meta-directory access protocol. As with 138 any directory protocol, the two principal functions supported by 139 Omnibroker are discovery and publication. These functions are 140 supported by the OmniDiscover and OmniPublish Web Services. 142 This specification document describes the architectural approach 143 shared by both protocols and the OmniDiscover protocol. The 144 OmniPublish protocol is described separately in [I-D.hallambaker- 145 omnipublish]. 147 2.2. Omnibroker Implementation 149 Omnibroker Discovery and Omnibroker Publication make use of the 150 following mechanisms defined in other specifications: 152 Service Connection Service (SXS) [!I-D.hallambaker-wsconnect] 153 To establish and manage the long term trust relationship with 154 the Omnibroker provider. 156 HTTP Session Authentication [!I-D.hallambaker-httpsession] 157 To provide message authentication in the HTTP/REST transport. 159 UDP Framed Messaged (UYFM) described in [!I-D.hallambaker- 160 wsconnect] 161 For low latency transactions. 163 JSON Encoding [!RFC4627] 164 For encoding messages in the HTTP transport. 166 JSON Binary and Compressed encodings described in [!I- 167 D.hallambaker-jsonbcd] 168 For efficient encoding messages in the low latency UYFM 169 transport. 171 2.2.1. Establishing service 173 In normal use, an omnibroker client receives service from a single 174 Omnibroker service provider. For performance and reliability reasons, 175 an Omnibroker service provider is expected to provide multiple 176 Omnibroker service instances. 178 An Omnibroker client acquires the network address information and 179 credentials necessary to access an omnibroker service using the JCX 180 Web Service to establish a connection binding. To ensure reliabilty 181 and the ability to access the service in all circumstances, an 182 Omnibroker connection binding SHOULD specify multiple service 183 instances. 185 2.2.2. Protocol Bindings 187 Due to the need for low latency and the need to function in a 188 compromised network environment, two protocol bindings are defined: 190 * A HTTP binding using HTTP [!RFC2616] for session layer framing 191 and HTTP Session Continuation [!I-D.hallambaker-httpsession] 192 for message authentication and JSON encoding [!RFC4627] of 193 protocol messages. 195 * A UDP Binding using UYFM framing [!I-D.hallambaker-wsconnect] 196 and JSON-B encoding [!I-D.hallambaker-jsonbcd] for framing and 197 encoding of protocol messages. 199 The implementation overhead of support for three different protocol 200 bindings is reduced by the choice of a binary encoding for JSON 201 (JSON-B) that is very close in structure to JSON encoding allowing 202 encoders and decoders to support both encodings with minimal 203 additional code. 205 Regardless of the protocol binding used, all Omnibroker messages are 206 authenticated with protection against replay attack under the 207 cryptographic credentials established in the connection binding 208 service instance. 210 3. OmniDiscovery Service 212 Directing queries through a single point of contact has performance, 213 relability and security advantages. Directing queries to multiple 214 network information sources degrades performance and may cause a 215 connection request to fail if an information resource is not 216 available. This has led many application providers to limit the 217 information sources they consult. Directing queries through an 218 Omnibroker allows as many information sources to be brought to bear 219 as the broker has local cached data for without loss of performance 220 or reliability. 222 Making use of additional data sources allows the broker to 'curate' 223 the response. If the broker knows that a Web site always returns a 224 redirect to a TLS secured version of the same site, it can tell a Web 225 Browser to go straight to the secure version. If a Web Server is 226 hosted on a known botnet, the Omnibroker can tell the client that it 227 really does not want to visit that location. 229 Unlike the traditional DNS configuration, an Omnibroker client 230 decides which source(s) of trusted information to use rather than 231 relying on whatever happens to be the nearest source to hand. 233 The traditional DNS approach creates an obvious security risk as DNS 234 is a trusted service and deciding to choose a random DNS service 235 advertised by the local DHCP service is clearly a poor decision 236 process for a trusted service. Further the DNS protocol does not 237 protect the confidentiality or integrity of messages exchanged. 239 3.1. Related Work 241 Omnibroker provides security for interactions with a DNS service by 242 replacing the DNS protocol with a new protocol that provides a higher 243 level abstract service. [I-D.hallambaker-privatedns] applies the same 244 approach and platforms to provide confidentiality and integrity for 245 legacy DNS protocol messages. 247 4. Walled Gardens 249 IETF culture has traditionally resisted attempts to establish 250 partitions within the open Internet with restricted access to network 251 resources or compromised security. Such 'Walled Gardens' models 252 typically exist for the benefits of those who own the walls rather 253 than those forced to live inside them. 255 While virtually all residential Internet users reject such controls, 256 most find them acceptable, if not desirable in workplaces and 257 schools. 259 Omnibroker simplifies the process of establishing such a walled 260 garden but does not make the walls any easier to defend. 262 4.1. Censorship 264 From a censorship point of view, the censorship concerns of running 265 an Omnibroker are essentially the same as those of running a DNS 266 service. The party who decides which discovery service to use can 267 determine which content is visible to the users. 269 4.2. Trust Substitution 271 Like SCVP [RFC5055] /> and XKMS [TBS], Omnibroker permits an Internet 272 client to delegate some or all aspects of PKIX [RFC5280] certificate 273 path chain discovery and validation. 275 In the normal mode of operation, the Omnibroker service performs only 276 path chain discovery, leaving the client to re-check the PKIX 277 certificate path before relying on it. This gives the Omnibroker the 278 power to veto a client connection to a server that it considers to be 279 unsafe but not the power to tell the client to trust a site of its 280 own choosing. 282 This ability to veto but not assert trust is appropriate and 283 sufficient for the vast majority of network applications. It allows 284 the broker to make use of additional path validation checks that are 285 not supported in the client such as DANE [RFC6698] or Certificate 286 Transparency [RFC6962] />. 288 There are however some workplace environments where the ability to 289 access external network resources with strong encryption is not 290 permissible by enterprise policy or in some cases by law. An 291 intelligence analyst working at the NSA may have a need to access 292 external Web sites that contain important information but must on no 293 account have access to a covert channel that could be used to 294 exfiltrate information. Certain Financial institutions with access to 295 valuable commercial information are required to monitor and record 296 all communications into and out of the company to deter insider 297 trading. 299 The traditional response to such needs has been to tell the parties 300 affected to look elsewhere for support. As a consequence the 301 techniques used to satisfy such requirements are generally unfriendly 302 to network applications in general and have in some cases put the 303 public Web PKI trust infratructure at risk. 305 There is an argument to be made that rather than attempting to 306 prohibit such activities entirely, it would be better to provide a 307 principled method of achieving those ends and for mainstream software 308 providers to support it in such a fashion that ensures that network 309 applications configured for that mode of use can be readilly 310 identified as such by end users. 312 4.3. Censorship Bypass 314 As the preceeding examples demonstrate, a party with control over the 315 Omnibroker service chosen by a user has full control over the network 316 activities of that user. An important corrolary of this fact is that 317 all a user need do to achieve full control over their network 318 activities is to run their own Omnibroker service and connect to 319 that. 321 For example such an Omnibroker service might be configured to return 322 connection data for permitted domestic Web sites as normal but direct 323 attempts to connect to forbidden foreign news or social media through 324 a privacy network such as TOR. 326 5. Use 328 For illustrative purposes, all the examples in this section are shown 329 using the Web Services Transport binding. The security connection has 330 already been established as described in [I-D.hallambaker-wsconnect]. 332 5.1. Connection Broker 334 The OBP service connection broker answers the query 'what connection 335 parameters should be used to establish the best connection to 336 interract with party X according to protocol Y. Where 'best' is 337 determined by the Omnibroker which MAY take into account parameters 338 specified by the relying party. 340 5.1.1. Service Connection Broker 342 The OBP service connection broker supports and extends the 343 traditional DNS resolution service that resolves a DNS name (e.g. 344 www.example.com) to return an IP address (e.g. 10.1.2.3). 346 When using an Omnibroker as a service connection broker, a client 347 specifies both the DNS name (e.g. www.example.com) and the Internet 348 protocol to be used (e.g. _http._tcp). The returned connection 349 parameters MAY include: 351 The IP protocol version, address and port number to establish a 352 connection to. If appropriate, a security transport such as TLS or 353 IPSEC. If appropriate, a description of a service credential such as 354 a TLS certificate or a constraint on the type of certificates that 355 the client should consider acceptable. If appropriate, application 356 protocol details such as version and protocol options. 358 If an attempt to connect with the parameters specified fails, a 359 client MAY report the failure and request a new set of parameters. 361 5.1.1.1. Service Connection Broker Example 363 Alice uses her Web browser to access the URL http://www.example.com/. 364 The Web browser sends a QueryConnectRequest request to obtain the 365 best connection parameters for the http protocol at www.example.com: 367 POST /.well-known/omni-query/ HTTP/1.1 368 Content-Type: application/json;charset=UTF-8 369 Cache-Control: no-store 370 Session: Value=5_AlS4yMTeE82T6ZP9qAZN7TOhXtvqZ__zsLOmCxNrQ; 371 Id=o7znkpTHfrqcwsI1eHkPghCj7YsGUCp0KV2DcV1qXGlCt9wzmr2T6UcO_0YI 372 AcEqVdTsqRsYBtVNGs9SJyTCnMvjIlU1xQ9ZzoUtqtJsT4A 373 Host: localhost:8080 374 Content-Length: 123 375 Expect: 100-continue 377 { 378 "QueryConnectRequest": { 379 "Identifier": { 380 "Name": "Example.com", 381 "Service": "_http", 382 "Port": 80}}} 384 The service responds with an ordered list of possible connections. In 385 this case the site is accessible via plain TCP transport or with TLS. 386 Since TLS is the preferred protocol, that connection is listed first. 388 HTTP/1.1 OK Success 389 Content-Length: 371 390 Date: Mon, 19 May 2014 17:17:43 GMT 391 Server: Microsoft-HTTPAPI/2.0 393 { 394 "QueryConnectResponse": { 395 "Status": 200, 396 "StatusDescription": "Success", 397 "Connection": [{ 398 "IPAddress": "10.3.2.1", 399 "IPPort": 443, 400 "Transport": "TLS", 401 "TransportPolicy": "TLS=Optional", 402 "ProtocolPolicy": "Strict"}, 403 { 404 "IPAddress": "10.3.2.1", 405 "IPPort": 80, 406 "ProtocolPolicy": "Strict"}]}} 408 5.1.2. Peer Connection Broker 410 Each OBP request identifies both the account under which the request 411 is made and the device from which it is made. An OBP broker is thus 412 capable of acting as a peer connection broker service or providing a 413 gateway to such a service. 415 When using Omnibroker as a peer connection broker, a client specifies 416 the account name and DNS name of the party with which a connection is 417 to be established (e.g. alice@example.com) and the connection 418 protocol to be used (e.g. _xmpp-client._tcp) 420 The returned connection parameters are similar to those returned in 421 response to a service broker query. 423 5.1.2.1. Service Connection Broker Example 425 Although the QueryConnectResponse returned the hash of a PKIX 426 certificate considered valid for that connection, the server returns 427 a different certificate which the client verifies using the 428 ValidateRequest query. 430 [POST /.well-known/omni-query/ HTTP/1.1 431 Content-Type: application/json;charset=UTF-8 432 Cache-Control: no-store 433 Session: Value=ebgTLvWjZFeTMnowmomslUu9rPvzAPAciO11QK26NQg; 434 Id=o7znkpTHfrqcwsI1eHkPghCj7YsGUCp0KV2DcV1qXGlCt9wzmr2T6UcO_0YI 435 AcEqVdTsqRsYBtVNGs9SJyTCnMvjIlU1xQ9ZzoUtqtJsT4A 436 Host: localhost:8080 437 Content-Length: 1126 438 Expect: 100-continue 440 { 441 "ValidateRequest": { 442 "Service": { 443 "Identifier": [{ 444 "Name": "example.com"}]}, 445 "Credential": [{ 446 "Data": " 447 MIIC0DCCAbigAwIBAgIQQut6m1F0PodIjIzop_d1uDANBgkqhkiG9w0BAQUFADAR 448 MQ8wDQYDVQQDEwZWb29kb28wHhcNMTMwNjI2MTczOTQyWhcNMTQwNjI2MDAwMDAw 449 WjARMQ8wDQYDVQQDEwZWb29kb28wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK 450 AoIBAQCdc7Qgx71o6Tq5dFUUhcCn8Nt-2Y9SGhm3WvsMYIqOIcHq3gjIKN9FWvXz 451 pBbTjz4lCwx-CJT82RBLNDFtsysfc0G7K_RsNKosYaM-L-DshO6R_314tptn9gnT 452 9tjTPXuiiICQlAP83BuTI148iEJWL36vbmv5AG6vrtk3T6ah5r2hBXQjt46sLQYw 453 eiM-peYIhPTIy9OYugogfqdzPvaJpDfAukqJBXqMxfscagKPYAGPaICKhobKr11a 454 Pam1Tchk2cBbtuYgSDz6ZGttsKE2omDbcmhbF7gBpRug-E2OH79Q4EVlSSoO9gZ6 455 AF4Km1A9uK9W_Pg8EPugY3Mgns6lAgMBAAGjJDAiMAsGA1UdDwQEAwIEMDATBgNV 456 HSUEDDAKBggrBgEFBQcDATANBgkqhkiG9w0BAQUFAAOCAQEACK9LQNkewOOugaYh 457 s4LfE3xdrRzrcaR0w5cf3wVcgR0ZZo98rDOtu3FAexpdh6vNaIdU4zAzNJPKKSso 458 3XF2LpQZovKIpUuN9pkZqslqZ0TLXqlyXMbheShcqIP1-m6qjZOp95N7jwgxBlEm 459 i_ne-rg1DicXFtAu90LpAZludaQGAyrj-LC37gzeMo2AG7BAuyFURXJFfxjpGmnu 460 euYfzZIMIQY-lNl6qm_vSMIz4uUKqq4lWndahnkJAwI2p5zUM0z3O6OMr_zr8eyr 461 dAL__H4NnG3gVyBbNoSbvbkxUt_C3oBwFFTupzRMQqJVjzbApyw5H0OzJPJKKkxx 462 hmIYTg"}]}} 464 The service validates the certificate according to the Omnibroker 465 service policy. 467 [HTTP/1.1 OK Success 468 Content-Length: 81 469 Date: Mon, 19 May 2014 17:17:43 GMT 470 Server: Microsoft-HTTPAPI/2.0 472 { 473 "ValidateResponse": { 474 "Status": 200, 475 "StatusDescription": "Success"}} 477 5.1.3. Credential Validation 479 The credential validation query provides certificate path validation 480 and status checking. 482 The service provided by OBP is similar to that provided by OCSP and 483 SCVP. Like SCVP, OBP is an agent selected by the relying party to 484 validate certificates and/or construct trust paths on its behalf. 486 5.1.4. Message: QMessage 488 5.1.5. Message: QRequest 490 Every query request contains the following common elements: 492 Index : 493 Integer [0..1] Index used to request a specific response when 494 multiple responses are available. 496 5.1.6. Message: QResponse 498 Every Query Response contains the following common elements: 500 Status : 501 Integer [1..1] Status return code value 503 StatusDescription : 504 String [0..1] Describes the status code (ignored by processors) 506 Index : 507 Integer [0..1] Index of the current response. 509 Count : 510 Integer [0..1] Number of responses available. 512 5.1.7. Structure: Identifier 514 Specifies an Internet service by means of a DNS address and either a 515 DNS service prefix, an IP port number or both. An Internet peer 516 connection MAY be specified by additionally specifying an account. 518 Name : 519 Name [1..1] The DNS name of the service to connect to. 520 Internationalized DNS names MUST be encoded in punycode 521 encoding. 523 Account : 524 Label [0..1] Identifies the account to connect to in the case 525 that a peer connection is to be established. 527 Service : 528 Name [0..1] The DNS service prefix defined for use with DNS 529 records that take a service prefix including SRV. 531 Port : 532 Integer [0..1] IP Port number. A service identifier MUST 533 specify either a service or a port or both. 535 5.1.8. Structure: Connection 537 IPAddress : 538 String [0..1] IP address in string representation 540 IPPort : 541 Integer [0..1] IP port. 1-65535 543 Transport : 544 String [0..1] Transport (RAW, TLS, IPSEC) 546 TransportPolicy : 547 String [0..1] Transport security policy as specified in [TBS] 549 ProtocolPolicy : 550 String [0..1] Application security policy specification as 551 specified by the application protocol. 553 Advice : 554 Advice [0..1] Additional information that a service MAY return 555 to support a service connection identification. 557 5.1.9. Structure: Credential 559 Type : 560 String [0..1] [TBS] 562 Data : 563 Binary [0..1] [TBS] 565 5.1.10. Structure: CertificateID 567 Type : 568 String [0..1] [TBS] 570 Data : 571 Binary [0..1] [TBS] 573 5.1.11. Structure: Advice 575 Additional information that a service MAY return to support a service 576 connection identification. For example, DNSSEC signatures chains, 577 SAML assertions, DANE records, Certificate Transparency proof chains, 578 etc. 580 Type : 581 Label [0..1] The IANA MIME type of the content type 583 Data : 584 Binary [0..1] The advice data. 586 5.1.12. Structure: Service 588 Describes a service connection 590 Identifier : 591 Identifier [0..Many] Internet addresses to which the service is 592 to be bound. 594 Connection : 595 Connection [0..1] Service connection parameters. 597 6. OBPQuery 599 6.1. QueryConnect 601 Requests a connection context to connect to a specified Internet 602 service or peer. 604 6.1.1. Message: QueryConnectRequest 606 Specifies the Internet service or peer that a connection is to be 607 established to and the acceptable security policies. 609 Identifier : 610 Identifier [0..1] Identifies the service or peer to which a 611 connection is requested. 613 Policy : 614 Label [0..Many] Acceptable credential validation policy. 616 ProveIt : 617 Boolean [0..1] If set the broker SHOULD send advice to permit 618 the client to validate the proposed connection context. 620 6.1.2. Message: QueryConnectResponse 622 Returns one or more connection contexts in response to a 623 QueryConnectRequest Message. 625 Connection : 626 Connection [0..Many] An ordered list of connection contexts 627 with the preferred connection context listed first. 629 Advice : 630 Advice [0..1] Proof information to support the proposed 631 connection context. 633 Policy : 634 Label [0..Many] Policy under which the credentials have been 635 verified. 637 6.2. Validate 639 The Validate query requests validation of credentials presented to 640 establish a connection. For example credentials presented by a server 641 in the process of setting up a TLS session. 643 6.2.1. Message: ValidateRequest 645 Specifies the credentials to be validated and the purpose for which 646 they are to be used. 648 Service : 649 Service [0..1] Describes the service for which the credentials 650 are presented for access. 652 Credential : 653 Credential [0..Many] Credentials for which validation is 654 requested. 656 CertificateID : 657 CertificateID [0..Many] OCSP Certificate Identifiers for which 658 validation is requested. 660 Policy : 661 Label [0..Many] Policy under which the credentials have been 662 verified. 664 6.2.2. Message: ValidateResponse 666 Reports the status of the credential presented. 668 Policy : 669 Label [0..Many] Policy under which the credentials have been 670 verified. 672 7. Transport Bindings 674 To achieve an optimal balance of efficiency and availability, two 675 transport bindings are defined: 677 JSON over HTTP (TLS or TCP) 678 Supports all forms of OBP transaction in all network 679 environments. 681 JSON-B over UYFM (UDP) 682 Provides efficient support for all OBP query transactions and 683 is accessible in most network environments. 685 Support for the HTTP binding is REQUIRED. 687 An OBP message consists of three parts: 689 Ticket [If required] 690 If specified, identifies the cryptographic key and algorithm 691 parameters to be used to secure the message payload. 693 Payload [Required] 694 If the ticket context does not specify use of an encryption 695 algorithm, contains the message data. Otherwise contains the 696 message data encrypted under the encryption algorithm and key 697 specified in the ticket context. 699 Authenticator [If required] 700 If the ticket context specifies use of a Message Authentication 701 Code (MAC), contains the MAC value calculated over the payload 702 data using the authentication key bound to the ticket. 704 Note that although each of the transport bindings defined in this 705 specification entail the use of a JSON encoding for the message data, 706 this is not a necessary requirement for a transport binding. 708 7.1. JSON Payload Binding 710 Integer 711 Data of type Integer is encoded using the JSON number encoding. 713 Name 714 Data of type Name is encoded using the JSON string encoding. 716 String 717 Data of type String is encoded using the JSON string encoding. 719 Binary 720 Data of type Binary is converted to strings using the Base64url 721 encoding specified in [!RFC4648] /> and encoded using the JSON 722 string type. 724 DateTime 725 Data of type DateTime is converted to string using the UTC time 726 conversion specified in [!RFC3339] /> with a UTC offset of 727 00:00. 729 8. Acknowledgements 731 Rob Stradling, Robin Alden... 733 9. Security Considerations 735 9.1. Denial of Service 737 9.2. Breach of Trust 739 9.3. Coercion 741 10. IANA Considerations 743 [TBS list out all the code points that require an IANA registration] 745 11. Example Data 747 11.1. Ticket A 749 11.2. Ticket B 751 12. References 753 12.1. Normative References 755 [RFC6698] Hoffman, P.,Schlyter, J., "The DNS-Based Authentication of 756 Named Entities (DANE) Transport Layer Security (TLS) 757 Protocol: TLSA", RFC 6698, August 2012. 759 [RFC5280] Cooper, D.,Santesson, S.,Farrell, S.,Boeyen, S.,Housley, 760 R.,Polk, W., "Internet X.509 Public Key Infrastructure 761 Certificate and Certificate Revocation List (CRL) 762 Profile", RFC 5280, May 2008. 764 [RFC5055] Freeman, T.,Housley, R.,Malpani, A.,Cooper, D.,Polk, W., 765 "Server-Based Certificate Validation Protocol (SCVP)", RFC 766 5055, December 2007. 768 [RFC6962] Laurie, B.,Langley, A.,Kasper, E., "Certificate 769 Transparency", RFC 6962, June 2013. 771 [I-D.hallambaker-omnipublish] , "[Reference Not Found!]". 773 [RFC3339] ,Klyne, G.,Newman, C., "Date and Time on the Internet: 774 Timestamps", RFC 3339, July 2002. 776 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 777 Encodings", RFC 4648, October 2006. 779 [I-D.hallambaker-httpsession] Hallam-Baker, P, "HTTP Session 780 Management", Internet-Draft draft-hallambaker-httpsession- 781 02, 21 January 2014. 783 [I-D.hallambaker-wsconnect] Hallam-Baker, P, "JSON Service Connect 784 (JCX) Protocol", Internet-Draft draft-hallambaker- 785 wsconnect-05, 21 January 2014. 787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 788 Requirement Levels", BCP 14, RFC 2119, March 1997. 790 [RFC4627] Crockford, D., "The application/json Media Type for 791 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 793 [I-D.hallambaker-privatedns] Hallam-Baker, P, "Private-DNS", 794 Internet-Draft draft-hallambaker-privatedns-00, 9 May 795 2014. 797 [RFC2616] Fielding, R.,Gettys, J.,Mogul, J.,Frystyk, H.,Masinter, 798 L.,Leach, P.,Berners-Lee, T., "Hypertext Transfer Protocol 799 -- HTTP/1.1", RFC 2616, June 1999. 801 [I-D.hallambaker-jsonbcd] Hallam-Baker, P, "Binary Encodings for 802 JavaScript Object Notation: JSON-B, JSON-C, JSON-D", 803 Internet-Draft draft-hallambaker-jsonbcd-01, 21 January 804 2014. 806 Author's Address 808 Phillip Hallam-Baker 809 Comodo Group Inc. 811 philliph@comodo.com