diff --git a/cookies/index.html b/cookies/index.html index d89709777d..5d48c1653a 100644 --- a/cookies/index.html +++ b/cookies/index.html @@ -1,1098 +1,286 @@ + Content Security Policy: Cookie Controls - + + - + + + + +
-

+

Content Security Policy: Cookie Controls

-

Editor’s Draft,

+

W3C Working Group Note,

This version: -
https://w3c.github.io/webappsec-csp/cookies/ -
Latest version: +
http://www.w3.org/TR/2016/NOTE-csp-cookies-1-20160908/ +
Latest published version:
http://www.w3.org/TR/csp-cookies/ +
Editor's Draft: +
https://w3c.github.io/webappsec-csp/cookies/
Feedback:
public-webappsec@w3.org with subject line “[csp-cookies] … message topic …” (archives)
Editor:
(Google Inc.)
-
+
+
+ Obsoletion Notice +

This specification is not being actively maintained, + and should not be used as a guide for implementations. + It may be revived in the future, + but for now should be considered obsolete.

+

If you have questions or comments on this specification, + please send an email to the editors.

+
+

©2015 Google, Inc.

Abstract

-

This document defines mechanisms by which web developers can limit the ways +

This Note provides a historical reference for a proposed set of mechanisms +by which web developers can limit the ways in which cookies may be set in the context of their sites and applications.

Status of this document

-
-

This is a public copy of the editors’ draft. - It is provided for discussion only and may change at any moment. - Its publication here does not imply endorsement of its contents by W3C. - Don’t cite this document other than as work in progress.

-

Changes to this document may be tracked at https://github.com/w3c/webappsec.

-

The (archived) public mailing list public-webappsec@w3.org (see instructions) - is preferred for discussion of this specification. - When sending e-mail, - please put the text “csp-cookies” in the subject, - preferably like this: - “[csp-cookies] …summary of comment…”

-

This document was produced by the Web Application Security Working Group.

-

This document was produced by a group operating under - the 5 February 2004 W3C Patent Policy. - W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; - that page also includes instructions for disclosing a patent. - An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

-

This document is governed by the 1 September 2015 W3C Process Document.

-

-
+
Work on this document has been discontinued and it should not be + referenced or used as a basis for implementation.
-

Table of Contents

-
- -
+ +

1. Introduction

@@ -1113,14 +301,14 @@

1 cookies. Following the principle of least privilege, the clever developers responsible for those pages send the following headers along with every HTTP response, ensuring that no cookies can be set via Set-Cookie or document.cookie: -
Content-Security-Policy: cookie-scope none
+
Content-Security-Policy: cookie-scope none
 

     
     

       MegaCorp Inc. hosts a number of pages on http://non-secure.example.com which need to write cookies, but don’t need those cookies to span
     subdomains. The following header ensures that cookies can only be set via Set-Cookie or document.cookie if those cookies are "host only" (e.g. the
     cookie’s domain attribute is empty): 
-
Content-Security-Policy: cookie-scope host
+
Content-Security-Policy: cookie-scope host
 

      
That is, the following code would set a cookie:

 
document.cookie = "key=value";
@@ -1131,11 +319,11 @@ 
1
     

     

       MegaCorp Inc. hosts a number of pages on https://secure.example.com which need to write cookies, but don’t need those cookies to span
-    subdomains. They’ll certainly set the host property, just
+    subdomains. They’ll certainly set the host property, just
     like the previous example, but since this is a secure site, they also wish
     to ensure that any cookies they set also contain the secure attribute.
     They can do so with the following header: 
-
Content-Security-Policy: cookie-scope host secure
+
Content-Security-Policy: cookie-scope host secure
 

      
That is, the following code would set a cookie:

 
document.cookie = "key=value; secure";
@@ -1148,30 +336,30 @@ 
1

-

cookie-scope is a Content Security Policy directive [CSP] which restricts the cookies [RFC6265] which can be set in a particular context. The syntax is described by the +

cookie-scope is a Content Security Policy directive [CSP] which restricts the cookies [RFC6265] which can be set in a particular context. The syntax is described by the following ABNF grammar [RFC5234] (including the RWS rule from [RFC7230]):

