In 2.3, I believe

If the Public-Key-Pins response header field does not meet all four
   of these criteria

should be "all three of these criteria" by my bullet-point count.

To close up the hole with inherited parameters, in 2.2, prior to the
"We pin public keys" note, add:

  If the SubjectPublicKeyInfo of a certificate is incomplete when taken
  in isolation, such as when holding a DSA key without domain parameters,
  a public key pin cannot be formed.

And in 2.4, adding a phrase to the parenthetical comment in the big paragraph :

   If the connection has no errors, the UA will then apply a new
   correctness check: Pin Validation.  To perform Pin Validation, the UA
   will compute the fingerprints of the SPKI structures in each
   certificate in the host's validated certificate chain.  (The UA
   ignores certificates whose SPKI cannot be taken in isolation and
   superfluous certificates in the chain that do not form part
   of the validating chain.)  The UA will then check that the set of
   these fingerprints intersects the set of fingerprints in that host's
   Pinning Metadata.  If there is set intersection, the UA continues
   with the connection as normal.  Otherwise, the UA MUST treat this Pin
   Failure as a non-recoverable error.

Finally, I'd suggest the following change to 2.3.1, clarifying it's
required-ness and a max-age of 0.

2.3.1.  max-age

   max-age specifies the number of seconds, after the reception of the
   Public-Key-Pins HTTP Response Header, during which the UA regards the
   host as a Pinned Host.  The delta-seconds production is specified in
   [rfc-2616].

   max-age is a required attribute. If omitted, the UA MUST NOT note the
   host as a Pinned Host, and MUST discard any previously set Pinning
   Metadata for that host in its non-volatile store.

   If max-age is set to 0, the UA MUST likewise discard any previsouly
   set Pinning Metadata.

I won't be insulted if you dislike my wording, but I think this is a
complete summary of raised oustanding issues on -01.

-tom
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec

Reply via email to