idnits 2.17.1 draft-reddy-dprive-dprive-privacy-policy-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2019) is 1642 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: 'RFCThis' is mentioned on line 725, but not defined == Outdated reference: A later version (-01) exists of draft-ietf-dnsop-resolver-information-00 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 6979 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' == Outdated reference: A later version (-16) exists of draft-ietf-dnsop-extended-error-12 == Outdated reference: A later version (-14) exists of draft-ietf-dprive-bcp-op-04 == Outdated reference: A later version (-08) exists of draft-reddy-dprive-bootstrap-dns-server-05 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) -- Obsolete informational reference (is this intentional?): RFC 7816 (Obsoleted by RFC 9156) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DPRIVE WG T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track D. Wing 5 Expires: April 27, 2020 Citrix 6 M. Richardson 7 Sandelman Software Works 8 October 25, 2019 10 DNS server privacy policy with assertion token 11 draft-reddy-dprive-dprive-privacy-policy-01 13 Abstract 15 Users want to control how their DNS queries are handled by DNS 16 servers so they can configure their system to use DNS servers that 17 comply with their privacy expectations. 19 This document defines a mechanism for a DNS server to communicate its 20 privacy policy to a DNS client. This communication is 21 cryptographically signed to attest to its authenticity. By 22 evaluating the DNS privacy policy and the signatory, the DNS client 23 can choose a DNS server that best supports its desired privacy 24 policies. The privacy assertion token is particularly useful for 25 DNS-over-TLS and DNS-over-HTTPS servers, both public resolvers and 26 those discovered on the local network. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 27, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Use Cases Overview . . . . . . . . . . . . . . . . . . . . . 4 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Privacy assertion token (PAT) overview . . . . . . . . . . . 5 66 5. PAT Header . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. "typ" (Type) Header Parameter . . . . . . . . . . . . . . 6 68 5.2. "alg" (Algorithm) Header Parameter . . . . . . . . . . . 6 69 5.3. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . . 7 70 5.4. Example PAT header . . . . . . . . . . . . . . . . . . . 7 71 6. PAT Payload . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6.1. JWT defined claims . . . . . . . . . . . . . . . . . . . 8 73 6.1.1. "iat" - Issued At claim . . . . . . . . . . . . . . . 8 74 6.1.2. "exp" - Expiration Time claim . . . . . . . . . . . . 8 75 6.2. PAT specific claims . . . . . . . . . . . . . . . . . . . 8 76 6.2.1. DNS server Identity Claims . . . . . . . . . . . . . 8 77 6.2.2. "privinfo" (Privacy Information) Claim . . . . . . . 9 78 6.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 11 79 7. PAT Signature . . . . . . . . . . . . . . . . . . . . . . . . 12 80 8. Extending PAT . . . . . . . . . . . . . . . . . . . . . . . . 13 81 9. Deterministic JSON Serialization . . . . . . . . . . . . . . 13 82 9.1. Example PAT deterministic JSON form . . . . . . . . . . . 14 83 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 12.1. Media Type Registration . . . . . . . . . . . . . . . . 16 87 12.1.1. Media Type Registry Contents Additions Requested . . 16 88 12.2. JSON Web Token Claims Registration . . . . . . . . . . . 17 89 12.2.1. Registry Contents Additions Requested . . . . . . . 17 90 12.3. DNS Resolver Information Registration . . . . . . . . . 17 91 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 92 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 14.1. Normative References . . . . . . . . . . . . . . . . . . 17 94 14.2. Informative References . . . . . . . . . . . . . . . . . 19 95 Appendix A. Example ES256 based PAT JWS Serialization and 96 Signature . . . . . . . . . . . . . . . . . . . . . 20 97 A.1. X.509 Private Key in PKCS#8 format for ES256 Example** . 22 98 A.2. X.509 Public Key for ES256 Example** . . . . . . . . . . 22 99 Appendix B. Complete JWS JSON Serialization Representation with 100 multiple Signatures . . . . . . . . . . . . . . . . 22 101 B.1. X.509 Private Key in PKCS#8 format for E384 Example** . . 24 102 B.2. X.509 Public Key for ES384 Example** . . . . . . . . . . 24 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 105 1. Introduction 107 [RFC7626] discusses DNS privacy considerations in both "on the wire" 108 (Section 2.4 of [RFC7626]) and "in the server" (Section 2.5 of 109 [RFC7626] contexts. In recent years there has also been an increase 110 in the availability of "public resolvers" 111 [I-D.ietf-dnsop-terminology-bis] which DNS clients may be pre- 112 configured to use instead of the default network resolver because 113 they offer a specific feature (e.g., good reachability, encrypted 114 transport, strong privacy policy, filtering (or lack of), etc.). 115 While a human can read the privacy policy of a DNS server operator, 116 this information is not machine-parsable to allow automatic DNS 117 server selection by the DNS client software. For DNS servers 118 operated on the local network, the DNS client can be securely 119 bootstrapped to discover and authenticate DNS-over-TLS and DNS-over- 120 HTTPS servers provided by a local network using the technique 121 proposed in [I-D.reddy-dprive-bootstrap-dns-server]. By creating a 122 machine-parsable DNS server privacy policy, the DNS client can 123 automatically allow using a DNS server on the local network that 124 complies with the DNS client's privacy policy. 126 This document defines a method for creating and validating a token 127 that cryptographically verifies the privacy policy information of a 128 DNS server, such as a DNS-over-TLS or DNS-over-HTTPS server. 130 The cryptographically signed privacy statement allows a DNS client to 131 connect to multiple DNS servers and select the DNS server that 132 adheres to the privacy preserving data policy requirements of the 133 client. For example, a browser with pre-configured DNS-over-HTTPS 134 server can discover the DNS-over-HTTPS server provided the local 135 network, connects to both the DNS servers, gets the privacy policy 136 information from each of the DNS servers, validates the signatures 137 and uses a server that meets the privacy preserving data policy 138 requirements of the client. If both servers meet the privacy 139 preserving data policy requirements of the client, it can select to 140 use the local DNS server. In addition, the cryptographically signed 141 privacy statement allows a DNS-over-TLS or DNS-over-HTTPS client to 142 securely determine whether the local DNS server performs DNS-based 143 content filtering, and if the local server meets the privacy 144 preserving data policy requirements of the client, the client can 145 continue to use the local DNS-over-TLS server to resolve DNS queries 146 and does not have to switch to the pre-configured public resolver. 148 2. Use Cases Overview 150 The mechanism for a DNS server to communicate its cryptographically 151 signed privacy policy to a DNS client solves the following problems 152 in various deployments: 154 o Typically Enterprise networks do not assume that all devices in 155 their network are managed by the IT team or Mobile Device 156 Management (MDM) devices, especially in the quite common BYOD 157 ("Bring Your Own Device") scenario. The mechanism specified in 158 this document can be used by BYOD devices to determine if the DNS 159 server on the local network complies with the client's privacy 160 policy. 162 o The user must select specific well known networks (e.g., 163 organization for which a user works or a user works temporarily 164 within another corporation) to learn the privacy policy 165 information of the local DNS server, and user can choose to use 166 the discovered DNS-over-TLS or DNS-over-HTTPS server. If that 167 discovered DNS-over-TLS or DNS-over-HTTPS server does not meet the 168 privacy requirements of the user, user can be warned and the 169 client can take appropriate action. For example, use the network 170 only to access internal-only DNS names or fallback to a privacy- 171 enabling public DNS server. 173 o The privacy policy information signals the presence of DNS-based 174 content filtering in the attached network. If the network is well 175 known and the local DNS server meets the privacy requirements of 176 the user, the client can continue to use encrypted connection with 177 the local DNS-over-TLS or DNS-over-HTTPS server. If the error 178 code returned by the DNS server indicates access to the domain is 179 blocked because of internal security policy 180 [I-D.ietf-dnsop-extended-error], the client can securely identify 181 access to the domain is censored by the network. 183 o The privacy policy conveys a URL that points to the human readable 184 privacy policy information of the DNS server for the user to 185 review and can make an informed decision whether the DNS server is 186 trustworthy to honor the privacy of the user. The client 187 automatically learns updates to the privacy policy of the DNS 188 server, and whenever the privacy policy of the DNS server changes, 189 the client can notify the user to re-visit the URL to re-review 190 the privacy policy information of the DNS server. 192 If the device joins a public WiFi without any security credential 193 verification, such networks are typically not known to the user, and 194 the device cannot be securely bootstrapped with the network's DNS- 195 over-HTTPS or DNS-over-TLS server. Such networks can be 196 misconfigured or malicious. Further, the client cannot know if the 197 discovered DNS-over-HTTPS or DNS-over-TLS server is hosted by the 198 network operator or by an attacker. This specification does not 199 cater to such networks. 201 3. Terminology 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 205 "OPTIONAL" in this document are to be interpreted as described in BCP 206 14 [RFC2119][RFC8174] when, and only when, they appear in all 207 capitals, as shown here. 209 (D)TLS is used for statements that apply to both Transport Layer 210 Security [RFC8446] and Datagram Transport Layer Security [RFC6347]. 211 Specific terms are used for any statement that applies to either 212 protocol alone. 214 This document uses the terms defined in [RFC8499]. 216 4. Privacy assertion token (PAT) overview 218 JSON Web Token (JWT) [RFC7519] and JSON Web Signature (JWS) [RFC7515] 219 and related specifications define a standard token format that can be 220 used as a way of encapsulating claimed or asserted information with 221 an associated digital signature using X.509 based certificates. JWT 222 provides a set of claims in JSON format that can conveniently 223 accommodate asserted privacy policy information of the DNS-over-TLS 224 or DNS-over-HTTPS server. Additionally, JWS provides a path for 225 updating methods and cryptographic algorithms used for the associated 226 digital signatures. 228 JWS defines the use of JSON data structures in a specified canonical 229 format for signing data corresponding to JOSE header, JWS Payload, 230 and JWS Signature. JWT defines a set of claims that are represented 231 by specified JSON objects which can be extended with custom keys for 232 specific applications. The next sections define the header and 233 claims that MUST be minimally used with JWT and JWS for privacy 234 assertion token. 236 The privacy assertion token (PAT) specifically uses this token format 237 and defines claims that convey the privacy policy information of DNS- 238 over-TLS or DNS-over-HTTPS server. The signer of a PAT object may or 239 may not correspond to the DNS server's domain. The PAT object can be 240 validated by the DNS client, and if the DNS server meets the privacy 241 preserving data policy requirements of the client and/or end user, it 242 can switch to the privacy-enabling DNS server discovered in the 243 located network. The creation of the PAT object is performed by an 244 entity that is authoritative to assert the DNS server privacy policy 245 information. This authority is represented by the certificate 246 credentials and the signature, and PAT object is created and the 247 client can retrieve the PAT object using the method discussed in 248 [I-D.ietf-dnsop-resolver-information]. 250 For example, the PAT object could be created by the domain hosting 251 the DNS-over-TLS or DNS-over-HTTPS server, or by a third party who 252 performed privacy and security audit of the DNS-over-TLS or DNS-over- 253 HTTPS server. The DNS client needs to have the capability to verify 254 the PAT token and the digital signature. The PAT associated 255 certificate is used to validate the authority of the originating 256 signer, generally via a certificate chain to the trust anchor for the 257 DNS client. 259 5. PAT Header 261 The JWS token header is a JOSE header, [RFC7515] Section 4, that 262 defines the type and encryption algorithm used in the token. 264 PAT header should include, at a minimum, the header parameters 265 defined in the next three subsections. 267 5.1. "typ" (Type) Header Parameter 269 The "typ" (Type) Header Parameter is defined in JWS [RFC7515] 270 Section 4.1.9 to declare the media type of the complete JWS. 272 For PAT Token the "typ" header MUST be the string "pat". This 273 represents that the encoded token is a JWT of type pat. 275 5.2. "alg" (Algorithm) Header Parameter 277 The "alg" (Algorithm) Header Parameter is defined in JWS [RFC7515] 278 Section 4.1.1. This definition includes the ability to specify the 279 use of a cryptographic algorithm for the signature part of the JWS. 280 It also refers to a list of defined "alg" values as part of a 281 registry established by JSON Web Algorithms (JWA) [RFC7518] 282 Section 3.1. 284 For the creation and verification of PAT tokens and their digital 285 signatures, implementations MUST support ES256 as defined in JWA 286 [RFC7518] Section 3.4. Implementations MAY support other algorithms 287 registered in the JSON Web Signature and Encryption Algorithms 288 registry created by [RFC7518]. The contents of that registry may be 289 updated in the future depending on cryptographic strength 290 requirements guided by current security best practice. The 291 mandatory-to-support algorithm for PAT tokens may likewise be updated 292 in future updates to this document. 294 Implementations of PAT digital signatures using ES256 as defined 295 above SHOULD use deterministic ECDSA if/when supported for the 296 reasons stated in [RFC6979]. 298 5.3. "x5u" (X.509 URL) Header Parameter 300 As defined in JWS [RFC7515] Section 4.1.5., the "x5u" header 301 parameter defines a URI [RFC3986] referring to the resource for the 302 X.509 public key certificate or certificate chain [RFC5280] 303 corresponding to the key used to digitally sign the JWS. Generally, 304 as defined in JWS [RFC7515] section 4.1.5, this would correspond to 305 an HTTPS or DNSSEC resource using integrity protection. 307 5.4. Example PAT header 309 An example of the header, would be the following, including the 310 specified pat type, ES256 algorithm, and a URI referencing the 311 network location of the certificate needed to validate the PAT 312 signature. 314 { 315 "typ":"pat", 316 "alg":"ES256", 317 "x5u":"https://cert.example.com/pat.cer" 318 } 320 6. PAT Payload 322 The token claims consists of the privacy policy information of the 323 DNS server which needs to be verified at the DNS client. These 324 claims follow the definition of a JWT claim [RFC7519] Section 4 and 325 are encoded as defined by the JWS Payload [RFC7515] Section 3. 327 PAT defines the use of a standard JWT defined claim as well as custom 328 claims corresponding to the DNS-over-TLS or DNS-over-HTTPS servers. 330 Any claim names MUST use the US-ASCII character set. Any claim 331 values can contain characters that are outside the US-ASCII range, 332 however MUST follow the default JSON serialization defined in 333 [RFC7519] Section 7. 335 6.1. JWT defined claims 337 6.1.1. "iat" - Issued At claim 339 The JSON claim MUST include the "iat" [RFC7519] Section 4.1.6 defined 340 claim Issued At. As defined the "iat" should be set to the date and 341 time of issuance of the JWT. The time value should be of the format 342 defined in [RFC7519] Section 2 NumericDate. 344 6.1.2. "exp" - Expiration Time claim 346 The JSON claim MUST include the "exp" [RFC7519] Section 4.1.4 defined 347 claim Expiration Time. As defined the "exp" should be set to specify 348 the expiration time on or after which the JWT is not accepted for 349 processing. The PAT object should generally expire after a 350 reasonable duration. A short expiration time for the PAT object 351 periodically reaffirms the privacy policy information of the DNS 352 server to the client and ensures the client does not use outdated 353 privacy policy information. If the client knows the PAT object has 354 expired, it makes another request to get the new PAT object from the 355 DNS server. 357 6.2. PAT specific claims 359 6.2.1. DNS server Identity Claims 361 The DNS server identity is represented by a claim that is required 362 for PAT, the "server" claim. The "server" MUST contain claim values 363 that are identity claim JSON objects where the child claim name 364 represents an identity type and the claim value is the identity 365 string, both defined in subsequent subsections. Currently, these 366 identities can be represented as either authentication domain name 367 (ADN) (defined in [RFC8310]) or Uniform Resource Indicators (URI). 369 6.2.1.1. "adn" - authentication domain name identity 371 If the DNS server identity is a ADN, the claim name representing the 372 identity MUST be "adn". The claim value for the "adn" claim is the 373 ADN. 375 6.2.1.2. "uri" - URI identity 377 If the DNS server identity is of the form URI, as defined in 378 [RFC3986], the claim name representing the identity MUST be "uri" and 379 the claim value is the URI form of the DNS server identity. As a 380 reminder, if DNS-over-HTTPS protocol is supported by the DNS server, 381 the DNS client uses the https URI scheme (Section 3 of [RFC8484]). 383 6.2.2. "privinfo" (Privacy Information) Claim 385 The "privinfo" claim MUST be formatted as a JSON object. The 386 "privinfo" claim contains the privacy policy information of the DNS 387 server, it includes the following attributes: 389 ipaddresspii: If the client IP address is Personally Identifiable 390 Information (PII) data or non PII-data. If client IP address is 391 PII, the parameter value is set to 'true'. This is a mandatory 392 attribute. 394 logging: If the transaction data (e.g., DNS messages) is logged and 395 the duration that data is stored. A value of negative one (-1) 396 indicates indefinite duration of logging transaction data. A 397 value of zero (0) indicates no logging. Logging duration is 398 represented in hours. If any of the attributes 'useridentity', 399 'notifyuser' and 'analytics' are not set to the value zero, 400 'logging' attribute MUST NOT be set to the value zero. This is a 401 mandatory attribute. 403 useridentity: If the user identity that sent the DNS query is logged 404 and the duration that data is retained. User identity includes 405 things such as username, IP address, MAC address, user DNS query 406 patterns or any other personally identifiable data. The server 407 should also discard or minimize correlation data (Section 5.2.4 of 408 [I-D.ietf-dprive-bcp-op]) that can be used to identify the end 409 user. A value of negative one (-1) indicates indefinite duration 410 of logging user identity. A value of zero (0) indicates no 411 logging. Logging duration is represented in hours. This is a 412 mandatory attribute. 414 filtering: If the DNS server changes some of the answers that it 415 returns based on policy criteria, such as to prevent access to 416 malware sites or objectionable content. This optional attribute 417 has the following structure: 419 malwareblocking: The DNS server offers malware blocking service. 420 If access to domains is blocked on threat data, the parameter 421 value is set to 'true'. 423 policyblocking: If access to domains is blocked on a blacklist or 424 objectionable content, the parameter value is set to 'true'. 426 notifyuser: If the transaction data is logged to notify the user 427 access to certain domains is blocked, the period for which the 428 transaction data is stored. A value of negative one (-1) 429 indicates indefinite duration of logging transaction data to 430 notify the user. A value of zero (0) indicates no logging. 431 Logging duration is represented in hours. This is an optional 432 attribute. 434 analytics: If the transaction data is logged for analytics (e.g., To 435 detect malicious domains), the period for which the transaction 436 data is stored. A value of negative one (-1) indicates indefinite 437 duration of logging transaction data for analytics. A value of 438 zero (0) indicates no logging. Logging duration is represented in 439 hours. This is an optional attribute. 441 sharedata: If the transaction data is shared with partners or not, 442 and if the transaction data is shared with partners, the names of 443 the partners. If anonymized data or client identifiable data is 444 shared with partners. The term "anonymization" is defined in 445 Section 5.2.2 of [I-D.ietf-dprive-bcp-op]. This mandatory 446 attribute has the following structure: 448 sharepartners: If transaction data is shared with partners, the 449 parameter value is set to 'true'. 451 partners: List of partner names. If 'sharepartners' value is set 452 to false, 'partners' MUST NOT be present in the 'sharedata' 453 structure. 455 anonymizeddata: If anonymized transaction data is shared with 456 partners, the parameter value is set to 'true'. If 457 'sharepartners' value is set to false, 'anonymizeddata' MUST 458 NOT be present in the 'sharedata' structure. 460 transferdata: If the transaction data is shared or sold to third 461 parties. If the parameter value is set to 'true', means share or 462 sell data to third parties. This is a mandatory attribute. 464 qnameminimization: If the DNS server implements QNAME minimisation 465 [RFC7816] to improve DNS privacy. If the parameter value is set 466 to 'true', QNAME minimisation is supported by the DNS server. 467 This is a mandatory attribute. 469 privacyurl: A URL that points to the privacy policy information of 470 the DNS server. This is a mandatory attribute. 472 auditurl: A URL that points to the security assessment report of the 473 DNS server by a third party auditor. This is an optional 474 attribute. 476 upstreamservers: The local DNS server can be configured as a 477 Forwarding DNS server [RFC8499] relying on the upstream resolver 478 (e.g., at an ISP) to perform recursive DNS lookups. The client 479 needs to discover the privacy policy information of both the 480 forwarder and recursive resolvers. This optional attribute has 481 the following structure: 483 securechannel: If DNS-over-TLS or DNS-over-HTTPS is used to 484 encrypt the DNS messages exchanged between the local DNS server 485 and recursive resolver, the parameter value is set to 'true'. 487 upstreamserverspat: The PAT object of the upstream DNS server. 488 If a local DNS server is configured as a Forwarding DNS server, 489 its PAT MUST include the PAT object of the upstream resolver it 490 is using. If the upstream DNS resolver does not communicate 491 its privacy policy, the attribute value must be set to empty 492 string. The client can combine the local and upstream 493 resolver's privacy policies, always combining for the worse 494 privacy values. For example, if the local server does not log 495 queries but the upstream resolver does log queries, the 496 combined PAT policy would indicate queries are logged and the 497 client can evaluate if its privacy preserving data policy 498 requirements are met. The Forwarding DNS server is typically 499 configured with both primary and secondary resolvers as a 500 backup mechanism to handle primary server failure. If the 501 local DNS server is configured to use primary and secondary 502 resolvers, 'upstreamserverspat' MUST include two entries in the 503 array. If the local DNS server is acting as a forwarder, it 504 RECOMMENDED that the DNS client requests the privacy policy 505 information of the server every time the connection is re- 506 established with the server. It allows the client to detect 507 change in the local DNS server configuration to use an 508 alternate resolver. 510 6.2.3. Example 512 The below Figure shows an example of privacy policy information. 514 { 515 "server":{ 516 "adn":["example.com"] 517 }, 518 "iat":1443208345, 519 "exp":1443640345, 520 "privinfo": { 521 "ipaddresspii":true, 522 "logging": 24, 523 "useridentity": 24, 524 "sharedata": { 525 "sharepartners": false 526 }, 527 "transferdata":false, 528 "privacyurl": "https://example.com/commitment-to-privacy/" 529 } 530 } 532 7. PAT Signature 534 The signature of the PAT is created as specified by JWS [RFC7515] 535 Section 5.1 Steps 1 through 6. PAT MUST use the JWS Protected 536 Header. For the JWS Payload and the JWS Protected Header, the 537 lexicographic ordering and white space rules described in Section 5 538 and Section 6, and JSON serialization rules in Section 9 of this 539 document MUST be followed. 541 The PAT is cryptographically signed by the domain hosting the DNS 542 server and optionally by a third party who performed privacy and 543 security audit of the DNS server. The privacy policy information 544 will be attested using "Organization Validation" (OV) or "Extended 545 Validation" (EV) certificates to avoid bad actors taking advantage of 546 this mechanism to advertise DNS-over-TLS and DNS-over-HTTPS servers 547 for illegitimate and fraudulent purposes meant to trick DNS clients 548 into believing that they are using a legitimate DNS-over-TLS or DNS- 549 over-HTTPS server hosted to provide privacy for DNS transactions. 550 Alternatively, the DNS client will have to be configured to trust the 551 leaf of the signer of the PAT object. That is, trust of the signer 552 MUST NOT be determined by validating the signer via the OS or browser 553 trust chain because that would allow any arbitrary entity to operate 554 a DNS server and assert any sort of privacy policy. 556 Appendix A of this document has a detailed example of how to follow 557 the steps to create the JWS Signature. 559 JWS [RFC7515] Section 5.1 Step 7 JWS JSON serialization is supported 560 for PAT to enable multiple signatures to be applied to the PAT 561 object. For example, the PAT object can be cryptographically signed 562 by the domain hosting the DNS server and by a third party who 563 performed privacy and security audit of the DNS server. 565 Appendix B of this document has a example of complete JWS JSON 566 serialization representation with multiple signatures. 568 JWS [RFC7515] Section 5.1 Step 8 describes the method to create the 569 final JWS Compact Serialization form of the PAT Token. 571 8. Extending PAT 573 PAT includes the minimum set of claims needed to securely assert the 574 privacy policy information of the DNS server. JWT supports a 575 straight forward way to add additional asserted or signed information 576 by simply adding new claims. PAT can be extended beyond the defined 577 base set of claims to represent other DNS server information 578 requiring assertion or validation. Specifying new claims follows the 579 baseline JWT procedures ([RFC7519] Section 10.1). Understanding new 580 claims on the DNS client is optional. The creator of a PAT object 581 cannot assume that the DNS client will understand the new claims. 583 9. Deterministic JSON Serialization 585 JSON objects can include spaces and line breaks, and key value pairs 586 can occur in any order. It is therefore a non-deterministic string 587 format. In order to make the digital signature verification work 588 deterministically, the JSON representation of the JWS Protected 589 Header object and JWS Payload object MUST be computed as follows. 591 The JSON object MUST follow the following rules. These rules are 592 based on the thumbprint of a JSON Web Key (JWK) as defined in 593 Section 3 Step 1 of [RFC7638]. 595 1. The JSON object MUST contain no whitespace or line breaks before 596 or after any syntactic elements. 598 2. JSON objects MUST have the keys ordered lexicographically by the 599 Unicode [UNICODE] code points of the member names. 601 3. JSON value literals MUST be lowercase. 603 4. JSON numbers are to be encoded as integers unless the field is 604 defined to be encoded otherwise. 606 5. Encoding rules MUST be applied recursively to member values and 607 array values. 609 9.1. Example PAT deterministic JSON form 611 This section demonstrates the deterministic JSON serialization for 612 the example PAT Payload shown in Section 6.2.3. 614 The initial JSON object is shown here: 616 { 617 "server":{ 618 "adn":["example.com"] 619 }, 620 "iat":1443208345, 621 "exp":1443640345, 622 "privinfo": { 623 "ipaddresspii":true, 624 "logging": 24, 625 "useridentity": 24, 626 "sharedata": { 627 "sharepartners": false 628 }, 629 "transferdata":false, 630 "privacyurl": "https://example.com/commitment-to-privacy/" 631 } 632 } 634 The parent members of the JSON object are as follows, in 635 lexicographic order: "exp", "iat", "privinfo", "server". 637 The final constructed deterministic JSON serialization 638 representation, with whitespace and line breaks removed, (with line 639 breaks used for display purposes only) is: 641 {"exp":1443640345,"iat":1443208345,"privinfo":{"ipaddresspii":true, 642 "logging":24,"privacyurl":"https://example.com/commitment-to-privacy/", 643 "sharedata":{"sharepartners":false},"transferdata":false, 644 "useridentity":24},"server":{"adn":["example.com"]}} 646 10. Privacy Considerations 648 Users are expected to indicate to their system in some way that they 649 trust certain PAT signers (e.g., if working for Example, Inc., the 650 user's system is configured to trust example.com signing the PAT). 651 Separately, the user is expected to indicate to their system their 652 PAT privacy requirements (e.g., logging, etc.). By doing so, the DNS 653 client can automatically discover local DNS-over-TLS or DNS-over- 654 HTTPS server, validate the PAT signature and check if the PAT 655 complies with user's privacy needs, prior to using that DNS-over-TLS 656 or DNS-over-HTTPS server for DNS queries. The client MAY also 657 retrieve the human-readable privacy statement from the 'privacyurl' 658 attribute to assist with that decision (e.g., display the privacy 659 statement when it changes, show differences in previously-retrieved 660 version, etc.). With the steps above, user consent is obtained prior 661 to using a locally-discovered DNS-over-TLS or DNS-over-HTTPS server 662 for DNS queries. 664 An average user may not be able to indicate the privacy preserving 665 data policy requirements to the system. For such users, the DNS 666 client should auto check if the PAT complies with typical users 667 privacy needs. For example, the client by default does not select 668 the local DNS-over-TLS or DNS-over-HTTPS server if it shares non- 669 anonymized DNS transaction data with partners or if it logs the DNS 670 transaction data for a very long duration. 672 11. Security Considerations 674 The use of PAT object based on the validation of the digital 675 signature and the associated certificate requires consideration of 676 the authentication and authority or reputation of the signer to 677 attest the privacy policy information of the DNS server being 678 asserted. Bad actors can host DNS-over-TLS and DNS-over-HTTPS 679 servers, and claim the servers offer privacy but exactly do the 680 opposite to invade the privacy of the user. Bad actor can get a 681 domain name, host DNS-over-TLS and DNS-over-HTTPS servers, and get 682 the DNS server certificate signed by a CA. The privacy policy 683 information will have to be attested using OV/EV certificates or a 684 PAT object signer trusted by the DNS client to prevent the attack. 686 If the PAT object is asserted by a third party, it can do a "time of 687 check" but the DNS server is susceptible of "time of use" attack. 688 For example, changes to privacy policy of the DNS server like sharing 689 identifiable transaction data with partners can cause a disagreement 690 between the PAT object and the DNS server operation. In other words, 691 the DNS server might have complied with the privacy policy when it 692 was audited (by the 3rd party) but could now be in non-compliance 693 with its privacy policy, hence the PAT object needs to be also 694 asserted by the domain hosting the DNS server. In addition, the PAT 695 object needs to have a short expiration time (e.g., 7 days) to ensure 696 the DNS server's domain re-asserts the privacy policy information and 697 limits the damage from change in privacy policy and mis-issuance. 699 12. IANA Considerations 700 12.1. Media Type Registration 702 12.1.1. Media Type Registry Contents Additions Requested 704 This section registers the "application/pat" media type [RFC2046] in 705 the "Media Types" registry in the manner described in [RFC6838], 706 which can be used to indicate that the content is a PAT defined JWT. 708 o Type name: application 710 o Subtype name: pat 712 o Required parameters: n/a 714 o Optional parameters: n/a 716 o Encoding considerations: 8bit; application/pat values are encoded 717 as a series of base64url-encoded values (some of which may be the 718 empty string) separated by period ('.') characters.. 720 o Security considerations: See the Security Considerations 721 Section of [RFC7515]. 723 o Interoperability considerations: n/a 725 o Published specification: [RFCThis] 727 o Applications that use this media type: DNS 729 o Fragment identifier considerations: n/a 731 o Additional information: 733 Magic number(s): n/a File extension(s): n/a Macintosh file type 734 code(s): n/a 736 o Person & email address to contact for further information: 737 Tirumaleswar Reddy, kondtir@gmail.com 739 o Intended usage: COMMON 741 o Restrictions on usage: none 743 o Author: Tirumaleswar Reddy, kondtir@gmail.com 745 o Change Controller: IESG 747 o Provisional registration? No 749 12.2. JSON Web Token Claims Registration 751 12.2.1. Registry Contents Additions Requested 753 o Claim Name: "server" 755 o Claim Description: DNS server identity 757 o Change Controller: IESG 759 o Specification Document(s): Section 6.2.1 of [TODO this document] 761 o Claim Name: "privinfo" 763 o Claim Description: Privacy policy information of DNS server. 765 o Change Controller: IESG 767 o Specification Document(s): Section 6.2.2 of [TODO this document] 769 12.3. DNS Resolver Information Registration 771 IANA will add the names ipaddresspii, logging, useridentity, 772 filtering, notifyuser, analytics, sharedata, transferdata, 773 qnameminimization, privacyurl, auditurl and upstreamserverpat to the 774 DNS Resolver Information registry defined in Section 5.2 of 775 [I-D.ietf-dnsop-resolver-information]. 777 13. Acknowledgments 779 This specification leverages some of the work that has been done in 780 [RFC8225]. Thanks to Ted Lemon, Paul Wouters and Shashank Jain for 781 the discussion and comments. 783 14. References 785 14.1. Normative References 787 [I-D.ietf-dnsop-resolver-information] 788 Sood, P., Arends, R., and P. Hoffman, "DNS Resolver 789 Information Self-publication", draft-ietf-dnsop-resolver- 790 information-00 (work in progress), August 2019. 792 [I-D.ietf-dnsop-terminology-bis] 793 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 794 Terminology", draft-ietf-dnsop-terminology-bis-14 (work in 795 progress), September 2018. 797 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 798 Extensions (MIME) Part Two: Media Types", RFC 2046, 799 DOI 10.17487/RFC2046, November 1996, 800 . 802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 803 Requirement Levels", BCP 14, RFC 2119, 804 DOI 10.17487/RFC2119, March 1997, 805 . 807 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 808 Resource Identifier (URI): Generic Syntax", STD 66, 809 RFC 3986, DOI 10.17487/RFC3986, January 2005, 810 . 812 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 813 Housley, R., and W. Polk, "Internet X.509 Public Key 814 Infrastructure Certificate and Certificate Revocation List 815 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 816 . 818 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 819 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 820 January 2012, . 822 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 823 Specifications and Registration Procedures", BCP 13, 824 RFC 6838, DOI 10.17487/RFC6838, January 2013, 825 . 827 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 828 Algorithm (DSA) and Elliptic Curve Digital Signature 829 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 830 2013, . 832 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 833 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 834 2015, . 836 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 837 DOI 10.17487/RFC7518, May 2015, 838 . 840 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 841 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 842 . 844 [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 845 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 846 2015, . 848 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 849 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 850 May 2017, . 852 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 853 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 854 . 856 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 857 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 858 . 860 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 861 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 862 January 2019, . 864 [UNICODE] The Unicode Consortium, "The Unicode Standard", June 2016, 865 . 867 14.2. Informative References 869 [I-D.ietf-dnsop-extended-error] 870 Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 871 Lawrence, "Extended DNS Errors", draft-ietf-dnsop- 872 extended-error-12 (work in progress), October 2019. 874 [I-D.ietf-dprive-bcp-op] 875 Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A. 876 Mankin, "Recommendations for DNS Privacy Service 877 Operators", draft-ietf-dprive-bcp-op-04 (work in 878 progress), October 2019. 880 [I-D.reddy-dprive-bootstrap-dns-server] 881 K, R., Wing, D., Richardson, M., and M. Boucadair, "A 882 Bootstrapping Procedure to Discover and Authenticate DNS- 883 over-(D)TLS and DNS-over-HTTPS Servers", draft-reddy- 884 dprive-bootstrap-dns-server-05 (work in progress), October 885 2019. 887 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 888 DOI 10.17487/RFC7626, August 2015, 889 . 891 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 892 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 893 . 895 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 896 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 897 . 899 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 900 for DNS over TLS and DNS over DTLS", RFC 8310, 901 DOI 10.17487/RFC8310, March 2018, 902 . 904 Appendix A. Example ES256 based PAT JWS Serialization and Signature 906 For PAT, there will always be a JWS with the following members: 908 o "protected", with the value BASE64URL(UTF8(JWS Protected Header)) 910 o "payload", with the value BASE64URL (JWS Payload) 912 o "signature", with the value BASE64URL(JWS Signature) 914 This example will follow the steps in JWS [RFC7515] Section 5.1, 915 steps 1-6 and 8 and incorporates the additional serialization steps 916 required for PAT. 918 Step 1 for JWS references the JWS Payload, an example PAT Payload is 919 as follows: 921 { 922 "server":{ 923 "adn":["example.com"] 924 }, 925 "iat":1443208345, 926 "exp":1443640345, 927 "privinfo": { 928 "ipaddresspii":true, 929 "logging": 24, 930 "useridentity": 24, 931 "sharedata": { 932 "sharepartners": false 933 }, 934 "transferdata":false, 935 "privacyurl": "https://example.com/commitment-to-privacy/" 936 } 937 } 938 This would be serialized to the form (with line break used for 939 display purposes only): 941 {"exp":1443640345,"iat":1443208345,"privinfo":{"ipaddresspii":true, 942 "logging":24,"privacyurl":"https://example.com/commitment-to-privacy/", 943 "sharedata":{"sharepartners":false},"transferdata":false, 944 "useridentity":24},"server":{"adn":["example.com"]}} 946 Step 2 Computes the BASE64URL(JWS Payload) producing this value (with 947 line break used for display purposes only): 949 eyJleHAiOjE0NDM2NDAzNDUsImlhdCI6MTQ0MzIwODM0NSwicHJpdmluZm8iOnsi 950 aXBhZGRyZXNzcGlpIjp0cnVlLCJsb2dnaW5nIjoyNCwicHJpdmFjeXVybCI6Imh0 951 dHBzOi8vZXhhbXBsZS5jb20vY29tbWl0bWVudC10by1wcml2YWN5LyIsInNoYXJl 952 ZGF0YSI6eyJzaGFyZXBhcnRuZXJzIjpmYWxzZX0sInRyYW5zZmVyZGF0YSI6ZmFs 953 c2UsInVzZXJpZGVudGl0eSI6MjR9LCJzZXJ2ZXIiOnsiYWRuIjpbImV4YW1wbGUu 954 Y29tIl19fQ 956 For Step 3, an example PAT Protected Header comprising the JOSE 957 Header is as follows: 959 { 960 "alg":"ES256", 961 "typ":"pat", 962 "x5u":"https://cert.example.com/pat.cer" 963 } 965 This would be serialized to the form (with line break used for 966 display purposes only): 968 {"alg":"ES256","typ":"pat","x5u":"https://cert.example.com 969 /pat.cer"} 971 Step 4 Performs the BASE64URL(UTF8(JWS Protected Header)) operation 972 and encoding produces this value (with line break used for display 973 purposes only): 975 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhdCIsIng1dSI6Imh0dHBzOi8vY2VydC5l 976 eGFtcGxlLmNvbS9wYXQuY2VyIn0 978 Step 5 and Step 6 performs the computation of the digital signature 979 of the PAT Signing Input ASCII(BASE64URL(UTF8(JWS Protected 980 Header)) || '.' || BASE64URL(JWS Payload)) using ES256 as the 981 algorithm and the BASE64URL(JWS Signature). 983 LEyaZpkJWVeJiQXdh6stCUo5VnLO56p9nTNsG8xhqpQMoJWc4j46Ze_43wPG-vHb 984 Xq7BaVIfdb_Lw3BcKr92Cw 986 Step 8 describes how to create the final PAT token, concatenating the 987 values in the order Header.Payload.Signature with period ('.') 988 characters. For the above example values this would produce the 989 following (with line breaks between period used for readability 990 purposes only): 992 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhdCIsIng1dSI6Imh0dHBzOi8vY2VydC5l 993 eGFtcGxlLmNvbS9wYXQuY2VyIn0 994 . 995 eyJleHAiOjE0NDM2NDAzNDUsImlhdCI6MTQ0MzIwODM0NSwicHJpdmluZm8iOnsi 996 aXBhZGRyZXNzcGlpIjp0cnVlLCJsb2dnaW5nIjoyNCwicHJpdmFjeXVybCI6Imh0 997 dHBzOi8vZXhhbXBsZS5jb20vY29tbWl0bWVudC10by1wcml2YWN5LyIsInNoYXJl 998 ZGF0YSI6eyJzaGFyZXBhcnRuZXJzIjpmYWxzZX0sInRyYW5zZmVyZGF0YSI6ZmFs 999 c2UsInVzZXJpZGVudGl0eSI6MjR9LCJzZXJ2ZXIiOnsiYWRuIjpbImV4YW1wbGUu 1000 Y29tIl19fQ 1001 . 1002 1ysb-n4O3YeN7HwPtzMP3SCEz28I80c78Lke4D_DRiwT8_-zi0p8IwmNU9778lOy 1003 Ub9WZehA89G4VMx8DDpm0Q 1005 A.1. X.509 Private Key in PKCS#8 format for ES256 Example** 1007 -----BEGIN PRIVATE KEY----- 1008 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgevZzL1gdAFr88hb2 1009 OF/2NxApJCzGCEDdfSp6VQO30hyhRANCAAQRWz+jn65BtOMvdyHKcvjBeBSDZH2r 1010 1RTwjmYSi9R/zpBnuQ4EiMnCqfMPWiZqB4QdbAd0E7oH50VpuZ1P087G 1011 -----END PRIVATE KEY----- 1013 A.2. X.509 Public Key for ES256 Example** 1015 -----BEGIN PUBLIC KEY----- 1016 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEVs/o5+uQbTjL3chynL4wXgUg2R9 1017 q9UU8I5mEovUf86QZ7kOBIjJwqnzD1omageEHWwHdBO6B+dFabmdT9POxg== 1018 -----END PUBLIC KEY----- 1020 Appendix B. Complete JWS JSON Serialization Representation with 1021 multiple Signatures 1023 The JWS payload used in this example as follows. 1025 { 1026 "server":{ 1027 "adn":["example.com"] 1028 }, 1029 "iat":1443208345, 1030 "exp":1443640345, 1031 "privinfo": { 1032 "ipaddresspii":true, 1033 "logging": 24, 1034 "useridentity": 24, 1035 "sharedata": { 1036 "sharepartners": false 1037 }, 1038 "transferdata":false, 1039 "privacyurl": "https://example.com/commitment-to-privacy/", 1040 "auditurl": "https://audit-example.com/privacyaudit" 1041 } 1042 } 1044 This would be serialized to the form (with line break used for 1045 display purposes only): 1047 {"auditurl":"https://audit-example.com/privacyaudit","exp":1443640345, 1048 "iat":1443208345,"privinfo":{"ipaddresspii":true,"logging":24, 1049 "privacyurl":"https://example.com/commitment-to-privacy/", 1050 "sharedata":{"sharepartners":false},"transferdata":false, 1051 "useridentity":24},"server":{"adn":["example.com"]}} 1053 The JWS protected Header value used for the first signature is same 1054 as that used in the example in Appendix A. The X.509 private key 1055 used for generating the first signature is same as that used in the 1056 example in Appendix A.1. 1058 The JWS Protected Header value used for the second signature is: 1060 { 1061 "alg":"ES384", 1062 "typ":"pat", 1063 "x5u":"https://cert.audit-example.com/pat.cer" 1064 } 1066 The complete JWS JSON Serialization for these values is as follows 1067 (with line breaks within values for display purposes only): 1069 { 1070 "payload": 1071 "eyJhdWRpdHVybCI6Imh0dHBzOi8vYXVkaXQtZXhhbXBsZS5jb20vcHJpdmFjeWF 1072 1ZGl0IiwiZXhwIjoxNDQzNjQwMzQ1LCJpYXQiOjE0NDMyMDgzNDUsInByaXZpbmZ 1073 vIjp7ImlwYWRkcmVzc3BpaSI6dHJ1ZSwibG9nZ2luZyI6MjQsInByaXZhY3l1cmw 1074 iOiJodHRwczovL2V4YW1wbGUuY29tL2NvbW1pdG1lbnQtdG8tcHJpdmFjeS8iLCJ 1075 zaGFyZWRhdGEiOnsic2hhcmVwYXJ0bmVycyI6ZmFsc2V9LCJ0cmFuc2ZlcmRhdGE 1076 iOmZhbHNlLCJ1c2VyaWRlbnRpdHkiOjI0fSwic2VydmVyIjp7ImFkbiI6WyJleGF 1077 tcGxlLmNvbSJdfX0", 1078 "signatures":[ 1079 {"protected":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhdCIsIng1dSI6Imh0dHB 1080 zOi8vY2VydC5leGFtcGxlLmNvbS9wYXQuY2VyIn0", 1081 "signature": 1082 "VeX23b4UNTRE358iXJGBnSnMXkIfrEYeZwA8aVKA1In-Nz5lpGVFXIjArnUY7T 1083 D9vMR01jUzTy4qVbtA0smbUA"}, 1084 {"protected":"eyJhbGciOiJFUzM4NCIsInR5cCI6InBhdCIsIng1dSI6Imh0dHB 1085 zOi8vY2VydC5hdWRpdC1leGFtcGxlLmNvbS9wYXQuY2VyIn0", 1086 "signature": 1087 "PKLgW0O3YZAv5ZlIMbQqOgCegAT_TUo6fshOuuGrPqBSYRgIb2ApfvCENzdp-f 1088 rKQEVUTWj2odSzMaEKBkjIv49GdEEvAxIy6C5uNzugfsGZswu7gyY8-9mZ_OFV 1089 -nWF"}] 1090 } 1092 B.1. X.509 Private Key in PKCS#8 format for E384 Example** 1094 -----BEGIN PRIVATE KEY----- 1095 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgevZzL1gdAFr88hb2 1096 OF/2NxApJCzGCEDdfSp6VQO30hyhRANCAAQRWz+jn65BtOMvdyHKcvjBeBSDZH2r 1097 1RTwjmYSi9R/zpBnuQ4EiMnCqfMPWiZqB4QdbAd0E7oH50VpuZ1P087G 1098 -----END PRIVATE KEY----- 1100 B.2. X.509 Public Key for ES384 Example** 1102 -----BEGIN PUBLIC KEY----- 1103 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEVs/o5+uQbTjL3chynL4wXgUg2R9 1104 q9UU8I5mEovUf86QZ7kOBIjJwqnzD1omageEHWwHdBO6B+dFabmdT9POxg== 1105 -----END PUBLIC KEY----- 1107 Authors' Addresses 1109 Tirumaleswar Reddy 1110 McAfee, Inc. 1111 Embassy Golf Link Business Park 1112 Bangalore, Karnataka 560071 1113 India 1115 Email: kondtir@gmail.com 1116 Dan Wing 1117 Citrix Systems, Inc. 1118 USA 1120 Email: dwing-ietf@fuggles.com 1122 Michael C. Richardson 1123 Sandelman Software Works 1124 USA 1126 Email: mcr+ietf@sandelman.ca