directive-name = "cookie-scope"
-directive-value = scoping-rules *( RWS scoping-rules )
-scoping-rules = "host" / "http" / "none" / "secure"
+directive-value = scoping-rules *( RWS scoping-rules )
+scoping-rules = "host" / "http" / "none" / "secure"

The directive has one of four values:

  1. -

    "host" allows "host only" cookies to be set, but will block +

    "host" allows "host only" cookies to be set, but will block setting cookies which set a domain attribute.

  2. -

    "http" allows cookies to be set via the Set-Cookie HTTP +

    "http" allows cookies to be set via the Set-Cookie HTTP header, but not via document.cookie.

  3. -

    "none" blocks all cookies.

    +

    "none" blocks all cookies.

  4. -

    "secure" allows cookies to be set with a secure attribute, and will block setting any non-secure cookies.

    +

    "secure" allows cookies to be set with a secure attribute, and will block setting any non-secure cookies.

These values MAY be combined in order to tighten the restrictions on a cookie. - That is, if both "host" and "secure" are + That is, if both "host" and "secure" are present, then cookies may only be set which are both secure and host-only. - If "none" is present with any combination of the other values, + If "none" is present with any combination of the other values, no cookies may be set.

Erik Nygren proposed adding path restrictions as well. Is that worthwhile?

2.1. Processing Model

@@ -1221,26 +409,26 @@
  1. -

    Let scope be the result of executing §3.3 Parse string as a cookie-scope value on policy’s cookie-scope directive.

    +

    Let scope be the result of executing §3.3 Parse string as a cookie-scope value on policy’s cookie-scope directive.

  2. If any of the following conditions are met, return "Violates":

    1. -

      scope contains "host", and the cookie’s host-only-flag is false.

      +

      scope contains "host", and the cookie’s host-only-flag is false.

    2. -

      scope contains "http", and the cookie +

      scope contains "http", and the cookie was received from a "non-HTTP" API.

    3. -

      scope contains "none".

      +

      scope contains "none".

    4. -

      scope contains "secure", and the +

      scope contains "secure", and the cookie’s secure-only-flag is false.

  3. Return "Does not violate".

3.3. Parse string as a cookie-scope value

-

Given a string (string), this algorithm returns a set of the valid cookie-scope values the string represents. Invalid values are +

