draft-ietf-webpush-vapid-01.txt   draft-ietf-webpush-vapid-02.txt 
Network Working Group M. Thomson Network Working Group M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track P. Beverloo Intended status: Standards Track P. Beverloo
Expires: December 31, 2016 Google Expires: June 25, 2017 Google
June 29, 2016 December 22, 2016
Voluntary Application Server Identification for Web Push Voluntary Application Server Identification for Web Push
draft-ietf-webpush-vapid-01 draft-ietf-webpush-vapid-02
Abstract Abstract
An application server can voluntarily identify itself to a push An application server can voluntarily identify itself to a push
service using the described technique. This identification service using the described technique. This identification
information can be used by the push service to attribute requests information can be used by the push service to attribute requests
that are made by the same application server to a single entity. that are made by the same application server to a single entity.
This can used to reduce the secrecy for push subscription URLs by This can used to reduce the secrecy for push subscription URLs by
being able to restrict subscriptions to a specific application being able to restrict subscriptions to a specific application
server. An application server is further able to include additional server. An application server is further able to include additional
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2016. This Internet-Draft will expire on June 25, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Voluntary Identification . . . . . . . . . . . . . . . . 3 1.1. Voluntary Identification . . . . . . . . . . . . . . . . 3
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Application Server Self-Identification . . . . . . . . . . . 4 2. Application Server Self-Identification . . . . . . . . . . . 4
2.1. Application Server Contact Information . . . . . . . . . 4 2.1. Application Server Contact Information . . . . . . . . . 4
2.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Additional Claims . . . . . . . . . . . . . . . . . . . . 4
3. WebPush Authentication Scheme . . . . . . . . . . . . . . . . 5 2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Public Key Representation . . . . . . . . . . . . . . . . . . 6 3. Vapid Authentication Scheme . . . . . . . . . . . . . . . . . 6
5. Subscription Restriction . . . . . . . . . . . . . . . . . . 6 3.1. Token Parameter (t) . . . . . . . . . . . . . . . . . . . 6
5.1. Creating a Restricted Push Subscription . . . . . . . . . 7 3.2. Public Key Parameter (k) . . . . . . . . . . . . . . . . 6
5.2. Using Restricted Subscriptions . . . . . . . . . . . . . 7 4. Subscription Restriction . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4.1. Creating a Restricted Push Subscription . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.2. Using Restricted Subscriptions . . . . . . . . . . . . . 8
7.1. WebPush Authentication Scheme . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7.2. p256ecdsa Parameter for Crypto-Key Header Field . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Vapid Authentication Scheme Parameters . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Web Push protocol [I-D.ietf-webpush-protocol] describes how an The Web Push protocol [I-D.ietf-webpush-protocol] describes how an
application server is able to request that a push service deliver a application server is able to request that a push service deliver a
push message to a user agent. push message to a user agent.
As a consequence of the expected deployment architecture, there is no As a consequence of the expected deployment architecture, there is no
basis for an application server to be known to a push service prior basis for an application server to be known to a push service prior
to requesting delivery of a push message. Requiring that the push to requesting delivery of a push message. Requiring that the push
skipping to change at page 4, line 7 skipping to change at page 4, line 11
The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this
document. It's not shouting, when they are capitalized, they have document. It's not shouting, when they are capitalized, they have
the special meaning described in [RFC2119]. the special meaning described in [RFC2119].
The terms "push message", "push service", "push subscription", The terms "push message", "push service", "push subscription",
"application server", and "user agent" are used as defined in "application server", and "user agent" are used as defined in
[I-D.ietf-webpush-protocol]. [I-D.ietf-webpush-protocol].
2. Application Server Self-Identification 2. Application Server Self-Identification
Application servers that wish to self-identity generate and maintain Application servers that wish to self-identify generate and maintain
a signing key pair. This key pair MUST be usable with elliptic curve a signing key pair. This key pair MUST be usable with elliptic curve
digital signature (ECDSA) over the P-256 curve [FIPS186]. Use of digital signature (ECDSA) over the P-256 curve [FIPS186]. Use of
this key when sending push messages establishes an identity for the this key when sending push messages establishes an identity for the
application server that is consistent across multiple messages. application server that is consistent across multiple messages.
When requesting delivery of a push message, the application includes When requesting delivery of a push message, the application includes
a JSON Web Token (JWT) [RFC7519], signed using its signing key. The a JSON Web Token (JWT) [RFC7519], signed using its signing key. The
token includes a number of claims as follows: token includes a number of claims as follows:
o An "aud" (Audience) claim in the token MUST include the unicode o An "aud" (Audience) claim in the token MUST include the unicode
skipping to change at page 4, line 29 skipping to change at page 4, line 33
resource URL. This binds the token to a specific push service. resource URL. This binds the token to a specific push service.
This ensures that the token is reusable for all push resource URLs This ensures that the token is reusable for all push resource URLs
that share the same origin. that share the same origin.
o An "exp" (Expiry) claim MUST be included with the time after which o An "exp" (Expiry) claim MUST be included with the time after which
the token expires. This limits the time that a token over which a the token expires. This limits the time that a token over which a
token is valid. An "exp" claim MUST NOT be more than 24 hours token is valid. An "exp" claim MUST NOT be more than 24 hours
from the time of the request. from the time of the request.
This JWT is included in an Authorization header field, using an auth- This JWT is included in an Authorization header field, using an auth-
scheme of "WebPush". A push service MAY reject a request with a 403 scheme of "vapid". A push service MAY reject a request with a 403
(Forbidden) status code [RFC7235] if the JWT signature or its claims (Forbidden) status code [RFC7235] if the JWT signature or its claims
are invalid. are invalid.
The JWT MUST use a JSON Web Signature (JWS) [RFC7515]. The signature The JWT MUST use a JSON Web Signature (JWS) [RFC7515]. The signature
MUST use ECDSA on the NIST P-256 curve [FIPS186], that is "ES256" MUST use ECDSA on the NIST P-256 curve [FIPS186] which is identified
[RFC7518]. as "ES256" [RFC7518].
2.1. Application Server Contact Information 2.1. Application Server Contact Information
If the application server wishes to provide contact details it MAY If the application server wishes to provide contact details it MAY
include an "sub" (Subject) claim in the JWT. The "sub" claim SHOULD include a "sub" (Subject) claim in the JWT. The "sub" claim SHOULD
include a contact URI for the application server as either a include a contact URI for the application server as either a
"mailto:" (email) [RFC6068] or an "https:" [RFC2818] URI. "mailto:" (email) [RFC6068] or an "https:" [RFC2818] URI.
2.2. Example 2.2. Additional Claims
An application server MAY include additional claims using public or
private names (see Sections 4.2 and 4.3 of [RFC7519]). Since the JWT
is in a header field, the size of additional claims SHOULD be kept as
small as possible.
2.3. Example
An application server requests the delivery of a push message as An application server requests the delivery of a push message as
described in [I-D.ietf-webpush-protocol]. If the application server described in [I-D.ietf-webpush-protocol]. If the application server
wishes to self-identify, it includes an Authorization header field wishes to self-identify, it includes an Authorization header field
with credentials that use the "WebPush" authentication scheme with credentials that use the "vapid" authentication scheme
Section 3 and a Crypto-Key header field that includes its public key (Section 3).
Section 4.
POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net Host: push.example.net
Content-Type: text/plain;charset=utf8 TTL: 30
Content-Length: 36 Content-Length: 136
Authorization: WebPush Content-Encoding: aes128gcm
eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3B Authorization: vapid
1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1haWx t=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3
0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_HLGk B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1ha
MlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA Wx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_H
Crypto-Key: p256ecdsa=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH LGkMlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA,
F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs k=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-dR
uU_RCPCfA5aq9ojSwk5Y2EmClBPs
iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB { encrypted push message }
Figure 1: Requesting Push Message Delivery with JWT Figure 1: Requesting Push Message Delivery with JWT
Note that the header fields shown in Figure 1 don't include line Note that the example header fields in this document include extra
wrapping. Extra whitespace is added to meet formatting constraints. line wrapping to meet formatting constraints.
The value of the Authorization header field is a base64url-encoded The "t" parameter of the Authorization header field contains a JWT;
JWT with the header and body shown in Figure 2. This JWT would be the "k" parameter includes the base64url-encoded key that signed that
valid until 2016-01-21T01:53:25Z [RFC3339]. token. The JWT input values and the JWK [RFC7517] corresponding to
the signing key are shown in Figure 2 with additional whitespace
added for readability purposes. This JWT would be valid until
2016-01-21T01:53:25Z [RFC3339].
header = {"typ":"JWT","alg":"ES256"} JWT header = { "typ": "JWT", "alg": "ES256" }
body = { "aud":"https://push.example.net", JWT body = { "aud": "https://push.example.net",
"exp":1453341205, "exp": 1453341205,
"sub":"mailto:push@example.com" } "sub": "mailto:push@example.com" }
JWK = { "crv":"P-256",
"kty":"EC",
"x":"DUfHPKLVFQzVvnCPGyfucbECzPDa7rWbXriLcysAjEc",
"y":"F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }
Figure 2: Example JWT Header and Body Figure 2: Decoded Example Values
3. WebPush Authentication Scheme 3. Vapid Authentication Scheme
A new "WebPush" HTTP authentication scheme [RFC7235] is defined. A new "vapid" HTTP authentication scheme [RFC7235] is defined. This
This authentication scheme carries a signed JWT, as described in authentication scheme carries a signed JWT, as described in
Section 2. Section 2, plus the key that signed that JWT.
This authentication scheme is for origin-server authentication only. This authentication scheme is for origin-server authentication only.
Therefore, this authentication scheme MUST NOT be used with the Therefore, this authentication scheme MUST NOT be used with the
Proxy-Authenticate or Proxy-Authorization header fields. Proxy-Authenticate or Proxy-Authorization header fields.
This authentication scheme does not require a challenge. Clients are This authentication scheme does not require a challenge. Clients are
able to generate the Authorization header field without any able to generate the Authorization header field without any
additional information from a server. Therefore, a challenge for additional information from a server. Therefore, a challenge for
this authentication scheme MUST NOT be sent in a WWW-Authenticate this authentication scheme MUST NOT be sent in a WWW-Authenticate
header field. header field.
All unknown or unsupported parameters to "WebPush" authentication Two parameters are defined for this authentication scheme: "t" and
"k". All unknown or unsupported parameters to "vapid" authentication
credentials MUST be ignored. The "realm" parameter is ignored for credentials MUST be ignored. The "realm" parameter is ignored for
this authentication scheme. this authentication scheme.
4. Public Key Representation This authentication scheme is intended for use by an application
server when using the Web Push protocol [I-D.ietf-webpush-protocol],
but it could be used in other contexts if applicable.
3.1. Token Parameter (t)
The "t" parameter of the "vapid" authentication scheme carries a JWT
as described in Section 2.
3.2. Public Key Parameter (k)
In order for the push service to be able to validate the JWT, it In order for the push service to be able to validate the JWT, it
needs to learn the public key of the application server. A needs to learn the public key of the application server. A "k"
"p256ecdsa" parameter is defined for the Crypto-Key header field parameter is defined for the "vapid" authentication scheme to carry
[I-D.ietf-httpbis-encryption-encoding] to carry this information. this information.
The "p256ecdsa" parameter includes an elliptic curve digital The "k" parameter includes an elliptic curve digital signature
signature algorithm (ECDSA) public key [FIPS186] in uncompressed form algorithm (ECDSA) public key [FIPS186] in uncompressed form [X9.62]
[X9.62] that is encoded using the URL- and filename-safe variant of that is encoded using base64url encoding [RFC7515].
base-64 [RFC4648] with padding removed.
Note that with push message encryption [I-D.ietf-webpush-encryption], Note: X9.62 encoding is used over JWK [RFC7517] for two reasons. A
this results in two values in the Crypto-Key header field, one with JWK does not have a canonical form, so X9.62 encoding makes it
the a "dh" key and another with a "p256ecdsa" key. easier for the push service to handle comparison of keys from
different sources. Secondarily, the X9.62 encoding is also
considerably smaller.
Some implementations permit the same P-256 key to be used for signing Some implementations permit the same P-256 key to be used for signing
and key exchange. An application server MUST select a different and key exchange. An application server MUST select a different
private key for the key exchange (i.e., "dh") and signing (i.e., private key for the key exchange [I-D.ietf-webpush-encryption] and
"p256ecdsa"). Though a push service is not obligated to check either signing the authentication token. Though a push service is not
parameter for every push message, a push service SHOULD reject push obligated to check either parameter for every push message, a push
messages that have identical values for these parameters with a 400 service SHOULD reject push messages that have identical values for
(Bad Request) status code. these parameters with a 400 (Bad Request) status code.
Editor's Note: JWK [RFC7517] seems like the obvious choice here.
However, JWK doesn't define a compact representation for public
keys, which complicates the representation of JWK in a header
field.
5. Subscription Restriction 4. Subscription Restriction
The public key of the application server serves as a stable The public key of the application server serves as a stable
identifier for the server. This key can be used to restrict a push identifier for the server. This key can be used to restrict a push
subscription to a specific application server. subscription to a specific application server.
Subscription restriction reduces the reliance on endpoint secrecy by Subscription restriction reduces the reliance on endpoint secrecy by
requiring proof of possession to be demonstrated by an application requiring proof of possession to be demonstrated by an application
server when requesting delivery of a push message. This provides an server when requesting delivery of a push message. This provides an
additional level of protection against leaking of the details of the additional level of protection against leaking of the details of the
push subscription. push subscription.
5.1. Creating a Restricted Push Subscription 4.1. Creating a Restricted Push Subscription
The user agent includes the public key of the application server when The user agent includes the public key of the application server when
requesting the creation of a push subscription. This restricts use requesting the creation of a push subscription. This restricts use
of the resulting subscription to application servers that are able to of the resulting subscription to application servers that are able to
provide proof of possession for the corresponding private key. provide proof of possession for the corresponding private key.
This public key is then added to the request to create a push The public key is then added to the request to create a push
subscription as described in Section 4. The Crypto-Key header field subscription. The push subscription request is extended to include a
includes exactly one public key. For example: body. The body of the request is a JSON object as described in
[RFC7159]. A "vapid" member is added to this JSON object, containing
the public key on the P-256 curve, encoded in the uncompressed form
[X9.62] and base64url encoded [RFC7515]. The MIME media type of the
body is set to "application/json".
The example in Figure 3 shows a restriction to the key used in
Figure 1. Extra whitespace is added to to meet formatting
constraints.
POST /subscribe/ HTTP/1.1 POST /subscribe/ HTTP/1.1
Host: push.example.net Host: push.example.net
Crypto-Key: p256ecdsa=BBa22H8qaZ-iDMH9izb4qE72puwyvfjH2RxoQr5oiS4b Content-Type: application/json;charset=utf-8
KImoRwJm5xK9hLrbfIik20g31z8MpLFMCMr8y2cu6gY Content-Length: 104
Figure 3: Example Subscribe Request { "vapid": "BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH
F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }
An application might use the Web Push API [API] to include this Figure 3: Example Subscribe Request
information. For example, the API might permit an application to
provide a public key as part of a new field on the
"PushSubscriptionOptions" dictionary.
Note: Allowing the inclusion of multiple keys when creating a An application might use the Web Push API [API] to provide the user
subscription would allow a subscription to be associated with agent with a public key.
multiple application servers or application server instances.
This might be more flexible, but it also would require more state
to be maintained by the push service for each subscription.
5.2. Using Restricted Subscriptions 4.2. Using Restricted Subscriptions
When a push subscription has been associated with an application When a push subscription has been associated with an application
server, the request for push message delivery MUST include proof of server, the request for push message delivery MUST include proof of
possession for the associated private key that was used when creating possession for the associated private key that was used when creating
the push subscription. the push subscription.
A push service MUST reject a message that omits mandatory credentials A push service MUST reject a message that omits mandatory credentials
with a 401 (Unauthorized) status code. A push service MAY reject a with a 401 (Unauthorized) status code. A push service MAY reject a
message that includes invalid credentials with a 403 (Forbidden) message that includes invalid credentials with a 403 (Forbidden)
status code. Credentials are invalid if: status code. Credentials are invalid if:
o either the authentication credentials or public key are not o either the authentication token or public key are not included in
included in the request, the request,
o the signature on the JWT cannot be successfully verified using the o the signature on the JWT cannot be successfully verified using the
included public key, included public key,
o the current time is later than the time identified in the "exp" o the current time is later than the time identified in the "exp"
(Expiry) claim or more than 24 hours before the expiry time, (Expiry) claim or more than 24 hours before the expiry time,
o the origin of the push resource is not included in the "aud" o the origin of the push resource is not included in the "aud"
(Audience) claim, or (Audience) claim, or
o the public key used to sign the JWT doesn't match the one that was o the public key used to sign the JWT doesn't match the one that was
included in the creation of the push message. included in the creation of the push subscription.
Note: In theory, since the push service was given a public key, the
push message request could omit the public key. On balance,
requiring the key keeps things simple and it allows push services
to compress the public key (by hashing it, for example). In any
case, the relatively minor space savings aren't particularly
important on the connection between the application server and
push service.
A push service MUST NOT forward the JWT or public key to the user A push service MUST NOT forward the JWT or public key to the user
agent when delivering the push message. agent when delivering the push message.
6. Security Considerations 5. Security Considerations
This authentication scheme is vulnerable to replay attacks if an This authentication scheme is vulnerable to replay attacks if an
attacker can acquire a valid JWT. Applying narrow limits to the attacker can acquire a valid JWT. Applying narrow limits to the
period over which a replayable token can be reused limits the period over which a replayable token can be reused limits the
potential value of a stolen token to an attacker and can increase the potential value of a stolen token to an attacker and can increase the
difficulty of stealing a token. difficulty of stealing a token.
An application server might offer falsified contact information. A An application server might offer falsified contact information. A
push service operator therefore cannot use the presence of push service operator therefore cannot use the presence of
unvalidated contact information as input to any security-critical unvalidated contact information as input to any security-critical
decision-making process. decision-making process.
Validation of a signature on the JWT requires a non-trivial amount of Validation of a signature on the JWT requires a non-trivial amount of
computation. For something that might be used to identify legitimate computation. For something that might be used to identify legitimate
requests under denial of service attack conditions, this is not requests under denial of service attack conditions, this is not
ideal. Application servers are therefore encouraged to reuse a JWT, ideal. Application servers are therefore encouraged to reuse tokens,
which permits the push service to cache the results of signature which permits the push service to cache the results of signature
validation. validation.
7. IANA Considerations 6. IANA Considerations
7.1. WebPush Authentication Scheme
This registers the "WebPush" authentication scheme in the "Hypertext This document registers the "vapid" authentication scheme in the
Transfer Protocol (HTTP) Authentication Scheme Registry" established "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"
in [RFC7235]. established in [RFC7235].
Authentication Scheme Name: WebPush Authentication Scheme Name: vapid
Pointer to specification text: Section 3 of this document Pointer to specification text: Section 3 of this document
Notes: This scheme is origin-server only and does not define a Notes: This scheme is origin-server only and does not define a
challenge. challenge.
7.2. p256ecdsa Parameter for Crypto-Key Header Field 6.1. Vapid Authentication Scheme Parameters
This registers a "p256ecdsa" parameter for the Crypto-Key header This creates a "Vapid Authentication Scheme Parameters" registry for
field in the "Hypertext Transfer Protocol (HTTP) Crypto-Key parameters to the "vapid" authentication scheme. This registry is
Parameters" established in [I-D.ietf-httpbis-encryption-encoding]. under the "WebPush Parameters" grouping. The registry operates on
the "Specification Required" policy [RFC5226].
Parameter Name: p256ecdsa Registrations MUST include the following information:
Purpose: Conveys a public key for that is used to generate an ECDSA Parameter Name: A name for the parameter, which conforms to the
signature. "token" grammar [RFC7230]
Reference: Section 4 of this document Purpose (optional): A brief identifying the purpose of the
parameter.
8. Acknowledgements Specification: A link to the specification that defines the format
and semantics of the parameter.
This registry initially contains the following entries:
+---------------+-------------------------+-------------------------+
| Parameter | Purpose | Specification |
| Name | | |
+---------------+-------------------------+-------------------------+
| t | JWT authentication | [[RFC-to-be]], Section |
| | token | 3.1 |
| | | |
| k | ECDSA signing key | [[RFC-to-be]], Section |
| | | 3.2 |
+---------------+-------------------------+-------------------------+
7. Acknowledgements
This document would have been much worse than it currently is if not This document would have been much worse than it currently is if not
for the contributions of Benjamin Bangert, Chris Karlof, Costin for the contributions of Benjamin Bangert, JR Conlin, Chris Karlof,
Manolache, and others. Costin Manolache, and others.
9. References 8. References
9.1. Normative References 8.1. Normative References
[FIPS186] National Institute of Standards and Technology (NIST), [FIPS186] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", NIST PUB 186-4 , July "Digital Signature Standard (DSS)", NIST PUB 186-4 , July
2013. 2013.
[I-D.ietf-httpbis-encryption-encoding]
Thomson, M., "Encrypted Content-Encoding for HTTP", draft-
ietf-httpbis-encryption-encoding-01 (work in progress),
March 2016.
[I-D.ietf-webpush-protocol] [I-D.ietf-webpush-protocol]
Thomson, M., Damaggio, E., and B. Raymor, "Generic Event Thomson, M., Damaggio, E., and B. Raymor, "Generic Event
Delivery Using HTTP Push", draft-ietf-webpush-protocol-06 Delivery Using HTTP Push", draft-ietf-webpush-protocol-12
(work in progress), June 2016. (work in progress), October 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
<http://www.rfc-editor.org/info/rfc4648>. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
<http://www.rfc-editor.org/info/rfc6068>. <http://www.rfc-editor.org/info/rfc6068>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011, DOI 10.17487/RFC6454, December 2011,
<http://www.rfc-editor.org/info/rfc6454>. <http://www.rfc-editor.org/info/rfc6454>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <http://www.rfc-editor.org/info/rfc7515>. 2015, <http://www.rfc-editor.org/info/rfc7515>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015, DOI 10.17487/RFC7518, May 2015,
<http://www.rfc-editor.org/info/rfc7518>. <http://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>. <http://www.rfc-editor.org/info/rfc7519>.
[X9.62] ANSI, "Public Key Cryptography For The Financial Services [X9.62] ANSI, "Public Key Cryptography For The Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62 , 1998. (ECDSA)", ANSI X9.62 , 1998.
9.2. Informative References 8.2. Informative References
[API] van Ouwerkerk, M. and M. Thomson, "Web Push API", 2015, [API] van Ouwerkerk, M. and M. Thomson, "Web Push API", 2015,
<https://w3c.github.io/push-api/>. <https://w3c.github.io/push-api/>.
[I-D.ietf-webpush-encryption] [I-D.ietf-webpush-encryption]
Thomson, M., "Message Encryption for Web Push", draft- Thomson, M., "Message Encryption for Web Push", draft-
ietf-webpush-encryption-02 (work in progress), March 2016. ietf-webpush-encryption-06 (work in progress), October
2016.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>. <http://www.rfc-editor.org/info/rfc3339>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015, DOI 10.17487/RFC7517, May 2015,
<http://www.rfc-editor.org/info/rfc7517>. <http://www.rfc-editor.org/info/rfc7517>.
Authors' Addresses Authors' Addresses
Martin Thomson Martin Thomson
Mozilla Mozilla
Email: martin.thomson@gmail.com Email: martin.thomson@gmail.com
 End of changes. 55 change blocks. 
142 lines changed or deleted 180 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/