On Thu, Nov 17, 2016 at 02:10:58PM -1000, Brian Smith wrote:
> Nick Lamb <[email protected]> wrote:
> > There's a recurring pattern in most of the examples. A technical
> > counter-measure would be possible, therefore you suppose it's OK to
> > screw-up and the counter-measure saves us.
>
> Right.
>
> > I believe this is the wrong attitude. These counter-measures are defence
> > in depth. We need this defence because people will screw up, but that
> > doesn't make screwing up OK.
> >
>
> With that attitude, CAs would never issue intermediate CAs with name
> constraints as the technical constraint on reasonable terms (not costing a
> fortune, not forcing you to let the issuing CA have the private key), and
> key pinning would remain too dangerous for the vast majority of sites to
> ever deploy. Giving up those things would be a huge cost. What's the actual
> benefit to end users in giving them up?
Survivability in the event that the technical constraint is implemented in a
flawed manner. It doesn't seem right to let one party's mistake ("whoops we
issued a 20 year certificate for addons.mozilla.org and don't have any
revocation infrastructure!") pass without any sanction, while another
party's mistake ("there was a flaw in the application of name constraints in
intermediate CA certificates under certain circumstances") results in
mass-pwnage.
> (Note: Key pinning isn't the only advantage to being able to freely operate
> your own intermediate CA.)
I don't see how freely operating your own intermediate CA is a pre-requisite
for key pinning, either. Nor do I accept that running a TCSC in line with
the minimum standards agreed for participation in the WebPKI *must*,
absolutely and without need for further justification, be prohibitively
expensive.
- Matt
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