Given a string (string), this algorithm returns a set of the valid cookie-scope values the string represents. Invalid values are ignored:

  1. @@ -1252,7 +440,7 @@

    3.3. spaces:

    1. -

      If token matches the grammar for scoping-rules, insert token into values.

      +

      If token matches the grammar for scoping-rules, insert token into values.

  2. Return values.

    @@ -1278,22 +466,22 @@

    Conformance

    Document conventions

    Conformance requirements are expressed with a combination of - descriptive assertions and RFC 2119 terminology. The key words "MUST", - "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", - "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this + descriptive assertions and RFC 2119 terminology. The key words “MUST”, + “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, + “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

    All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

    -

    Examples in this specification are introduced with the words "for example" +

    Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

    This is an example of an informative example.

    -

    Informative notes begin with the word "Note" and are set apart from the +

    Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

    Note, this is an informative note.

    Conformant Algorithms

    @@ -1306,9 +494,10 @@

    -

    Index

    -

    Terms defined by this specification

    -
      + +

      Index

      +

      Terms defined by this specification

      + -

      Terms defined by reference

      -
        +

        Terms defined by reference

        + -

        References

        -

        Normative References

        +

        References

        +

        Normative References

        -
        [CSP] -
        Brandon Sterne; Adam Barth. Content Security Policy 1.0. 19 February 2015. NOTE. URL: http://www.w3.org/TR/CSP1/ -
        [CSP3] -
        Mike West; Daniel Veditz. Content Security Policy. ED. URL: https://w3c.github.io/webappsec/specs/content-security-policy/ -
        [HTML5] -
        Ian Hickson; et al. HTML5. 28 October 2014. REC. URL: http://www.w3.org/TR/html5/ -
        [RFC2119] +
        [CSP] +
        Brandon Sterne; Adam Barth. Content Security Policy 1.0. 19 February 2015. NOTE. URL: https://www.w3.org/TR/CSP1/ +
        [CSP3] +
        Mike West. Content Security Policy Level 3. 21 June 2016. WD. URL: https://www.w3.org/TR/CSP3/ +
        [HTML5] +
        Ian Hickson; et al. HTML5. 28 October 2014. REC. URL: https://www.w3.org/TR/html5/ +
        [RFC2119]
        S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119 -
        [RFC5234] +
        [RFC5234]
        D. Crocker, Ed.; P. Overell. Augmented BNF for Syntax Specifications: ABNF. January 2008. Internet Standard. URL: https://tools.ietf.org/html/rfc5234 -
        [RFC6265] +
        [RFC6265]
        A. Barth. HTTP State Management Mechanism. April 2011. Proposed Standard. URL: https://tools.ietf.org/html/rfc6265 -
        [RFC6454] +
        [RFC6454]
        A. Barth. The Web Origin Concept. December 2011. Proposed Standard. URL: https://tools.ietf.org/html/rfc6454 -
        [RFC7230] +
        [RFC7230]
        R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7230 -
        [URL] -
        Anne van Kesteren; Sam Ruby. URL. 9 December 2014. WD. URL: http://www.w3.org/TR/url-1/ +
        [WHATWG-URL] +
        Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/
        -

        Informative References

        +

        Informative References

        -
        [CSP-PINNING] +
        [CSP-PINNING]
        Mike West. Content Security Policy: Pinning. FPWD. URL: https://w3c.github.io/webappsec/specs/csp-pinning/ -
        [YUMMY-COOKIES] +
        [YUMMY-COOKIES]
        Vincent Marti. Yummy cookies across domains. URL: https://github.com/blog/1466-yummy-cookies-across-domains
        -

        Issues Index

        +

        Issues Index

        Erik Nygren proposed adding path restrictions as well. Is that worthwhile? ↵
        Monkey patching! Hey, maybe it’s time to reopen that cookie RFC after @@ -1396,5 +585,113 @@

        Issue
        We’ll need a mechanism to restrict reading from document.cookie, but I’d like something less specific than cookie-scope disable-dom-access or something similar. The linked GitHub bug is a proposal that’s a bit more general and widely applicable. <https://github.com/w3c/webappsec-csp/issues/42> ↵

        - - \ No newline at end of file + + + + + + + diff --git a/pinning/index.html b/pinning/index.html index 481a739248..abbc7b2e41 100644 --- a/pinning/index.html +++ b/pinning/index.html @@ -1,1136 +1,329 @@ + Content Security Policy Pinning - + + - + + + + +
        -

        +

        Content Security Policy Pinning

        -

        Editor’s Draft,

        +

        W3C Working Group Note,

        This version: -
        https://w3c.github.io/webappsec-csp/pinning/ -
        Latest version: +
        http://www.w3.org/TR/2016/NOTE-csp-pinning-1-20160908/ +
        Latest published version:
        http://www.w3.org/TR/csp-pinning/ +
        Editor's Draft: +
        https://w3c.github.io/webappsec-csp/pinning/
        Version History:
        https://github.com/w3c/webappsec-csp/commits/master/pinning/index.src.html
        Feedback: -
        public-webappsec@w3.org with subject line “[csp-pinning] … message topic …” (archives) +
        public-webappsec@w3.org with subject line “[csp-pinning] … message topic …” (archives)
        Editor:
        (Google Inc.)
        Participate:
        File an issue (open issues)
        -
        -

        Copyright © 2015 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.

        +
        +
        + Obsoletion Notice +

        This specification is not being actively maintained, + and should not be used as a guide for implementations. + It may be revived in the future, + but for now should be considered obsolete.

        +

        If you have questions or comments on this specification, + please send an email to the editors.

        +
        +
        +

        Copyright © 2016 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.

        Abstract

        -

        This document defines two new HTTP header fields that allow authors to +

        This Note provides a historical reference for a proposed mechanism to -instruct user agents to remember ("pin") and enforce a Content Security -Policy for a set of hosts for a period of time.

        +allow authors to instruct user agents to remember ("pin") and +enforce a Content Security Policy for a set of hosts for a period of time.

        Status of this document

        -
        -

        This is a public copy of the editors’ draft. - It is provided for discussion only and may change at any moment. - Its publication here does not imply endorsement of its contents by W3C. - Don’t cite this document other than as work in progress.

        -

        Changes to this document may be tracked at https://github.com/w3c/webappsec.

        -

        The (archived) public mailing list public-webappsec@w3.org (see instructions) - is preferred for discussion of this specification. - When sending e-mail, - please put the text “csp-pinning” in the subject, - preferably like this: - “[csp-pinning] …summary of comment…”

        -

        This document was produced by the Web Application Security Working Group.

        -

        This document was produced by a group operating under - the 5 February 2004 W3C Patent Policy. - W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; - that page also includes instructions for disclosing a patent. - An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

        -

        This document is governed by the 1 September 2015 W3C Process Document.

        -

        -
        +
        Work on this document has been discontinued and it should not be + referenced or used as a basis for implementation.
        -

        Table of Contents

        -

  • 3 Pinned Policy Delivery - + +
  • 4 Pinned Policy Processing - + +
  • 5 Security Considerations - +
  • 6 Privacy Considerations - +
  • 7 Authoring Considerations - +
  • 8 IANA Considerations - +
  • 9 Acknowledgements
  • Conformance - +
  • Index - +
  • References - +
  • Issues Index - - + +

    1. Introduction

    @@ -1149,7 +342,7 @@

    1. CSP Pinning attempts to address this concern by allowing authors to "pin" a baseline policy to an application’s host. Conceptually, this is quite similar to the approach taken by Strict Transport Security [RFC6797] and Public Key - Pinning [PKP]: we define a new header, Content-Security-Policy-Pin which instructs a user agent + Pinning [PKP]: we define a new header, Content-Security-Policy-Pin which instructs a user agent to remember a baseline policy that will be enforced for any document and worker delivered by an application that doesn’t come with its own Content-Security-Policy header.

    1.1. Use Cases

    @@ -1166,8 +359,8 @@

    https://example.com/application1/ delivers the following HTTP response headers: -
    Content-Security-Policy-Pin: max-age: 10886400;
