On Wed, April 23, 2014 1:31 am, Ivan RistiÄ wrote:
> In Section 2.6. ("Validating Pinned Connections"), there is this wording:
>
> "To perform Pin Validation, the UA will compute the SPKI Fingerprints
> for each certificate in the Pinned Host's validated certificate
> chain, [...]"
>
> It is assumed that there is only one validated certificate chain. In
> practice, there could be multiple valid certificate chains, some with
> pins, others without. It's possible that a UA will first process the
> paths, select one deemed to be the "best", only after which the pins
> will be examined. If the selected path is without pins, the connection
> will fail, even though there might be another paths that could have been
> used.
>
> I think the specification should describe this situation, and instruct
> UAs to try alternative (acceptable) trust paths in case of pin failure.
>
> --
> Ivan
>
Note that describing path *building* algorithms has largely been outside
the scope of most protocol work. The fact that there are multiple valid
paths - eg: via the chasing of authorityInfoAccess - has in fact been
contentious in other WGs (PKIX/TLS, for example) - in part because the aIA
is unvalidated, attacker-controlled data being processed by the client.
The exact behaviour of the UA's path building algorithm is equally one
that differs wildly between UAs (and notably, sometimes between the same
UA on different platforms).
The behaviour you describe as preferable (check-while-building) is
something that's been/being implemented in Firefox, while the behaviour
you dislike (check-after-building) is something that's been implemented in
Chrome. For Chrome, when dealing with different platforms' path validating
APIs, the check-after-building is the only implementation *possible* using
these APIs.
I don't think the check-while-building algorithm provides any more
determinism for clients than the check-after-building algorithm. For sites
that are implementing pinning, they have two absolute guarantees - the
SPKI of the EE cert, and the SPKI of the EE's signer - will always be in
the chain. Above that, the exact nature of what's valid - either with
check-after or check-while - is somewhat dependent on the applications'
trust store - and if you wish to pin at those levels or above, you need a
robust pin set. PKP-R-O provides a means to discover that pin set
proactively prior to pinning.
Cheers,
Ryan
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
