This was raised during our discussions in Atlanta, and continued on the
mailing list under http://trac.tools.ietf.org/wg/websec/trac/ticket/53

As discussed during Atlanta, the way that pinning is currently implemented
within Google Chrome, pinning is only enforced as it relates to so-called
"public trust anchors" (eg: those shipped by default as part of a browser
or OS installation, not those installed by a user).

The motivation for this was and is simple: If you have sufficient local
privilege to install additional trust anchors on a device, then it's
presumed you have sufficient privilege to take any number of other
actions, including disabling pinning enforcement entirely. As such, having
the UA disable enforcement selectively is strictly less worse, from a
security perspective, than having the UA disable enforcement entirely, and
still provides significant benefit through the reduction of risk through
public trust anchors.

However, this creates an interesting split between the specification
language and implementations.

In draft-04, we've tried to clarify this through the text in Section 2.6,
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.6 ,
along with the addition of a "strict" mode, as described in Section 2.1.4,
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.4

While there is an open question as to whether or not such user-agent
behaviour is appropriate to specify here, does the group feel the proposed
text sufficiently addresses the issue as originally raised?

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

Reply via email to