-                             includeSubDomains;
+
    Content-Security-Policy-Pin: max-age: 10886400;
+                             includeSubDomains;
                              default-src https:;
                              form-action 'none';
                              frame-ancestors 'none';
@@ -1180,8 +373,8 @@ 
    
 
    
      
    While https://example.com/application2/ delivers the following
     HTTP response headers:
    
-
    Content-Security-Policy-Pin: max-age: 10886400;
-                             includeSubDomains;
+
    Content-Security-Policy-Pin: max-age: 10886400;
+                             includeSubDomains;
                              default-src https:;
                              form-action 'none';
                              frame-ancestors 'none';
@@ -1199,25 +392,25 @@ 
    
     
    2. Key Concepts and Terminology
    
     
    2.1. Terms defined by this specification
    
     
    
-     
      pinned security policy  
+     
      pinned security policy  
      
     A security policy that is enforced for resources
-      delivered from a protected host without their own policy.
+      delivered from a protected host without their own policy.
       The pinned policy’s properties are defined in §3 Pinned Policy Delivery. 
-     
    pinned policy cache
+     
    pinned policy cache
      
    
        In order to persistently enforce policy for an origin, the user
-      agent caches the following details about each pinned policy: 
+      agent caches the following details about each pinned policy: 
       
      
-       
    1.  The protected host: a hostname to which the policy applies
+       
    2.  The protected host: a hostname to which the policy applies
           (e.g. example.com) 
-       
    3.  subdomains included: true if includeSubDomains is asserted, false otherwise. 
-       
    4.  The policy expiration date: the moment at which a pinned
+       
    5.  subdomains included: true if includeSubDomains is asserted, false otherwise. 
+       
    6.  The policy expiration date: the moment at which a pinned
           policy is no longer applicable 
-       
    7.  The policy directive set: a set of Content Security Policy
-          directives [CSP] that the user agent MUST apply, according to its mode, for each Document and Worker served from protected host, (and, potentially, its subdomains)
+       
    8.  The policy directive set: a set of Content Security Policy
