idnits 2.17.1 draft-ietf-webpush-vapid-03.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 18, 2017) is 2505 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186' ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) == Outdated reference: A later version (-09) exists of draft-ietf-webpush-encryption-08 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track P. Beverloo 5 Expires: December 20, 2017 Google 6 June 18, 2017 8 Voluntary Application Server Identification (VAPID) for Web Push 9 draft-ietf-webpush-vapid-03 11 Abstract 13 An application server can use the method described to voluntarily 14 identify itself to a push service. This identification information 15 can be used by the push service to attribute requests that are made 16 by the same application server to a single entity. An application 17 server can include additional information that the operator of a push 18 service can use to contact the operator of the application server. 19 This identification information can be used to restrict the use of a 20 push subscription a single application server. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 20, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Voluntary Identification . . . . . . . . . . . . . . . . 3 58 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 59 2. Application Server Self-Identification . . . . . . . . . . . 4 60 2.1. Application Server Contact Information . . . . . . . . . 4 61 2.2. Additional Claims . . . . . . . . . . . . . . . . . . . . 4 62 2.3. Cryptographic Agility . . . . . . . . . . . . . . . . . . 5 63 2.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Vapid Authentication Scheme . . . . . . . . . . . . . . . . . 6 65 3.1. Token Parameter (t) . . . . . . . . . . . . . . . . . . . 6 66 3.2. Public Key Parameter (k) . . . . . . . . . . . . . . . . 6 67 4. Subscription Restriction . . . . . . . . . . . . . . . . . . 7 68 4.1. Creating a Restricted Push Subscription . . . . . . . . . 7 69 4.2. Using Restricted Subscriptions . . . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 6.1. Vapid Authentication Scheme Registration . . . . . . . . 9 73 6.2. Vapid Authentication Scheme Parameters . . . . . . . . . 10 74 6.3. application/webpush-options+json Media Type Registration 10 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 8.2. Informative References . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 The Web Push protocol [RFC8030] describes how an application server 84 is able to request that a push service deliver a push message to a 85 user agent. 87 As a consequence of the expected deployment architecture, there is no 88 basis for an application server to be known to a push service prior 89 to requesting delivery of a push message. Requiring that the push 90 service be able to authenticate application servers places an 91 unwanted constraint on the interactions between user agents and 92 application servers, who are the ultimate users of a push service. 93 That constraint would also degrade the privacy-preserving properties 94 the protocol provides. For these reasons, [RFC8030] does not define 95 a mandatory system for authentication of application servers. 97 An unfortunate consequence of this design is that a push service is 98 exposed to a greater risk of denial of service attack. While 99 requests from application servers can be indirectly attributed to 100 user agents, this is not always efficient or even sufficient. 101 Providing more information about the application server directly to a 102 push service allows the push service to better distinguish between 103 legitimate and bogus requests. 105 Additionally, this design also relies on endpoint secrecy as any 106 application server in possession of the endpoint is able to send 107 messages, albeit without payloads. In situations where usage of a 108 subscription can be limited to a single application server, the 109 ability to associate a subscription with the application server could 110 reduce the impact of a data leak. 112 1.1. Voluntary Identification 114 This document describes a system whereby an application server can 115 volunteer information about itself to a push service. At a minimum, 116 this provides a stable identity for the application server, though 117 this could also include contact information, such as an email 118 address. 120 A consistent identity can be used by a push service to establish 121 behavioral expectations for an application server. Significant 122 deviations from an established norm can then be used to trigger 123 exception handling procedures. 125 Voluntarily-provided contact information can be used to contact an 126 application server operator in the case of exceptional situations. 128 Experience with push service deployment has shown that software 129 errors or unusual circumstances can cause large increases in push 130 message volume. Contacting the operator of the application server 131 has proven to be valuable. 133 Even in the absence of usable contact information, an application 134 server that has a well-established reputation might be given 135 preference over an unidentified application server when choosing 136 whether to discard a push message. 138 1.2. Notational Conventions 140 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 141 document. It's not shouting, when they are capitalized, they have 142 the special meaning described in [RFC2119]. 144 The terms "push message", "push service", "push subscription", 145 "application server", and "user agent" are used as defined in 146 [RFC8030]. 148 2. Application Server Self-Identification 150 Application servers that wish to self-identify generate and maintain 151 a signing key pair. This key pair MUST be usable with elliptic curve 152 digital signature (ECDSA) over the P-256 curve [FIPS186]. Use of 153 this key when sending push messages establishes an identity for the 154 application server that is consistent across multiple messages. 156 When requesting delivery of a push message, the application includes 157 a JSON Web Token (JWT) [RFC7519], signed using its signing key. The 158 token includes a number of claims as follows: 160 o An "aud" (Audience) claim in the token MUST include the unicode 161 serialization of the origin (Section 6.1 of [RFC6454]) of the push 162 resource URL. This binds the token to a specific push service. 163 This ensures that the token is reusable for all push resource URLs 164 that share the same origin. 166 o An "exp" (Expiry) claim MUST be included with the time after which 167 the token expires. This limits the time over which a token is 168 valid. An "exp" claim MUST NOT be more than 24 hours from the 169 time of the request. 171 This JWT is included in an Authorization header field, using an auth- 172 scheme of "vapid". A push service MAY reject a request with a 403 173 (Forbidden) status code [RFC7235] if the JWT signature or its claims 174 are invalid. 176 The JWT MUST use a JSON Web Signature (JWS) [RFC7515]. The signature 177 MUST use ECDSA on the NIST P-256 curve [FIPS186] which is identified 178 as "ES256" [RFC7518]. 180 2.1. Application Server Contact Information 182 If the application server wishes to provide contact details it MAY 183 include a "sub" (Subject) claim in the JWT. The "sub" claim SHOULD 184 include a contact URI for the application server as either a 185 "mailto:" (email) [RFC6068] or an "https:" [RFC2818] URI. 187 2.2. Additional Claims 189 An application server MAY include additional claims using public or 190 private names (see Sections 4.2 and 4.3 of [RFC7519]). Since the JWT 191 is in a header field, the size of additional claims SHOULD be kept as 192 small as possible. 194 2.3. Cryptographic Agility 196 The "vapid" authentication scheme is used to identify the specific 197 profile of JWT defined in this document. A different authentication 198 scheme is needed to update the signature algorithm or other 199 parameters. This ensures that existing mechanisms for negotiating 200 authentication scheme can be used rather than defining new parameter 201 negotiation mechanisms. 203 2.4. Example 205 An application server requests the delivery of a push message as 206 described in [RFC8030]. If the application server wishes to self- 207 identify, it includes an Authorization header field with credentials 208 that use the "vapid" authentication scheme (Section 3). 210 POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 211 Host: push.example.net 212 TTL: 30 213 Content-Length: 136 214 Content-Encoding: aes128gcm 215 Authorization: vapid 216 t=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3 217 B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1ha 218 Wx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_H 219 LGkMlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA, 220 k=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-dR 221 uU_RCPCfA5aq9ojSwk5Y2EmClBPs 223 { encrypted push message } 225 Figure 1: Requesting Push Message Delivery with JWT 227 Note that the example header fields in this document include extra 228 line wrapping to meet formatting constraints. 230 The "t" parameter of the Authorization header field contains a JWT; 231 the "k" parameter includes the base64url-encoded key that signed that 232 token. The JWT input values and the JWK [RFC7517] corresponding to 233 the signing key are shown in Figure 2 with additional whitespace 234 added for readability purposes. This JWT would be valid until 235 2016-01-23T04:36:08Z [RFC3339]. 237 JWT header = { "typ": "JWT", "alg": "ES256" } 238 JWT body = { "aud": "https://push.example.net", 239 "exp": 1453523768, 240 "sub": "mailto:push@example.com" } 241 JWK = { "crv":"P-256", 242 "kty":"EC", 243 "x":"DUfHPKLVFQzVvnCPGyfucbECzPDa7rWbXriLcysAjEc", 244 "y":"F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" } 246 Figure 2: Decoded Example Values 248 3. Vapid Authentication Scheme 250 A new "vapid" HTTP authentication scheme [RFC7235] is defined. This 251 authentication scheme carries a signed JWT, as described in 252 Section 2, plus the key that signed that JWT. 254 This authentication scheme is for origin-server authentication only. 255 Therefore, this authentication scheme MUST NOT be used with the 256 Proxy-Authenticate or Proxy-Authorization header fields. 258 This authentication scheme does not require a challenge. Clients are 259 able to generate the Authorization header field without any 260 additional information from a server. Therefore, a challenge for 261 this authentication scheme MUST NOT be sent in a WWW-Authenticate 262 header field. 264 Two parameters are defined for this authentication scheme: "t" and 265 "k". All unknown or unsupported parameters to "vapid" authentication 266 credentials MUST be ignored. The "realm" parameter is ignored for 267 this authentication scheme. 269 This authentication scheme is intended for use by an application 270 server when using the Web Push protocol [RFC8030], but it could be 271 used in other contexts if applicable. 273 3.1. Token Parameter (t) 275 The "t" parameter of the "vapid" authentication scheme carries a JWT 276 as described in Section 2. 278 3.2. Public Key Parameter (k) 280 In order for the push service to be able to validate the JWT, it 281 needs to learn the public key of the application server. A "k" 282 parameter is defined for the "vapid" authentication scheme to carry 283 this information. 285 The "k" parameter includes an elliptic curve digital signature 286 algorithm (ECDSA) public key [FIPS186] in uncompressed form [X9.62] 287 that is encoded using base64url encoding [RFC7515]. 289 Note: X9.62 encoding is used over JWK [RFC7517] for two reasons. A 290 JWK does not have a canonical form, so X9.62 encoding makes it 291 easier for the push service to handle comparison of keys from 292 different sources. Secondarily, the X9.62 encoding is also 293 considerably smaller. 295 Some implementations permit the same P-256 key to be used for signing 296 and key exchange. An application server MUST select a different 297 private key for the key exchange [I-D.ietf-webpush-encryption] and 298 signing the authentication token. Though a push service is not 299 obligated to check either parameter for every push message, a push 300 service SHOULD reject push messages that have identical values for 301 these parameters with a 400 (Bad Request) status code. 303 4. Subscription Restriction 305 The public key of the application server serves as a stable 306 identifier for the server. This key can be used to restrict a push 307 subscription to a specific application server. 309 Subscription restriction reduces the reliance on endpoint secrecy by 310 requiring proof of possession to be demonstrated by an application 311 server when requesting delivery of a push message. This provides an 312 additional level of protection against leaking of the details of the 313 push subscription. 315 4.1. Creating a Restricted Push Subscription 317 The user agent includes the public key of the application server when 318 requesting the creation of a push subscription. This restricts use 319 of the resulting subscription to application servers that are able to 320 provide proof of possession for the corresponding private key. 322 The public key is then added to the request to create a push 323 subscription. The push subscription request is extended to include a 324 body. The body of the request is a JSON object as described in 325 [RFC7159]. A "vapid" member is added to this JSON object, containing 326 the public key on the P-256 curve, encoded in the uncompressed form 327 [X9.62] and base64url encoded [RFC7515]. The media type of the body 328 is set to "application/webpush-options+json" (see Section 6.3 for 329 registration of this media type). 331 A push service MUST ignore the body of a request that uses a 332 different media type. For the "application/webpush-options+json" 333 media type, a push service MUST ignore any members on this object 334 that it does not understand. 336 The example in Figure 3 shows a restriction to the key used in 337 Figure 1. Extra whitespace is added to meet formatting constraints. 339 POST /subscribe/ HTTP/1.1 340 Host: push.example.net 341 Content-Type: application/webpush-optjons+json;charset=utf-8 342 Content-Length: 104 344 { "vapid": "BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH 345 F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" } 347 Figure 3: Example Subscribe Request 349 An application might use the Web Push API [API] to provide the user 350 agent with a public key. 352 4.2. Using Restricted Subscriptions 354 When a push subscription has been associated with an application 355 server, the request for push message delivery MUST include proof of 356 possession for the associated private key that was used when creating 357 the push subscription. 359 A push service MUST reject a message that omits mandatory credentials 360 with a 401 (Unauthorized) status code. A push service MAY reject a 361 message that includes invalid credentials with a 403 (Forbidden) 362 status code. Credentials are invalid if: 364 o either the authentication token or public key are not included in 365 the request, 367 o the signature on the JWT cannot be successfully verified using the 368 included public key, 370 o the current time is later than the time identified in the "exp" 371 (Expiry) claim or more than 24 hours before the expiry time, 373 o the origin of the push resource is not included in the "aud" 374 (Audience) claim, or 376 o the public key used to sign the JWT doesn't match the one that was 377 included in the creation of the push subscription. 379 A push service MUST NOT forward the JWT or public key to the user 380 agent when delivering the push message. 382 An application server that needs to replace its signing key needs to 383 create a new subscription that is restricted to the updated key. 384 Application servers need to remember the key that was used when 385 creating a given subscription. 387 5. Security Considerations 389 This authentication scheme is vulnerable to replay attacks if an 390 attacker can acquire a valid JWT. Applying narrow limits to the 391 period over which a replayable token can be reused limits the 392 potential value of a stolen token to an attacker and can increase the 393 difficulty of stealing a token. 395 An application server might offer falsified contact information. A 396 push service operator therefore cannot use the presence of 397 unvalidated contact information as input to any security-critical 398 decision-making process. 400 Validation of a signature on the JWT requires a non-trivial amount of 401 computation. For something that might be used to identify legitimate 402 requests under denial of service attack conditions, this is not 403 ideal. Application servers are therefore encouraged to reuse tokens, 404 which permits the push service to cache the results of signature 405 validation. 407 An application server that changes its signing key breaks linkability 408 between push messages that it sends under the different keys. A push 409 service that relies on a consistent identity for application servers 410 might categorize requests made with new keys differently. Gradual 411 migration to a new signing key reduces the chances that requests that 412 use the new key will be categorized as abusive. 414 6. IANA Considerations 416 This document registers a new authentication scheme, a registry for 417 parameters of that scheme, and media type for push options. 419 6.1. Vapid Authentication Scheme Registration 421 This document registers the "vapid" authentication scheme in the 422 "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" 423 established in [RFC7235]. 425 Authentication Scheme Name: vapid 427 Pointer to specification text: Section 3 of this document 428 Notes: This scheme is origin-server only and does not define a 429 challenge. 431 6.2. Vapid Authentication Scheme Parameters 433 This document creates a "Vapid Authentication Scheme Parameters" 434 registry for parameters to the "vapid" authentication scheme. This 435 registry is under the "WebPush Parameters" grouping. The registry 436 operates on the "Specification Required" policy [RFC5226]. 438 Registrations MUST include the following information: 440 Parameter Name: A name for the parameter, which conforms to the 441 "token" grammar [RFC7230] 443 Purpose (optional): A brief identifying the purpose of the 444 parameter. 446 Specification: A link to the specification that defines the format 447 and semantics of the parameter. 449 This registry initially contains the following entries: 451 +---------------+-------------------------+-------------------------+ 452 | Parameter | Purpose | Specification | 453 | Name | | | 454 +---------------+-------------------------+-------------------------+ 455 | t | JWT authentication | [[RFC-to-be]], Section | 456 | | token | 3.1 | 457 | | | | 458 | k | signing key | [[RFC-to-be]], Section | 459 | | | 3.2 | 460 +---------------+-------------------------+-------------------------+ 462 6.3. application/webpush-options+json Media Type Registration 464 This document registers the "application/webpush-options+json" media 465 type in the "Media Types" registry following the process described in 466 [RFC6838]. 468 Type name: application 470 Subtype name: webpush-options+json 472 Required parameters: n/a 474 Optional parameters: n/a 475 Encoding considerations: binary 477 Security considerations: See [RFC7159] for security considerations 478 specific to JSON. 480 Interoperability considerations: See [RFC7159] for interoperability 481 considerations specific to JSON. 483 Published specification: This document. 485 Applications that use this media type: Web browsers, via the Web 486 Push Protocol [RFC8030]. 488 Fragment identifier considerations: None, see [RFC7159]. 490 Additional information: 492 Deprecated alias names for this type: n/a 494 Magic number(s): n/a 496 File extension(s): .json 498 Macintosh file type code(s): TEXT 500 Person & email address to contact for further information: Martin 501 Thomson (martin.thomson@gmail.com) 503 Intended usage: LIMITED USE 505 Restrictions on usage: For use with the Web Push Protocol [RFC8030]. 507 Author: See "Authors' Addresses" section of this document. 509 Change controller: Internet Engineering Task Force 511 7. Acknowledgements 513 This document would have been much worse than it currently is if not 514 for the contributions of Benjamin Bangert, JR Conlin, Chris Karlof, 515 Costin Manolache, Adam Roach, and others. 517 8. References 518 8.1. Normative References 520 [FIPS186] National Institute of Standards and Technology (NIST), 521 "Digital Signature Standard (DSS)", NIST PUB 186-4 , July 522 2013. 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, 526 DOI 10.17487/RFC2119, March 1997, 527 . 529 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 530 DOI 10.17487/RFC2818, May 2000, 531 . 533 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 534 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 535 DOI 10.17487/RFC5226, May 2008, 536 . 538 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 539 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, 540 . 542 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 543 DOI 10.17487/RFC6454, December 2011, 544 . 546 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 547 Specifications and Registration Procedures", BCP 13, 548 RFC 6838, DOI 10.17487/RFC6838, January 2013, 549 . 551 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 552 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 553 2014, . 555 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 556 Protocol (HTTP/1.1): Message Syntax and Routing", 557 RFC 7230, DOI 10.17487/RFC7230, June 2014, 558 . 560 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 561 Protocol (HTTP/1.1): Authentication", RFC 7235, 562 DOI 10.17487/RFC7235, June 2014, 563 . 565 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 566 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 567 2015, . 569 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 570 DOI 10.17487/RFC7518, May 2015, 571 . 573 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 574 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 575 . 577 [RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic 578 Event Delivery Using HTTP Push", RFC 8030, 579 DOI 10.17487/RFC8030, December 2016, 580 . 582 [X9.62] ANSI, "Public Key Cryptography For The Financial Services 583 Industry: The Elliptic Curve Digital Signature Algorithm 584 (ECDSA)", ANSI X9.62 , 1998. 586 8.2. Informative References 588 [API] Beverloo, P., Thomson, M., van Ouwerkerk, M., Sullivan, 589 B., and E. Fullea, "Push API", May 2017, 590 . 592 [I-D.ietf-webpush-encryption] 593 Thomson, M., "Message Encryption for Web Push", draft- 594 ietf-webpush-encryption-08 (work in progress), February 595 2017. 597 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 598 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 599 . 601 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 602 DOI 10.17487/RFC7517, May 2015, 603 . 605 Authors' Addresses 607 Martin Thomson 608 Mozilla 610 Email: martin.thomson@gmail.com 611 Peter Beverloo 612 Google 614 Email: beverloo@google.com