On Fri, Sep 22, 2017 at 6:22 AM, Nick Lamb via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
> On Friday, 22 September 2017 05:01:03 UTC+1, Peter Bowen  wrote:
>> I realize this is somewhat more complex than what you, Ryan, or Jeremy
>> proposed, but it the only way I see root pins working across both
>> "old" and "new" trust stores.
>
> I would suggest that a better way to spend the remaining time would be 
> remedial work so that your business isn't dependant on a single third party 
> happening to make choices that are compatible with your existing processes. 
> Trust agility should be built into existing processes and systems, where it 
> doesn't exist today it must be retro-fitted, systems which can't be 
> retrofitted are an ongoing risk to the company's ability to deliver.
>
> Trust agility doesn't have to mean you give up all control, but if you were 
> in a situation where the business trusted roots from Symantec, Comodo and 
> say, GlobalSign then you would have an obvious path forwards in today's 
> scenario without also needing to trust dozens of organisations you've no 
> contact with.
>
> I know the Mozilla organisation has made this mistake itself in the past, and 
> I'm sure Google has too, but I don't want too much sympathy here to get in 
> the way of actually making us safer.

Nick,

I agree with pretty much everything you said :)

However, as you point out, many organisations have run into problems
in this area.  As a community, we saw similar issues come up during
the SHA-1 deprecation phase and seemed surprised.  I want to try to
make sure there is not surprise, especially when it comes to
configurations that are not obvious.

For example, on some mobile platforms it is common to have the app
enforce pinning but the OS handle chain building and validation.  This
can have poor interaction if the OS were to update the trust store as
the returned chain may no longer have the pinned CA.

Consider what Jeremy drew:

GeoTrust Primary Certification Authority -> DigiCert Global G2 -> (new
issuing CA) -> (end entity)

If the platform trusts DigiCert Global G2, then the chain that is
returned to the application will be:

DigiCert Global G2 -> (new issuing CA) -> (end entity)

In this case, any application pinned to GeoTrust will fail.

Even if it was a new Root:

GeoTrust Primary Certification Authority -> DigiCert GeoTrust G2 ->
(new issuing CA) -> (end entity)

The same problem will occur if the OS updates the trust store but the
application does not update.

One notable thing is that the server operator, application vendor, OS
vendor, and CA may be four unrelated parties.  If the application is
expected to work with "new" and "old" OS versions, this will take some
careful work if the keys in the built chain change over time.

Thanks,
Peter
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to