+          directives [CSP] that the user agent MUST apply, according to its mode, for each Document and Worker served from protected host, (and, potentially, its subdomains)
           that does not provide its own policy. 
-       
    9.  mode: monitor if the policy directive
-          set is to be monitored, enforce if the policy directive set is to be enforced. 
+       
    10.  mode: monitor if the policy directive
+          set is to be monitored, enforce if the policy directive set is to be enforced. 
       
    
     
    
     
    The Augmented Backus-Naur Form (ABNF) notation used in §3 Pinned Policy Delivery is specified in RFC5234. [ABNF]
    
@@ -1225,7 +418,7 @@ 
    
     
    3. Pinned Policy Delivery
    
     
    A server MAY instruct a user agent to pin a single security policy by
-  sending either a Content-Security-Policy-Pin or Content-Security-Policy-Report-Only-Pin HTTP response
+  sending either a Content-Security-Policy-Pin or Content-Security-Policy-Report-Only-Pin HTTP response
   header field along with a resource. §4 Pinned Policy Processing defines the user
   agent’s behavior when it receives such a response.
    
     
    Once a policy is pinned, it will be either enforced or monitored as specified for any resource that doesn’t enforce or monitor its own policy.
    
@@ -1233,14 +426,14 @@ 
    meta elements. See §7.2 Pins override <meta> for authoring guidelines.
    
     
    
      
    3.1.  Content-Security-Policy-Pin Header Field 
    
-     
    The Content-Security-Policy-Pin header field
+     
    The Content-Security-Policy-Pin header field
     is the mechanism for delivering a pinned policy that the user agent MUST enforce for any resource which is not delivered with a Content-Security-Policy header (as described in the §4.1.3 Pin a policy to response algorithm).
    
      
    The ABNF grammar is as follows:
    
 
    "Content-Security-Policy-Pin:" 1#<policy-token production from CSP, Section 4.1>
 
    
      
    Pinning a security policy is a somewhat dangerous operation, and
     requires some reasonable expectation that the pinning is in fact desired by
-    a particular origin’s owner. To that end, a server MUST NOT send a Content-Security-Policy-Pin header with a resource delivered from an a priori insecure
+    a particular origin’s owner. To that end, a server MUST NOT send a Content-Security-Policy-Pin header with a resource delivered from an a priori insecure
     URL. The threat is discussed in more detail in §5.1 Hostile Pinning.
    
      
    Note: This means that pinning is only practically available over HTTPS.
     This is intentional, as pinning is a powerful feature that ought to be
@@ -1254,13 +447,13 @@ 
    3.2.  Content-Security-Policy-Report-Only-Pin Header Field 
    
-     
    The Content-Security-Policy-Report-Only-Pin header field is the mechanism for delivering a pinned policy that the user
+     
    The Content-Security-Policy-Report-Only-Pin header field is the mechanism for delivering a pinned policy that the user
     agent MUST monitor for any resource which is not delivered with a Content-Security-Policy-Report-Only header (as described in the §4.1.3 Pin a policy to response algorithm).
    
      
    The ABNF grammar is as follows:
    
 
    "Content-Security-Policy-Report-Only-Pin:" 1#<policy-token production from CSP, Section 4.1>
 
    
-     
    As with Content-Security-Policy-Pin, a server MUST NOT
-    send a Content-Security-Policy-Report-Only-Pin header
+     
    As with Content-Security-Policy-Pin, a server MUST NOT
+    send a Content-Security-Policy-Report-Only-Pin header
     with a resource delivered from an a priori insecure URL. The threat is discussed in more detail in §5.1 Hostile Pinning.
    
      
    Note: This means that pin-reporting is only practically available over HTTPS.
     This is intentional, as pinning is a powerful feature that ought to be
@@ -1284,24 +477,24 @@ 
    3.3. Pinned Policy Syntax
    
      
    The grammar for a pinned policy is the same as the grammar for the Content-Security-Policy header, defined in Section 4.1 of the Content Security Policy
     specification.
    
-     
    A pinned policy’s value MUST contain a max-age directive, and MAY contain an includeSubDomains directive.
    
+     
    A pinned policy’s value MUST contain a max-age directive, and MAY contain an includeSubDomains directive.
    
      
    
       
    3.3.1. The max-age directive
    
-      
    The max-age directive specifies the number of
-      seconds after the reception of the Content-Security-Policy-Pin HTTP response header
-      field during which the UA SHOULD enforce the pinned policy.
    
+      
    The max-age directive specifies the number of
+      seconds after the reception of the Content-Security-Policy-Pin HTTP response header
+      field during which the UA SHOULD enforce the pinned policy.
    
       
    The directive is defined via the following ABNF grammar:
    
 
    directive-name  = "max-age"
 directive-value = 1*DIGIT
 
    
-      
    The max-age directive MUST be present within the Content-Security-Policy-Pin header field. If it is not
+      
    The max-age directive MUST be present within the Content-Security-Policy-Pin header field. If it is not
       present, the header field will be ignored (see §4 Pinned Policy Processing for
       user agent requirements).
    
      
    
      
    
       
    3.3.2.  The includeSubDomains directive 
    
-      
    The includeSubDomains directive signals to
-      the user agent that the pinned policy defined in the Content-Security-Policy-Pin header field applies not
+      
    The includeSubDomains directive signals to
+      the user agent that the pinned policy defined in the Content-Security-Policy-Pin header field applies not
       only to the origin that served the resource representation,
       but also to any origin whose host component is a subdomain
       of the host component of the resource representation’s origin (see §4 Pinned Policy Processing for user agent requirements).
    
@@ -1314,24 +507,24 @@ 
    
-      
    Sift through the HTTP headers according to the §4.1.1 Discover pinned policies for response algorithm to determine if the pinned policy cache for the response’s
+      
    Sift through the HTTP headers according to the §4.1.1 Discover pinned policies for response algorithm to determine if the pinned policy cache for the response’s
  host needs to be updated.
    
      
  • 
-      
    Update the pinned policy cache, according to the §4.1.2 Pin policy for origin in mode algorithm.
    
+      
    Update the pinned policy cache, according to the §4.1.2 Pin policy for origin in mode algorithm.
    
      
  • 
-      
    Update the response’s headers to ensure that any relevant pinned
+      
    Update the response’s headers to ensure that any relevant pinned
  policies are applied, according to the §4.1.3 Pin a policy to response algorithm.
    
     
     
     We probably need a hook in [Fetch]. In
   particular, we need to ensure that we detect and pin a policy early enough
   for frame-ancestors and referrer to handle blocking
   and redirects.
    
-    
    Periodically, the user agent will run through the pinned policies it
-  has stored in the pinned policy cache, and remove those that have
+    
    Periodically, the user agent will run through the pinned policies it
+  has stored in the pinned policy cache, and remove those that have
   expired, according to the §4.2.2 Remove expired pinned policies from the cache algorithm.
    
     
    4.1. Fetching Algorithms
    
     
    4.1.1.  Discover pinned policies for response 
    
-    
    Upon receiving a Response response containing at least one Content-Security-Policy-Pin header field, the user agent
+    
    Upon receiving a Response response containing at least one Content-Security-Policy-Pin header field, the user agent
   MUST peform the following steps:
    
     
      
      
    1.  Let origin be the origin of response’s URL. 
@@ -1344,7 +537,7 @@ 
      
     
      4.1.2.  Pin policy for origin in mode 
      
     
      Given an Origin origin, a parsed set of directives policy, and a mode (either enforce or monitor), this algorithm defines the user agent behavior that
-  results in a pinned policy for origin.
      
+  results in a pinned policy for origin.
      
     
        
      
      1.  If origin is an a priori insecure
       origin, output a developer-friendly warning, and abort these steps. 
@@ -1353,40 +546,40 @@ 
        parse the
       policy algorithm on directives. 
-     
      2.  If policy does not contain a max-age directive, then output a developer-friendly
+     
      3.  If policy does not contain a max-age directive, then output a developer-friendly
       warning, and abort these steps. 
-     
      4.  Let subdomains be true if an includeSubDomains is present in policy,
+     
      5.  Let subdomains be true if an includeSubDomains is present in policy,
       and false otherwise. 
-     
      6.  Let TTL be the number of seconds specified in policy’s max-age directive. If more than
+     
      7.  Let TTL be the number of seconds specified in policy’s max-age directive. If more than
       one such directive is present, let TTL be the largest value
       specified. 
      
      8.  Let expiration be the current time, plus TTL. 
-     
      9.  Remove any max-age and includeSubDomains directives from policy. 
+     
      10.  Remove any max-age and includeSubDomains directives from policy. 
      
      11.  Let pinned be the result of executing §4.2.1 Get the mode pinned policy for host for mode and host. 
      
      12. 
-       If pinned is not null, then update the pinned
+       If pinned is not null, then update the pinned
       policy pinned as follows: 
       
          
-       
        1.  If max-age is 0, then remove pinned from the pinned policy cache and abort these
+       
        2.  If max-age is 0, then remove pinned from the pinned policy cache and abort these
           steps. 
        
        3. 
          Otherwise: 
         
            
-         
          1.  Set pinned’s policy expiration date to expiration. 
-         
          2.  Set pinned’s subdomains included to subdomains. 
-         
          3.  Set pinned’s policy directive set to policy. 
+         
          4.  Set pinned’s policy expiration date to expiration. 
+         
          5.  Set pinned’s subdomains included to subdomains. 
+         
          6.  Set pinned’s policy directive set to policy. 
         
          
       
        
      
      13. 
-       Otherwise, host is not a protected host. If TTL is not 0, then: 
+       Otherwise, host is not a protected host. If TTL is not 0, then: 
       
          
-       
        1.  Let pinned be a new pinned policy. 
-       
        2.  Set pinned’s protected host to host. 
-       
        3.  Set pinned’s policy expiration date to expiration. 
-       
        4.  Set pinned’s subdomains included to subdomains. 
-       
        5.  Set pinned’s policy directive set to policy. 
-       
        6.  Set pinned’s mode to mode. 
-       
        7.  Add pinned to the pinned policy cache. 
+       
        8.  Let pinned be a new pinned policy. 
+       
        9.  Set pinned’s protected host to host. 
+       
        10.  Set pinned’s policy expiration date to expiration. 
+       
        11.  Set pinned’s subdomains included to subdomains. 
+       
        12.  Set pinned’s policy directive set to policy. 
+       
        13.  Set pinned’s mode to mode. 
+       
        14.  Add pinned to the pinned policy cache. 
       
        
     
      
     
      4.1.3.  Pin a policy to response 
      
@@ -1405,7 +598,7 @@ 
      value is null: 
         
        
          
      1.  Append a header named Content-Security-Policy with a
-              value of pinned’s policy directive set to response’s header list. 
+              value of pinned’s policy directive set to response’s header list. 
         
      
       
    
      
  •  Let pinned be the result of executing §4.2.1 Get the mode pinned policy for host for monitor and host. 
@@ -1416,26 +609,26 @@ 
    
          If value is null: 
         
      
-         
    1.  Append a header named Content-Security-Policy-Report-Only with a value of pinned’s policy directive set to response’s header list. 
+         
    2.  Append a header named Content-Security-Policy-Report-Only with a value of pinned’s policy directive set to response’s header list. 
         
    
       
     
     
    4.2.  Pinned Policy Cache Algorithms 
    
     
    4.2.1.  Get the mode pinned policy for host 
    
-    
    Given a host, and a mode mode, this algorithm
-  walks through the pinned policy cache, and returns the first matching
+    
    Given a host, and a mode mode, this algorithm
+  walks through the pinned policy cache, and returns the first matching
   policy. If no policies match, this algorithm returns null.
    
     
    Note: There ought to be at most one policy that matches, given the constraints
   in §4.1.2 Pin policy for origin in mode.
    
     
      
      
    1. 
-       For each policy in the pinned policy cache: 
+       For each policy in the pinned policy cache: 
       
        
-       
      1.  If policy’s mode is not mode, skip to the
-          next policy in the pinned policy cache. 
+       
      2.  If policy’s mode is not mode, skip to the
+          next policy in the pinned policy cache. 
        
      3.  Let match type be the result of applying the Known HSTS
-          Host domain name matching algorithm specified in [RFC6797] to host and policy’s protected host. 
-       
      4.  If match type is Superdomain Match, and policy’s subdomains included is true,
+          Host domain name matching algorithm specified in [RFC6797] to host and policy’s protected host. 
+       
      5.  If match type is Superdomain Match, and policy’s subdomains included is true,
           then return policy. 
        
      6.  If match type is Congruent Match, then
           return policy. 
@@ -1443,7 +636,7 @@ 
         Return null. 
     
      
     
      4.2.2.  Remove expired pinned policies from the cache 
      
-    
      Periodically, the user agent MUST remove expired policies from the pinned
+    
      Periodically, the user agent MUST remove expired policies from the pinned
   policy cache. Removal will have no web-visible effect, as expired policies
   will not modify Responses during fetching, but expired policies can
   have privacy impact if they aren’t removed completely (as they offer evidence
@@ -1451,11 +644,11 @@ 
      Expired entries can be removed via the following steps:
      
     
        
      
      1. 
-       For each policy in the list of pinned policies contained
-      in the pinned policy cache: 
+       For each policy in the list of pinned policies contained
+      in the pinned policy cache: 
       
          
-       
        1.  If policy’s policy expiration date is prior to the
-          current time, remove policy from the pinned policy
+       
        2.  If policy’s policy expiration date is prior to the
+          current time, remove policy from the pinned policy
           cache. 
       
        
     
      
@@ -1479,7 +672,7 @@ 
      Content-Security-Policy-Pin header with a max-age of 0. 
+     
    2.  Authors may also rescind a pinned policy by sending a new Content-Security-Policy-Pin header with a max-age of 0. 
     
    
     
    Moreover, the risk of malicious injection is mitigated by the fact that we
   only accept pins over secure and authenticated connections.
    
@@ -1487,7 +680,7 @@ 
    6. Privacy Considerations
    
     
    6.1. Fingerprinting
    
-    
    Similar to HSTS and HPKP, a pinned security policy could be used as a
+    
    Similar to HSTS and HPKP, a pinned security policy could be used as a
   "supercookie", setting a distinct policy for each user which can be used as
   an identifier in combination with (or instead of) HTTP cookies.
    
     
    For example, the report-uri directive could contain a unique
@@ -1496,7 +689,7 @@ 
    pinned policy cache when the user clears her browsing
+     
  •  Clear the pinned policy cache when the user clears her browsing
       data (cookies, site data, history, etc). 
      
  •  Refuse to process Set-Cookie response headers during the send violation reports algorithm. 
     
@@ -1532,7 +725,7 @@ 
    Content-Security-Policy-Pin Header Field)
+      
    This specification (See Content-Security-Policy-Pin Header Field)
      
     
    • 
     
    
@@ -1547,7 +740,7 @@ 
    Content-Security-Policy-Report-Only-Pin Header Field)
+      
    This specification (See Content-Security-Policy-Report-Only-Pin Header Field)
      
     
    
    
    
@@ -1560,22 +753,22 @@ 
    Conformance
    
   
    Document conventions
    
   
    Conformance requirements are expressed with a combination of
-    descriptive assertions and RFC 2119 terminology. The key words "MUST",
-    "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
-    "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this
+    descriptive assertions and RFC 2119 terminology. The key words “MUST”,
+    “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
+    “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this
     document are to be interpreted as described in RFC 2119.
     However, for readability, these words do not appear in all uppercase
     letters in this specification. 
    
   
    All of the text of this specification is normative except sections
     explicitly marked as non-normative, examples, and notes. [RFC2119]
    
-  
    Examples in this specification are introduced with the words "for example"
+  
    Examples in this specification are introduced with the words “for example”
     or are set apart from the normative text with class="example",
     like this: 
    
   
    
     
    
    This is an example of an informative example.
    
   
    
-  
    Informative notes begin with the word "Note" and are set apart from the
+  
    Informative notes begin with the word “Note” and are set apart from the
     normative text with class="note", like this: 
    
   
    Note, this is an informative note.
    
   
    Conformant Algorithms
    
@@ -1588,9 +781,10 @@ 
    
-  
    Index
    
-  
    Terms defined by this specification
    
-